Re: 9.2.2, Rough Consensus, and Working Code

> On 6 Nov 2014, at 4:15 pm, Greg Wilkins <gregw@intalio.com> wrote:
> 
> 
> On 6 November 2014 14:28, Mark Nottingham <mnot@mnot.net> wrote:
> Dare I say MAY?
> 
> You MAY say MAY,  but increased flexibility with the interpretation of 9.2.2 requirements just makes it all the more important to have a robust handshake.
> 
> Let's consider the original interoperability problem that raised this issue and consider how MAY would help or hinder.
> 
> I ran Jetty's http2 server on Java-7, which has no ciphers that are satisfactory with regards to 9.2.2.

Then it's not conformant to 9.2.2. This is not an interop problem -- it's a failure to conform.

As I explained, the only way we can consider this an interop issue is if it affects the ecosystem in such a way that it seriously retards deployment of the protocol (i.e., it puts it at risk). One -- or a handful -- of implementations that can't conform with their current APIs is NOT a technical issue.

Yes, I realise that's... not great... for some, but I think that's where we're at. However, I don't think it's that dim -- see below.


> FF offered a connection with a cipher set that included both 9.2.2 acceptable and non acceptable ciphers.    Jetty's http2 implementation did not implement 9.2.2 and choose to accept whatever cipher was negotiated based on what the client offered and how the JVM had been configured (as a recently released and still supported JVM, it had no known weak ciphers), together with h2.       FF then applied it's 9.2.2 implementation and rejected the connection.      Thus we failed to communicate even though both client and server spoke h1 and h2, and both were configured with recently updated black/white lists of acceptable ciphers.    All we did was turn on h2 support and this caused a server from being able to communicate with a client.  Turning off h2 support in either the client or the server allowed connections to succeed.
> 
> In the current draft, the fault for this interoperability failure was with Jetty, as we did not implement 9.2.2.        I looked into implementing 9.2.2 and discovered that not only are unable to affect cipher negotiation, but that we have no API with which to query cipher properties.     The only implementations of 9.2.2 that are available to use are basically regex and/or name white/black lists, so that this would leave our interpretation of 9.2.2 subject to configuration and future changes to cipher naming conventions.  If we are ever configured with a different interpretation of 9.2.2 than our clients, then connections can fail even if there are mutually acceptable ciphers/protocols.    Thus was born the fragile handshake issue.

Most servers have exposed the black/white lists as configuration metadata, and presumably will give guidance / good defaults to the admin to assure that it will be 9.2.2-conformant. Why is this not adequate, until you have appropriate APIs in place?


> 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.

Well, it makes it a conformance issue at runtime, one that will be very evident once the admin points Firefox or Chrome at the server. AIUI the idea is that they'll self-correct (quickly).


> 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.  

I know, I think most people feel like that. All I can do is continue to try to move the discussion forward. At some point, I'll have to call consensus, and I'm hoping we can find more common ground than we have now before doing so.

Regards,


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

Received on Thursday, 6 November 2014 05:40:56 UTC