Re: reframing draft-ietf-httpbis-http2-encryption to focus on deployment aid rather than security?

I would welcome this change and be interested in implementing it in Apache httpd. My personal interest is in keeping http: alive and performing.

There are three server deployments "http:" lives right now:
A. with valid certs and acceptable security for h2
B. with certs but unacceptable security for h2
C. without certificates

While B servers should really upgrade to A. The fate of C servers is questionable. Some will become A with the help of Let's Encrypt or StartSSL and others, either migrating to https: urls or using secure transport over h2. 

But I suspect a lot of C servers will not for various reasons. Offering an anonymous cipher mode with almost zero configuration would allow users to have at least protection against passive monitoring and the benefits of a HTTP/2 transport. And "users" could of course also be proxies.

If the anon cipher mode is only relevant for C, a new ALPN identifier seems only necessary for Alt-Svc. If the client then uses 'h2' in ALPN for such a connection, the server would answer with an anon cipher which the client should be then willing to accept. Or am I missing something here?

//Stefan 


> Am 14.08.2015 um 01:30 schrieb Erik Nygren <erik@nygren.org>:
> 
> Based on some discussions in Prague, one of the challenges with draft-ietf-httpbis-http2-encryption is that it is trying to serve two purposes where some trade-offs need to be made between them.
> 
> The first purpose is to enable the deployment of HTTP/2 for "http" scheme traffic over the open Internet by encapsulating it within TLS to avoid causing problems with middle boxes.  The second purpose is to defend against pervasive monitoring by purely passive adversaries.
> 
> The current document is focused on the second purpose (opportunistic security), with first (deployment aid for http scheme traffic) as a side benefit.  At least some potential implementors are more interested in this first deployment aid and have little-to-no interest in doing this purely for opportunistic security.
> 
> I'd suggest that we consider refocusing the document to treat 'deployment of HTTP/2 for "http" scheme traffic' as primary with opportunistic security against purely passive adversaries being a nice side-benefit.
> 
> This might not change too much technical content, but might change interest in implementing this functionality.  In particular on technical details:
> 
> * Clients would still want to treat this as "http" scheme traffic and show no security indicators
> 
> * We could either continue to ignore server certificate mismatches or perhaps require or strongly encourage anonymous authentication  (eg, TLS_ECDH_anon_WITH_AES_128_GCM_SHA256)
> 
> * Negotiating those mode explicitly with its own ALPN token makes some things safer and easier (although does make things marginally easier for semi-active attackers who can block those connections to force fallback, but those same attackers could just as easily try and block TLS for SNI values where HTTP cleartext sends an Alt-Svc).
> 
> Having a separate ALPN token has the benefit that it means that there would not be confusion between clients and servers about whether they support this functionality.  A risk highlighted in a mail thread a month or so ago is that many server implementations effectively ignore :scheme and look purely on the port and :origin.  While arguably a bug, this seems like a very common implementation behavior with servers negotiating the "h2" ALPN token.
> 
> For better or worse, a separate ALPN token does mean that middle boxes could terminate this traffic in cases where today they terminate clear-text http traffic as long as they correctly know how to implement HTTP/2.  If our focus is on TLS as a deployment aid for http/2 then this is not a bad thing.  And even for opportunistic security, traffic is still at least encrypted hop-by-hop on the wire, and any middle box that could do this is already an active attacker that could find some other possibly more invasive/problematic heuristic for intercepting opp sec traffic.
> 
> What are peoples' thoughts on shifting the focus in this manner?  Would it make you more or less willing to implement?
> 
>     Erik
> 
> 

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

Received on Friday, 14 August 2015 09:00:45 UTC