Re: Concluding discussion on #612 (9.2.2)

On Wed, Oct 8, 2014 at 6:17 AM, Ilari Liusvaara
<ilari.liusvaara@elisanet.fi> wrote:
> The problems with 9.2./9.2.2.
> - It allows endpoints to assume properties of ciphersuites, instead of
>   requiring querying TLS stack at runtime, leading to serious risk of
>   interop failure[1][4][6].

On the other hand, allowing implementations leeway in handling this
may improve interop, at least in the short term, until more
server-side TLS stacks are extended to provide better support for
this.

> - It does not require server to enforce the restrictions on handshake time
>   [1].
> - It allows server to send GOAWAY(INADEQUATE_SECURITY). This is never
>   necressary if the handshake actually worked[5].
> - It allows advertising HTTP/2 if ClientVersion is not maximal (fallback).
>   Using non-maximal ClientVersion is just asking for trouble[2].

I support adding language to 9.2.2 that says something like "If the
client's TLS ClientHello.client_version indicates a version lower than
TLS 1.2, then the client MUST NOT offer HTTP/2 in its ALPN extension."
After all, it doesn't make sense for the client to offer HTTP/2 in a
configuration where it is guaranteed to reject it.

> - It contains no explicit requirement for client to finish handshake even
>   if requirements fail. Any behaviour change as response to aborted handshake
>   is no-no[2].

Such a requirement would be harmful. In fact, I wish the requirement
went the other way: If the client detects that the minimum
requirements in 9.2.2 are not met and HTTP/2 is negotiated, then the
client MUST NOT complete the handshake. Otherwise, you have to worry
about the server pushing application data to the client between the
time the client finishes the handshake and the time that the client
sends the INADAEQUATE_SECURITY message. (I can see how this race could
occur and be problematic in the Firefox implementation, for example,
because Firefox is likely to finish the handshake well before it
considered it safe to send the INADAEQUATE_SECURITY message.)

> - It is confusing, especially some of the examples confuse instead of clarify
>   (the mentions of AEAD and AES-GCM are the worst[3]). And getting these
>   things wrong causes interop problems.

I agree that the attempts to clarify in 9.2.2 that AEAD cipher suites
and AES-GCM are acceptable seem to be having the
opposite-from-intended effect on clarifying things.

> - It wrongly assumes DHE and ECDHE are the only PFS key exchanges.

Do you have a suggestion for improving that?

Cheers,
Brian

Received on Wednesday, 8 October 2014 16:38:25 UTC