[148159] in cryptography@c2.net mail archive
[Cryptography] Fwd: Moving forward on improving HTTP's security
daemon@ATHENA.MIT.EDU (Greg)
Wed Nov 13 14:49:58 2013
X-Original-To: cryptography@metzdowd.com
From: Greg <greg@kinostudios.com>
Date: Wed, 13 Nov 2013 13:40:15 -0500
To: cryptography@randombit.net,
Cryptography <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============8717850461779798119==
Content-Type: multipart/signed; boundary="Apple-Mail=_207AC540-BB39-496E-8820-D37CD35DD182"; protocol="application/pgp-signature"; micalg=pgp-sha512
--Apple-Mail=_207AC540-BB39-496E-8820-D37CD35DD182
Content-Type: multipart/alternative;
boundary="Apple-Mail=_268E6A21-B7D1-498E-8843-EA90897F5F4C"
--Apple-Mail=_268E6A21-B7D1-498E-8843-EA90897F5F4C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
If you haven't heard, the IETF is trying to move forward with "HTTP =
2.0", which is, from what I can tell, simply "HTTPS all the time".
We know HTTPS is broken and that it gives people a false sense of =
security, leading them to share material that they otherwise might not =
share, with potentially life threatening consequences.
If you'd like to weigh in on this matter, you are welcome to subscribe =
and share your point of view before they do something rash and =
unreasonable.
To subscribe, send an email (subject: "Subscribe") to: =
ietf-http-wg-request@w3.org
Part of an exchange about this topic below is forwarded below:
--
Please do not email me anything that you are not comfortable also =
sharing with the NSA.
Begin forwarded message:
> Resent-From: ietf-http-wg@w3.org
> From: Tao Effect <contact@taoeffect.com>
> Subject: Re: Moving forward on improving HTTP's security
> Date: November 13, 2013 at 1:27:38 PM EST
> To: Mike Belshe <mike@belshe.com>
> Cc: Tim Bray <tbray@textuality.com>, James M Snell =
<jasnell@gmail.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group =
<ietf-http-wg@w3.org>
>=20
>> Agree with Tim; I am also in support of 100% TLS all the time.
>=20
> Here are some nice quotes from the EFF about the system you are =
supporting (without any explanation):
>=20
> As we learned from the SSL Observatory project, there are 600+ =
Certificate Authorities that your browser will trust; the attacker only =
needs to find one of those 600 that she is capable of breaking into. =
This has been happening with catastrophic results.
>=20
> Certificate-based attacks are a concern all over the world, including =
in the U.S., since governments everywhere are eagerly adopting spying =
technology to eavesdrop on the public. Vendors of this technology seem =
to suggest the attacks can be done routinely.=20
>=20
> In many cases, people's lives are literally ended (or destroyed) =
because of this system.
>=20
> I do not support such a system, and am very suspicious of folks =
voicing their support without a word of explanation.
>=20
> I am reminded of how easy it is for a malicious entity to infiltrate a =
group and manipulate their opinion through sock-puppets. Not to say that =
you are one, but it's something that I'm reminded of each time I come =
across these types of situations.
>=20
> Let's not have another NSA/NIST situation here.
>=20
> Links:
>=20
> =
https://www.eff.org/deeplinks/2011/03/iranian-hackers-obtain-fraudulent-ht=
tps
> =
https://www.eff.org/deeplinks/2011/09/post-mortem-iranian-diginotar-attack=
>=20
> Cheers,
> Greg
>=20
> --
> Please do not email me anything that you are not comfortable also =
sharing with the NSA.
>=20
> On Nov 13, 2013, at 1:14 PM, Mike Belshe <mike@belshe.com> wrote:
>=20
>> Agree with Tim; I am also in support of 100% TLS all the time.
>>=20
>> I would like us to do both Mark's proposals:
>> (A) opportunistic upgrade of http to SSL
>> and
>> (C) HTTP/2.0 is TLS all the time.
>>=20
>> Mike
>>=20
>>=20
>>=20
>> On Wed, Nov 13, 2013 at 9:46 AM, Tao Effect <contact@taoeffect.com> =
wrote:
>> On Nov 13, 2013, at 12:31 PM, Tim Bray <tbray@textuality.com> wrote:
>>>=20
>>> Let=92s not let the perfect be the enemy of the good.
>>>=20
>>> FWIW, here=92s one voice in support of HTTP/2=3D=3DTLS.
>>=20
>> Not much content there supporting your vote. :-(
>>=20
>> A vote doesn't count (in my book at least), if it doesn't have strong =
rationale before it.
>>=20
>> To me this also comes across as security theater (what a wonderful =
expression).
>>=20
>> Let's get this clear:
>>=20
>> 1. Perfection is not being requested. Just something other than =
"abysmal".
>>=20
>> 2. TLS that depends on CAs is not by any means "good". It is bad. =
Very bad. I would even support a viewpoint that says it's worse than =
HTTP because of the false sense of security that it gives people.
>>=20
>> - Greg
>>=20
>> --
>> Please do not email me anything that you are not comfortable also =
sharing with the NSA.
>>=20
>> On Nov 13, 2013, at 12:31 PM, Tim Bray <tbray@textuality.com> wrote:
>>=20
>>> On Wed, Nov 13, 2013 at 9:22 AM, James M Snell <jasnell@gmail.com> =
wrote:
>>> To be honest, much of this comes across to me as knee-jerk security
>>> theater. Sure, using TLS is a good thing, but by itself it doesn't
>>> come even remotely close to dealing with the range of fundamental
>>> security and privacy issues that have come to light over the past =
few
>>> months. If not handled properly, it could definitely give a false
>>> sense of security.
>>>=20
>>> Let=92s not let the perfect be the enemy of the good.
>>>=20
>>> FWIW, here=92s one voice in support of HTTP/2=3D=3DTLS. And another =
saying let=92s not give up on opportunistic encryption.
>>>=20
>>>=20
>>>=20
>>> =20
>>>=20
>>>=20
>>> On Wed, Nov 13, 2013 at 2:01 AM, Mark Nottingham <mnot@mnot.net> =
wrote:
>>> [snip]
>>> >
>>> > The most relevant proposals were:
>>> >
>>>=20
>>> FWIW, I intend to make another proposal once (a) the base http/2
>>> protocol is complete and (b) protocol extensions have been dealt =
with
>>> properly.
>>>=20
>>> [snip]
>>> >
>>> > As a result, I believe the best way that we can meet the goal of =
increasing use of TLS on the Web is to encourage its use by only using =
HTTP/2.0 with https:// URIs.
>>> >
>>>=20
>>> -1. HTTP/2 should not be limited to TLS only. If someone wishes to
>>> craft text that strongly encourages use of TLS in specific
>>> applications of HTTP/2, then that would be fine. But the protocol
>>> itself should not require it.
>>>=20
>>> > This can be effected without any changes to our current document; =
browser vendors are not required to implement HTTP/2.0 for http:// URIs =
today. However, we will discuss formalising this with suitable =
requirements to encourage interoperability; suggestions for text are =
welcome.
>>> >
>>>=20
>>> FWIW, I have to concur with the others on this thread, Mark. The
>>> language you're using here makes it sound like the decision has
>>> already been made.
>>>=20
>>> > To be clear - we will still define how to use HTTP/2.0 with =
http:// URIs, because in some use cases, an implementer may make an =
informed choice to use the protocol without encryption. However, for the =
common case -- browsing the open Web -- you'll need to use https:// URIs =
and if you want to use the newest version of HTTP.
>>> >
>>>=20
>>> Again, -1 to making this a normative requirement. Our task ought to =
be
>>> ensuring that people who bother to read the specification are fully
>>> informed of the choices they are making, and not to make those =
choices
>>> for them. Yes, I get it, some security is better than no security, =
but
>>> adding constraints that only partially address the problem, just
>>> because it makes us feel good or because it looks better from a PR
>>> perspective, is not the right approach.
>>>=20
>>> What I think would be helpful is taking some time to draw up a =
description of:
>>>=20
>>> 1. The specific types of threats to HTTP/1.1 and HTTP/2 we feel =
are
>>> significant.
>>> 2. The specific types of threats we collectively feel ought to be
>>> addressed by HTTP/2, and the ones we feel are beyond our scope
>>> 3. A broader list of options for how those threats can be =
mitigated
>>>=20
>>> In other words, an I-D describing the relevant threat model.
>>>=20
>>> Once we have that, we can make a more informed collective decision.
>>>=20
>>> - James
>>>=20
>>> > This is by no means the end of our security-related work. For =
example:
>>> >
>>> > * Alternate approaches to proxy caching (such as peer-to-peer =
caching protocols) may be proposed here or elsewhere, since traditional =
proxy caching use cases will no longer be met when TLS is in wider use.
>>> >
>>> > * As discussed in the perpass BoF, strengthening how we use TLS =
(e.g., for Perfect Forward Security) is on the table.
>>> >
>>> > * A number of people expressed interest in refining and/or =
extending how proxies work in HTTP (both 1.0 and 2.0), as discussed in =
draft-nottingham-http-proxy-problem (among many other relevant drafts).
>>> >
>>> > Furthermore, other security-related work in the IETF (see the =
perpass BoF) and elswhere (e.g., W3C) may affect HTTP. For example, a =
number of people have pointed out how weaknesses in PKIX affect the Web.
>>> >
>>> > Your input, as always, is appreciated. I believe this approach is =
as close to consensus as we're going to get on this contentious subject =
right now. As HTTP/2 is deployed, we will evaluate adoption of the =
protocol and might revisit this decision if we identify ways to further =
improve security.
>>> >
>>> >
>>>=20
>>>=20
>>=20
>>=20
>=20
--Apple-Mail=_268E6A21-B7D1-498E-8843-EA90897F5F4C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=windows-1252
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">If you =
haven't heard, the IETF is trying to move forward with "HTTP 2.0", which =
is, from what I can tell, simply "HTTPS all the =
time".<div><br></div><div>We know HTTPS is broken and that it gives =
people a false sense of security, leading them to share material that =
they otherwise might not share, with potentially life threatening =
consequences.</div><div><br></div><div>If you'd like to weigh in on this =
matter, you are welcome to subscribe and share your point of view before =
they do something rash and unreasonable.</div><div><br></div><div>To =
subscribe, send an email (subject: "Subscribe") to: <a =
href=3D"mailto:ietf-http-wg-request@w3.org">ietf-http-wg-request@w3.org</a=
><br><div><br class=3D"webkit-block-placeholder"></div><div>Part of an =
exchange about this topic below is forwarded below:</div><div>
<br>--<br>Please do not email me anything that you are =
not comfortable also sharing with the NSA.<br>
</div>
<div><br><div>Begin forwarded message:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px;"><span style=3D"font-family:'Helvetica'; color:rgba(0, =
0, 0, 1.0);"><b>Resent-From: </b></span><span =
style=3D"font-family:'Helvetica';"><a =
href=3D"mailto:ietf-http-wg@w3.org">ietf-http-wg@w3.org</a><br></span></di=
v><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px;"><span style=3D"font-family:'Helvetica'; color:rgba(0, =
0, 0, 1.0);"><b>From: </b></span><span =
style=3D"font-family:'Helvetica';">Tao Effect <<a =
href=3D"mailto:contact@taoeffect.com">contact@taoeffect.com</a>><br></s=
pan></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px;"><span =
style=3D"font-family:'Helvetica'; color:rgba(0, 0, 0, 1.0);"><b>Subject: =
</b></span><span style=3D"font-family:'Helvetica';"><b>Re: Moving =
forward on improving HTTP's security</b><br></span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px;"><span style=3D"font-family:'Helvetica'; color:rgba(0, =
0, 0, 1.0);"><b>Date: </b></span><span =
style=3D"font-family:'Helvetica';">November 13, 2013 at 1:27:38 PM =
EST<br></span></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px;"><span =
style=3D"font-family:'Helvetica'; color:rgba(0, 0, 0, 1.0);"><b>To: =
</b></span><span style=3D"font-family:'Helvetica';">Mike Belshe <<a =
href=3D"mailto:mike@belshe.com">mike@belshe.com</a>><br></span></div><d=
iv style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px;"><span style=3D"font-family:'Helvetica'; color:rgba(0, =
0, 0, 1.0);"><b>Cc: </b></span><span =
style=3D"font-family:'Helvetica';">Tim Bray <<a =
href=3D"mailto:tbray@textuality.com">tbray@textuality.com</a>>, James =
M Snell <<a =
href=3D"mailto:jasnell@gmail.com">jasnell@gmail.com</a>>, Mark =
Nottingham <<a href=3D"mailto:mnot@mnot.net">mnot@mnot.net</a>>, =
HTTP Working Group <<a =
href=3D"mailto:ietf-http-wg@w3.org">ietf-http-wg@w3.org</a>><br></span>=
</div><br><div><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"><div style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><blockquote type=3D"cite"><div dir=3D"ltr">Agree =
with Tim; I am also in support of 100% TLS all the =
time.</div></blockquote><div><br></div><div>Here are some nice quotes =
from the EFF about the system you are supporting (without any =
explanation):</div><div><br></div><div><blockquote style=3D"margin: 0 0 =
0 40px; border: none; padding: 0px;"><i>As we learned from the <a =
href=3D"https://www.eff.org/observatory">SSL Observatory</a> project, =
there are <a href=3D"https://www.eff.org/files/colour_map_of_CAs.pdf">600+=
Certificate Authorities</a> that your browser will trust; the attacker =
only needs to find one of those 600 that she is capable of breaking =
into. This has <a =
href=3D"https://www.eff.org/deeplinks/2011/03/iranian-hackers-obtain-fraud=
ulent-https">been</a> <a =
href=3D"https://www.eff.org/deeplinks/2011/08/iranian-man-middle-attack-ag=
ainst-google">happening</a> with <a =
href=3D"https://www.eff.org/deeplinks/2011/09/post-mortem-iranian-diginota=
r-attack">catastrophic =
results</a>.</i></blockquote></div><div><br></div><blockquote =
style=3D"margin: 0 0 0 40px; border: none; padding: =
0px;"><i>Certificate-based attacks are a concern all over the world, <a =
href=3D"https://twitter.com/#%21/csoghoian/status/111416087979114497">incl=
uding in the U.S.</a>, since governments everywhere are eagerly adopting =
spying technology to eavesdrop on the public. Vendors of this technology =
<a href=3D"http://files.cloudprivacy.net/ssl-mitm.pdf">seem to suggest =
the attacks can be done =
routinely</a>. </i></blockquote><div><div><br></div><div>In many =
cases, people's lives are literally ended (or destroyed) because of this =
system.</div><div><br></div><div>I do not support such a system, and am =
very suspicious of folks voicing their support without a word of =
explanation.</div><div><br></div><div>I am reminded of how easy it is =
for a malicious entity to infiltrate a group and manipulate their =
opinion through sock-puppets. Not to say that you are one, but it's =
something that I'm reminded of each time I come across these types of =
situations.</div><div><br></div><div>Let's not have another NSA/NIST =
situation =
here.</div><div><br></div><div>Links:</div><div><br></div><div><a =
href=3D"https://www.eff.org/deeplinks/2011/03/iranian-hackers-obtain-fraud=
ulent-https">https://www.eff.org/deeplinks/2011/03/iranian-hackers-obtain-=
fraudulent-https</a></div><div><a =
href=3D"https://www.eff.org/deeplinks/2011/09/post-mortem-iranian-diginota=
r-attack">https://www.eff.org/deeplinks/2011/09/post-mortem-iranian-digino=
tar-attack</a><br><div><br =
class=3D"webkit-block-placeholder"></div><div>Cheers,</div><div>Greg</div>=
<div>
<br>--<br>Please do not email me anything that you are =
not comfortable also sharing with the NSA.<br>
</div>
<br><div><div>On Nov 13, 2013, at 1:14 PM, Mike Belshe <<a =
href=3D"mailto:mike@belshe.com">mike@belshe.com</a>> wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
dir=3D"ltr">Agree with Tim; I am also in support of 100% TLS all the =
time.<div><br></div><div>I would like us to do both Mark's =
proposals:</div><div> (A) opportunistic upgrade of =
http to SSL</div><div>and</div><div>
(C) HTTP/2.0 is TLS all the =
time.</div><div><br></div><div><div>Mike</div><div><br></div></div></div><=
div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed, Nov =
13, 2013 at 9:46 AM, Tao Effect <span dir=3D"ltr"><<a =
href=3D"mailto:contact@taoeffect.com" =
target=3D"_blank">contact@taoeffect.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
style=3D"word-wrap:break-word"><div class=3D"im">On Nov 13, 2013, at =
12:31 PM, Tim Bray <<a href=3D"mailto:tbray@textuality.com" =
target=3D"_blank">tbray@textuality.com</a>> wrote:<blockquote =
type=3D"cite">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div>Let=92s not let the perfect be the enemy of =
the good.</div><div><br></div><div>FWIW, here=92s one voice in support =
of HTTP/2=3D=3DTLS.</div></div></div></div></blockquote>
<br></div><div><div dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div>Not much content there supporting your vote. =
:-(</div><div><br></div><div>A vote doesn't count (in my book at least), =
if it doesn't have strong rationale before it.</div>
<div><br></div><div>To me this also comes across as security theater =
(what a wonderful expression).</div><div><br></div><div>Let's get this =
clear:</div><div><br></div><div>1. Perfection is not being requested. =
Just something other than "abysmal".</div>
<div><br></div><div>2. TLS that depends on CAs is not by any means =
"good". It is <b>bad.</b> Very bad. I would even support a =
viewpoint that says it's worse than HTTP because of the false sense of =
security that it gives people.</div>
<div><br></div><div>- Greg</div></div></div></div></div><div =
class=3D"im"><div>
<br>--<br>Please do not email me anything that you are =
not comfortable also sharing with the NSA.<br>
</div>
<br></div><div><div class=3D"h5"><div><div>On Nov 13, 2013, at 12:31 PM, =
Tim Bray <<a href=3D"mailto:tbray@textuality.com" =
target=3D"_blank">tbray@textuality.com</a>> =
wrote:</div><br><blockquote type=3D"cite"><div dir=3D"ltr">
On Wed, Nov 13, 2013 at 9:22 AM, James M Snell <span dir=3D"ltr"><<a =
href=3D"mailto:jasnell@gmail.com" =
target=3D"_blank">jasnell@gmail.com</a>></span> wrote:<br><div =
class=3D"gmail_extra"><div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex">To be honest, much of this comes across =
to me as knee-jerk security<br>
theater. Sure, using TLS is a good thing, but by itself it doesn't<br>
come even remotely close to dealing with the range of fundamental<br>
security and privacy issues that have come to light over the past =
few<br>
months. If not handled properly, it could definitely give a false<br>
sense of security.<br></blockquote><div><br></div><div>Let=92s not let =
the perfect be the enemy of the good.</div><div><br></div><div>FWIW, =
here=92s one voice in support of HTTP/2=3D=3DTLS. And another =
saying let=92s not give up on opportunistic encryption.</div>
=
<div><br></div><div><br></div><div><br></div><div> </div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">
<br>
<div><br>
On Wed, Nov 13, 2013 at 2:01 AM, Mark Nottingham <<a =
href=3D"mailto:mnot@mnot.net" target=3D"_blank">mnot@mnot.net</a>> =
wrote:<br>
</div>[snip]<br>
<div>><br>
> The most relevant proposals were:<br>
><br>
<br>
</div>FWIW, I intend to make another proposal once (a) the base =
http/2<br>
protocol is complete and (b) protocol extensions have been dealt =
with<br>
properly.<br>
<br>
[snip]<br>
<div>><br>
> As a result, I believe the best way that we can meet the goal of =
increasing use of TLS on the Web is to encourage its use by only using =
HTTP/2.0 with https:// URIs.<br>
><br>
<br>
</div>-1. HTTP/2 should not be limited to TLS only. If someone wishes =
to<br>
craft text that strongly encourages use of TLS in specific<br>
applications of HTTP/2, then that would be fine. But the protocol<br>
itself should not require it.<br>
<div><br>
> This can be effected without any changes to our current document; =
browser vendors are not required to implement HTTP/2.0 for http:// URIs =
today. However, we will discuss formalising this with suitable =
requirements to encourage interoperability; suggestions for text are =
welcome.<br>
><br>
<br>
</div>FWIW, I have to concur with the others on this thread, Mark. =
The<br>
language you're using here makes it sound like the decision has<br>
already been made.<br>
<div><br>
> To be clear - we will still define how to use HTTP/2.0 with http:// =
URIs, because in some use cases, an implementer may make an informed =
choice to use the protocol without encryption. However, for the common =
case -- browsing the open Web -- you'll need to use https:// URIs and if =
you want to use the newest version of HTTP.<br>
><br>
<br>
</div>Again, -1 to making this a normative requirement. Our task ought =
to be<br>
ensuring that people who bother to read the specification are fully<br>
informed of the choices they are making, and not to make those =
choices<br>
for them. Yes, I get it, some security is better than no security, =
but<br>
adding constraints that only partially address the problem, just<br>
because it makes us feel good or because it looks better from a PR<br>
perspective, is not the right approach.<br>
<br>
What I think would be helpful is taking some time to draw up a =
description of:<br>
<br>
1. The specific types of threats to HTTP/1.1 and HTTP/2 we feel =
are<br>
significant.<br>
2. The specific types of threats we collectively feel ought to =
be<br>
addressed by HTTP/2, and the ones we feel are beyond our scope<br>
3. A broader list of options for how those threats can be =
mitigated<br>
<br>
In other words, an I-D describing the relevant threat model.<br>
<br>
Once we have that, we can make a more informed collective decision.<br>
<span><font color=3D"#888888"><br>
- James<br>
</font></span><div><br>
> This is by no means the end of our security-related work. For =
example:<br>
><br>
> * Alternate approaches to proxy caching (such as peer-to-peer =
caching protocols) may be proposed here or elsewhere, since traditional =
proxy caching use cases will no longer be met when TLS is in wider =
use.<br>
><br>
> * As discussed in the perpass BoF, strengthening how we use TLS =
(e.g., for Perfect Forward Security) is on the table.<br>
><br>
> * A number of people expressed interest in refining and/or =
extending how proxies work in HTTP (both 1.0 and 2.0), as discussed in =
draft-nottingham-http-proxy-problem (among many other relevant =
drafts).<br>
><br>
> Furthermore, other security-related work in the IETF (see the =
perpass BoF) and elswhere (e.g., W3C) may affect HTTP. For example, a =
number of people have pointed out how weaknesses in PKIX affect the =
Web.<br>
><br>
> Your input, as always, is appreciated. I believe this approach is =
as close to consensus as we're going to get on this contentious subject =
right now. As HTTP/2 is deployed, we will evaluate adoption of the =
protocol and might revisit this decision if we identify ways to further =
improve security.<br>
><br>
><br>
<br>
</div></blockquote></div><br></div></div>
</blockquote></div><br></div></div></div></blockquote></div><br></div>
=
</blockquote></div><br></div></div></div></div></blockquote></div><br></di=
v></body></html>=
--Apple-Mail=_268E6A21-B7D1-498E-8843-EA90897F5F4C--
--Apple-Mail=_207AC540-BB39-496E-8820-D37CD35DD182
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQEcBAEBCgAGBQJSg8eSAAoJEKFrDougX6FkoT4IAL43/MdrwM/sUpn2avrZhLhf
Obls4NhoMKGsS9pFkQCspAM94Y4Wvd+42Irw2kKTZCCd89R4GwEugq++vNnaaGIZ
0VWzE2Z7ihOZi0M06AhaiZo9kNRCCSbYkMLD5W7D8aJRRPeWy3qfTut68EdWoEhz
09gxgIrnK+4cwVFtNFvXswhRLqlqflfSUCs96h9TqIYnYdcnUzCqldbGowfZyOUM
26K4A2Ox5A6f4KZQgRSpG2yFROZ4RkP+qlr2ZyWBidz/k0YyjvHZ5WdaCTjeS4Ch
EjeenOQjKnO/krdJgfNAuHMX1vQq7ULf190CnoS3A47WmEDV4V4vKU/z5hDUTf4=
=T42+
-----END PGP SIGNATURE-----
--Apple-Mail=_207AC540-BB39-496E-8820-D37CD35DD182--
--===============8717850461779798119==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============8717850461779798119==--
