Re: 9.2.2, Rough Consensus, and Working Code

There are two problems with it:

1. Many (GNU TLS, OpenSSL, MS SPI, and Apple SecureTransport for sure) have no API to control the order of cipher suites

2. It still forbids the use of non-conforming ciphers which can only be enforced after a successful TLS negotiation if an endpoint wants to support both HTTP/1 and HTTP/2.

Sent from my iPad

> On Nov 6, 2014, at 12:40 AM, Mark Nottingham <mnot@mnot.net> wrote:
> 
> I'd really like to hear what people think about this; it might need some wordsmithing around "unknown", etc. but it's a fairly small change...
> 
> 
>> On 6 Nov 2014, at 4:26 pm, Jason Greene <jason.greene@redhat.com> wrote:
>> 
>> 
>>> On Nov 5, 2014, at 11:15 PM, Greg Wilkins <gregw@intalio.com> wrote:
>>> 
>>> If we replace MUST with MAY, this make the handshake fragility a much greater interoperability problem.   If the server MAY respond with INADEQUATE_SECURITY, then it also MAY NOT.   Jetty's deferral of cipher selection to the TLS layer will now be spec compliant and the failure to connect even though there were shared ciphers and protocols because a real problem today rather than a possible problem when faces with hypothetical future cipher names.  This makes the handshake broken rather than fragile.
>>> 
>>> I know I sound like a scratched record - but we MUST have a robust handshake that does not rely on how we "think" ciphers will evolve.  
>> 
>> Hi Greg, can you take a look at the small proposal I sent a few days ago. I think its closer to what you are looking for:
>> https://github.com/http2/http2-spec/pull/639/files
>> 
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
>

Received on Thursday, 6 November 2014 11:12:19 UTC