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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
