Re: 9.2.2, Rough Consensus, and Working Code

• From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
• Date: Thu, 6 Nov 2014 14:24:25 +0200
• To: Greg Wilkins <gregw@intalio.com>
• Cc: Mark Nottingham <mnot@mnot.net>, Patrick McManus <mcmanus@ducksong.com>, Mike Bishop <Michael.Bishop@microsoft.com>, HTTP Working Group <ietf-http-wg@w3.org>
• Message-ID: <20141106122425.GA24815@LK-Perkele-VII>

On Thu, Nov 06, 2014 at 04:15:55PM +1100, Greg Wilkins 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.

Thinking about it, I see three ways to get robust handshake with cipher
restrictions:


1) Without TLS stack support on either side:

- First handshake: Only known acceptable ciphers, TLS 1.2+, (h1+)h2.
- INADEQUATE_SECURITY is only sent for known unacceptable ciphers[1].
- Second handshake (if dual-version): All ciphers, h1.


- Implementable today in major TLS stacks.
- Sending only known acceptable ciphers in first handshake "punishes"
  bad servers (only bad crypto, not lack of h2 support) with extra
  latency.


2) Without TLS stack support on either side (dual-version): 

- First handshake: All ciphers, h1+h2.
- INADEQUATE_SECURITY is only sent for known unacceptable ciphers[1].
- Second handshake: All ciphers, h1.


- Implementable today in major TLS stacks.
- Not possible for h2-only clients (those can do 1)).
- Here there is possiblity that server picked h2 and some not-really-
  acceptable cipher (client may or may not reject).
- Second handshake is done even on INADEQUATE_SECURITY by either side
  (not doing this leads to hard interop failures[2])


3) With server TLS stack support:

- Client handshake, all ciphers, (h1+)h2.
- INADEQUATE_SECURITY is sent for known unacceptable ciphers.
- Servers only select h2 with acceptable ciphers[3][4].


- (Most?) major TLS stacks need additions.
- Server can't have unknown ciphers, because if client knows one is
  unacceptable, server can pick it with h2 and then client sends
  INADEQUATE_SECURITY. Boom.



[1] This is NOT the same as not known aceptable, since there can
be unknown ciphers.

[2] Solution: Disable h2 (client or serverside).

[3] This is exact (MUST query TLS stack for cipher properties).

[4] Server is capable of varying ciphersuite selections based on
ALPN.



-Ilari

Received on Thursday, 6 November 2014 12:24:52 UTC