Re: Concluding discussion on #612 (9.2.2)

On 08.10.2014 03:10, Patrick McManus wrote:
> 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.
An API extension just to repair something the protocol doesn't do seems 
weird. I would expect the TLS cipher negotiation and ALPN protocol 
negotiation do the right thing and not to fallback to the application.

Roland

Received on Wednesday, 8 October 2014 11:25:36 UTC