[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    [TLS] Very rough proposal for QUIC-ish SNI-encryption-compatible flow
From:       Andy Lutomirski <luto () amacapital ! net>
Date:       2014-05-16 17:56:57
Message-ID: CALCETrUSWE_hx1b13LbGqYfn3h0VgC4BhUV1=57EAr6MPQ2xTw () mail ! gmail ! com
[Download RAW message or body]

Here's my rough proposed flow.

This have the property that all TLS 1.3 successful connections have
exactly the same set of messages exchanged and the same kind of
transcript.  This may make this a lot easier to understand.


A successful TLS 1.3 connection attempt looks like:

ClientHello
Cleartext extensions
KeyID [may be 0 for plaintext]
MaskSessionKey [starts blank]
Masked {
 ClientHello
 SNI
 Encrypted server hello keying material
 Server mask key [same cipher as for KeyID, but w/o DH]
 DH share, Client Random, Ciphersuites, Enxrypted extensions
}

                                             ServerHello
                                             ServerMaskPolicy
                                             Masked {
                                               ServerSupportedGroups
                                               Server random, cert, etc.
                                               [or "wrong DH group", try again]
                                             }

This can restart for three reasons:

1. The mask id is some special flag that asks the server for a valid
ServerMaskPolicy.

2. The server hello keying material was on the wrong group.  The
server should send ServerMaskPolicy, which must include a list of
acceptable groups for the server hello keying material.  (It can
suggest sending SNI in the clear.)

3. The client's DH share was on the wrong group.  The server should reply
with ServerSupportedGroups.

Handshake restarts clear all state, except that, after a restart,
clients must verify that ServerMaskPolicy and ServerSupportedGroups
(depending on where the restart was) are exactly what the client
expected.  This is critical to prevent downgrade.

Notes:

The server hello encryption group is in ServerMaskPolicy because, in
the event of a failure to encrypt the server hello, the server can't
safely send ServerSupportedGroups without weaking SNI encryption.

This needs to be massaged into a state in which the unmasked case will allow
TLS 1.2 and below servers to handshake.  This may be easy.

ServerSupportedGroups are a lot like PredictedParameters.

ServerMaskPolicy is a list of valid DANISH B-style associations.

It may be acceptable for the client's DH shares to be identical.  A real
cryptographer should confirm.  We could require this in the unencrypted
SNI case (i.e. require the client to choose the same share and group
when possible) to avoid allowing a client to force a server to do
an extra DH computation.

--Andy


[prev in list] [next in list] [prev in thread] [next in thread]