Re: #612: 9.2.2 requirements

> On Oct 31, 2014, at 1:35 PM, Mark Nottingham <mnot@mnot.net> wrote:
> 
>> On 27 Oct 2014, at 1:54 pm, Mark Nottingham <mnot@mnot.net> wrote:
>> 
>> <https://github.com/http2/http2-spec/issues/612>
>> 
>> Reviewing the discussion, I think it’s going to be difficult to declare consensus on 9.2.2 in its current form.
> 
> And yet, I get the big bucks* from the IESG to do the difficult things. Winning a straw poll is not necessarily consensus in the IETF.
> 
>> Talking through it with a few of the proponents, my proposal to close this issue is to remove 9.2.2 (i.e., the specific requirements on cipher suites), but leave 9.2.1 (the section on TLS features) as-is.
> 
> Talking it through at length with our Area Director and other IETF leadership, this will not fly (at least that easily). 
> 
> The fundamental technical issue — publishing a protocol standard that allows cipher suites that we know to be insecure — has not been addressed. Patrick is absolutely right about this.

They are not insecure, just not modern. There is a huge difference. If they were insecure, you wouldn’t be able to use them with H1 today and TLS 1.2 today, they would be blacklisted.

>  
> 
> The question at hand is what interoperability cost is involved in 9.2.2. If it is a cost paid by a few implementations who don’t have adequate APIs immediately at hand, that is emphatically *not* a technical issue. 

AFAIK there is exactly *one* TLS implementation out there that has nearly adequate facilities, NSS.

> 
> If it were a considerable interoperability cost to the whole community — i.e., it caused long-term problems across most or all deployments of the new protocol — it would be serious enough to warrant consideration. 
> 
> So far, this does not seem to be the case; a significant number of browser vendors have said that they will not fall back to HTTP/1.1 if they see servers that cause them to throw INADEQUATE_SECURITY, thereby isolating those servers that are not conformant (and giving them a *very* strong incentive to become conformant). Even if they were to retry, it would not be an interoperability issue; only a performance degradation for non-conformant servers.

Thats not true, the problem can occur with a conforming implementation.

> 
> In other words, while 9.2.2 may retard deployment of the new protocol while some implementations are updated to support it, it does not seem to put the entire effort at risk of interoperability problems.
> 
> The arguments that this is a process or layering issue are not valid; both have been refuted.

It would be great to hear the refutation to Microsoft’s position that the UTA is more appropriate for mandating TLS implementation API enhancements, and not the HTTP WG:

http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0114.html
 

> While some may consider the handshake “fragile”, they’ll need to explain how — given the above context — it affects interoperability in a way that’s significant. So far, I haven’t seen an explanation of how the handshake raises such an issue.
> 
> If you think you have one, please carefully explain it to us (even if you have before — and thank you for your patience) soon. Without more (and convincing) information,

Ilari’s use case is a great example of where it all goes wrong:
http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0167.html

I summarized the only known non-fragile handshaking solutions here:
http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0198.html


> we don’t have adequate reason to remove 9.2.2 from the specification, and therefore I think that the resolution that gets us to consensus on #612 is Martin’s first pull request:
> 
>  https://github.com/http2/http2-spec/pull/615
> 
> Sorry for the back-and-forth; it’s important to get this right.

Agreed. It’s not unsolvable. 

> 
> Regards,
> 
> 
> * If I’m really lucky, Barry will buy me a drink in HNL.
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 
> 

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

Received on Friday, 31 October 2014 19:43:03 UTC