W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: New Version Notification for draft-nottingham-http2-encryption-00.txt

From: Eliot Lear <lear@cisco.com>
Date: Tue, 01 Oct 2013 07:57:01 +0200
Message-ID: <524A642D.7020903@cisco.com>
To: Mark Nottingham <mnot@mnot.net>
CC: "ietf-http-wg@w3.org WG" <ietf-http-wg@w3.org>

On 10/1/13 7:43 AM, Mark Nottingham wrote:

> AIUI your concern is that when this is in place, it enables an attacking intermediary to redirect links in HTML content to a site that isn't encrypted without having that redirection show up in the browser, or noticed on the server. 
> However, it *will* show up in the browser, in that the security "lock" won't be in place. 

That is not what I call a strong indication.  Want to test its
effectiveness with users?

> Furthermore, note the item in "Next Steps":
> """
> Indicating Chosen Service: It’s likely necessary for the server to know which protocol the client has chosen, and perhaps even the hostname (for load balancing). This could be conveyed as part of the “magic”, or as a request header. There are also security implications here; for example, without this information, the server doesn’t know if the client has checked the certificate, leading to a situation where an intermediary can downgrade a HTTPS connection to relaxed HTTP.
> """
> I fully expect that if we get momentum on this proposal, we'll need to look at modifying the protocol to carry this information from the UA to the origin.
>>  The mitigations for this attack are, as far as I can tell:
>> 1.  Do not have the primitive in the browser;
>> 2.  Only upgrade on the existing connection;
>> 3.  Use a DNS record instead that is signed and can be validated (I
>> don't know if this is a complete mitigation).
>> My suggestion is (2) or (3) if you're looking for OE.
>> Finally, using port 443 in the example conflicts with TLS and the
>> assignment as articulated in RFC 2818.
> The registry does not reference RFC2818:
>   <http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=443>
> It merely says "http protocol over TLS/SSL." That's what's happening here.
> More to the point, this draft is proposing a pretty fundamental change to how URI schemes map to protocols and ports, and so some adjustment of scheme and port semantics ought to be expected. 

Not to the detriment of TLS.

Received on Tuesday, 1 October 2013 05:57:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:18 UTC