Re: Concluding discussion on #612 (9.2.2)

On Tue, Oct 07, 2014 at 09:10:01PM -0400, Patrick McManus wrote:
> 
> 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.

Then 9.2/9.2.2 should explicitly call out requirements for TLS stacks
for reliable operation, even if no current TLS stack meets those.

Regarding application protocols standardization, when faced with bad
or even nonexistent support for required features, some back off, some
don't.

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].
- 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].
- 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].
- 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.
- It wrongly assumes DHE and ECDHE are the only PFS key exchanges.


The "fragility" some have talked about is the first two plus the confused
interpretations.

Note that requiring TLS 1.2+ is not on this list. It is trivial to do
with present-day TLS stacks and is well-supported. Additionally, there is
plenty of percedent for requiring minimal (D)TLS versions.

Disabling RC4 specifically is not trivial to do, but still quite easy.
And if RC4 is mentioned specially, calling out concerns about it is
entierely justfied. Heck, there is "publication requested" I-D about
completely prohibiting RC4 usage in TLS.


[1] Even if this probably requires TLS stack upgrades.
[2] I hope there are no TLS libraries retarded enough for this to cause any
implementation problems.
[3] This has apparently been gotten wrong multiple people.
[4] "disable what you don't undestand" 1) May not be reliable, 2) May lead
to actually more secure stuff getting disabled (I have personally seen this
happen, and I got very annoyed).
[5] RST_STREAM(INADEQUATE_SECURITY) could be useful in some cases, E.g.
buggy client trying to request https:// in plaintext. Or some special
material having even higher cipher requirements.
[6] Have the same TLS library on both sides, and sometimes one sees really
"interesting" TLS ciphersuites (fortunately those are almost invariably much
stronger than RC4-based ones).


-Ilari

Received on Wednesday, 8 October 2014 13:18:12 UTC