On 15/11/2016 07:36, "TLS on behalf of Martin Thomson" <tls-boun...@ietf.org on behalf of martin.thom...@gmail.com> wrote: >On 15 November 2016 at 16:12, Nikos Mavrogiannopoulos <n...@redhat.com> >wrote: >> TLDR; the privacy offered by this extension is the same as the privacy >> of DTLS over UDP. > >I disagree. All the privacy considerations of the QUIC connection ID >apply here. It would probably pay to follow that discussion. > >If the intent of this is simply to deal with the NAT rebinding issue, >then I think that this is worth doing, but to say that this does not >have privacy issues would be overstating the case.
I agree. We had previous discussion on and off list about this and we took Stephen's point to look at ways to make this identifier privacy friendly. The draft proposes two ways to allocate the identifier (see 3rd para of https://thomas-fossati.github.io/draft-tls-cid/#rfc.section.1): 1. Server decides unilaterally a value that is fixed for the duration of the session (SecAssocType.fixed); 2. Server and Client agree on a sequence of values generated using HOTP [RFC 4226] seeded by the session shared secret (SecAssocType.hotp); Client shifts to the next value when needed (e.g. on transport handover). At first this might not look particularly elegant, but there are good reasons for having both methods. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
