Re: [TLS] Connection ID Draft

[Benjamin Kaduk <[e-mail]>]

On 10/12/2017 06:13 PM, Eric Rescorla 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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Drescorla-2Dtls-2Ddtls-2Dconnection-2Did-2D00&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=CDf7zAKso3W-qOi8wQqK6uWaBGWhWCn6w5Q5gFHEjUY&s=1hkGM7Hn4fhvL0vEqnLxYGyRwan9tjm4IICGPgXS4eo&e=>
>
> Comments welcome.
>

I see it already got some good comments, so I'll try to stick to just
new ones.

Since a participant that wants to make use of DTLS CIDs might expect to
talk to many peers, some of which do and some of which do not support
the CID extension, it seems like the participant might want to always
use the same cid_length for all its peers that support CIDs, to ease the
parsing decision and CID lookup process, and we could mention this
expectation. Or am I missing some reason why the CID would be easy to
pick out of the ciphertext otherwise?

In the security/privacy considerations:

   An on-path adversary, who is able to observe the DTLS 1.2 protocol
   exchanges between the DTLS client and the DTLS server, is able to
   link the initial handshake to all subsequent payloads carrying the
   same connection id pair (for bi-directional communication).

My first time reading this I thought that the text was only claiming that linkability was possible if the initial handshake was observed, which is not really needed.  It might be better to avoid mentioning the handshake at all and just say that the attacker is able to link all observed payloads carrying the same connection id pair as being exchanges between the same client and server.

-Ben