Re: [TLS] Connection ID Draft

This seems like a pretty solid design.  (Better in many ways to the
QUIC design, but then I might concede that the constraints are
different.)

The example shows the connection ID only being used after the
handshake completes (that is, on epoch=3), but handshake records
(epoch=2) use the same record format and we already know the
preference of the peer when sending them.  I can see why you opted for
this design (there is no way for the server to signal that it intends
to use the connection ID before it starts to send it), but that could
be addressed by moving the extension to the ServerHello.  The value is
sent on every subsequent record, so there is no real gain in having
the extension in EncryptedExtensions.  There is value in having record
construction be consistent.

The design for new connection IDs is clearly to handle the linkability
issue, but the draft doesn't propose a solution for linking based on
the monotonic increase of sequence numbers, or acknowledge the
problem.

We had comments about the length of the connection ID and the value
being used as a covert channel.  That issue should at least be
addressed in the security considerations.

On Fri, Oct 13, 2017 at 10:13 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> Hi folks,
>
> I have just posted a first cut at a connection ID draft.
> https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00
>
> Comments welcome.
>
> -Ekr
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>