Re: Concluding discussion on #612 (9.2.2)

I strongly support 9.2.2 as written.

The big picture: We know the best practices for application protocol
security and they are reflected in 9.2.2. To mint a protocol at this point
that doesn't guarantee, for example, forward secrecy does not pay heed to
the needs of the modern day Internet and the IETF consensus that it is
being attacked by eavesdroppers  (BCP 188).

I don't find either of the common criticisms of 9.2.2 compelling. One
argument is some variation of scope and standing wrt the TLS wg. But we've
established that TLS-wg is perfectly comfortable with applications
profiling TLS, 9.2.2 is consistent with the direction of TLS 1.3, and
explicit coordination on this point was used in the authoring of 9.2.2.

The other criticism is really an API implementation concern. 9.2.2. is
robustly implemented when there is coordination between cipher suite
selection, TLS version, and ALPN selection. It is true that h2 requires new
code and new interfaces to be implemented for some TLS implementations - I
don't see why 9.2.2 is a particularly special burden in that regard. ALPN
is a useful existence proof - it is also a required part of h2, it also
requires changes to TLS libraries, and we've seen movement on adoption of
it. The internet moves on - h2 implementations will need new code; that's
not an inherent criticism of h2.

-Patrick

On Tue, Oct 7, 2014 at 8:36 PM, Jason Greene <jason.greene@redhat.com>
wrote:

>
> On Oct 7, 2014, at 1:34 PM, Albert Lunde <atlunde@panix.com> wrote:
>
> > TLS 1.2 introduces the GCM ciphers that have the "holy grail"
> properties, so
> > there's nothing wrong with parts of 1.2, it's just a question of how to
> deal
> > with the legacy ciphers. But an API that gives a version number check
> won't
> > draw the line at the right place.
>
> The desired “parts” of 1.2 happen to be the exact 1.3 restrictions. So
> what’s happening here is 9.2.2 is trying to require 1.3 semantics without
> sending the required {3, 4} version identifier during negotiation which is
> what creates these handshaking issues.
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
>