What "mandatory to offer" means

To add some nuance - I believe I said that "mandatory to offer" would be the *effect* of the path proposed, *if* some clients choose not to negotiate for HTTP URLs over HTTP/2 without encryption.

I.e., we might not even make encryption mandatory to offer with a MUST. By giving the client more power to choose when encryption is used, we effectively create a market, avoiding the need to impose this kind of deus ex machina requirement. 

What's really being discussed is the creation of a profile of HTTP2-over-TLS for HTTP (not S) URIs, which can be negotiated for (just as the same thing without encryption can be negotiated for). 

We have a lot of things to discuss around what that profile looks like; e.g., whether cert validation should take place. Since the negotiation mechanism itself is vulnerable to a downgrade attack, and since HTTP URIs don't have a strong security semantic, it may be reasonable to assume that certs for HTTP URIs shouldn't be validated -- which would ease deployment considerably. Like I said, though, there will need to be a lot of discussion.

The high order bit here is that with an appropriate negotiation mechanism, we have a powerful way to re-mix the mapping of HTTP onto lower-layer substrates, whether that be TCP, SCTP, Minion, QUIC or TLS. That flexibility is a way to address the varying needs of the protocol's users without putting MUSTs into HTTP/2. If we get to a place where we have rough consensus that having such a requirement improves interop (e.g., a minimum 'profile set'), that's great, but I don't think we necessarily need the requirement to make it work.

Cheers,


On 25/08/2013, at 5:07 PM, William Chan (陈智昌) <willchan@chromium.org> wrote:

> Just chiming in here since I'm concerned that a misinterpretation of the minutes may have led to an accidental straw man argument.
> 
> Eliot, can you clarify what section of the minutes you're responding to? I see only one hum for HTTP/2:
> """
> Who believes that these issues are worthy of further discussion: Hum in
> support:strong hum. Hum against: silence. Good, and we are now at the end of
> the alloted time for this.
> """
> 
> I don't see anything on humming on mandatory encryption. I note that there's a section of the minutes where Larry and Mark are clarifying the topic, since Larry said the topic was introduced as mandatory to implement security, whereas Mark clarified:
> """
> Mark says “mandatory to offer” is closer
> to what he said.
> """
> 
> So, I don't believe "mandatory encryption" was even discussed at the last IETF, merely mandatory to offer [i forget if it was security or encryption, but I suspect encryption]. And let's be precise about the language, since security != encryption. You mentioned encryption, and then talked about certificate warnings. Let's remember you can try to encrypt without authenticating the peer.
> 
> Now, we can have a debate about whether or not mandatory encryption is security theater, but I think no one is beating that drum right now (although I won't preclude the possibility of someone stepping up to do so). So it's probably best to stick to the topic that we discussed at the last IETF, namely mandatory to offer [encryption?], unless someone would like to discuss mandatory encryption right now.
> 
> Cheers.
> 
> 
> On Sun, Aug 25, 2013 at 2:16 PM, Eliot Lear <lear@cisco.com> wrote:
> Mark,
> 
> Regarding the minutes of the group, the working group declined to
> mandate encryption for a number of reasons, not just back end services.
> What I said the last time, was that we can damage overall Internet
> security by inuring people to certificate warnings – or we will inhibit
> adoption of HTTP2 – unless the mechanisms to manage certificates
> improve.  In addition many thousands of small devices exist without a
> simple means to enroll – and pay.  Even if they do enroll – and pay, the
> current certificate mechanisms require that they re-enroll - and pay.
> And so they don't.  There simply is no magic bullet.  The economics are
> clear.  The means to encrypt has existed nearly two decades.   Mandating
> encryption from the IETF has been tried before – specifically with IPv6
> and IPsec.  If anything, that mandate may have acted as an inhibitor to
> IPv6 implementations and deployment and served as a point of ridicule.
> 
> And so, I do not agree with those who hummed in favor of mandatory
> encryption.  HTTP2 is already very complex and is biting off enough.
> The more it bites off the less likelihood of broad adoption.  We've seen
> this movie before.  What we will have instead of HTTP/2 will be an
> optional alternative to HTTP/1.1 that is deployed by large scale high
> performance services.  Maybe that was always the goal, but if so, let's
> recognize that and relabel.  I was under a different impression.
> 
> If we wish to explore new means to authenticate endpoints, that would be
> a better starting point.
> 
> Eliot
> 
> 

--
Mark Nottingham   http://www.mnot.net/

Received on Sunday, 25 August 2013 23:59:52 UTC