I have not looked at this draft yet, but what about DTLS/UDP? Jim
> -----Original Message----- > From: TLS <tls-boun...@ietf.org> On Behalf Of Tommy Pauly > Sent: Wednesday, March 20, 2019 3:00 PM > To: Martin Thomson <m...@lowentropy.net> > Cc: tls@ietf.org > Subject: Re: [TLS] draft-kinnear-tls-client-net-address comments > > The QUIC and TLS drafts were written together, and are quite similar as you > note. The intention is to use the TLS extension over TLS/TCP connections, > and the QUIC extension for QUIC/UDP. > > I agree that QUIC as a protocol benefits more from the extension than TLS > does, but applications on top of both can benefit by detecting NATs, for > making decisions about long-lived connections and privacy mitigations. > > Thanks, > Tommy > > > On Mar 20, 2019, at 2:26 AM, Martin Thomson <m...@lowentropy.net> > wrote: > > > > I see a substantially similar draft in draft-pauly-quic-address-extension. I'd > like to understand how these might be complementary, or whether the idea > is to pursue only one. The QUIC extension seems superior, if you have QUIC. > There are a lot more plausible reasons to want this information in QUIC > though. > > > > Nits: > > > > The format of the extension is not ideal. Wouldn't you want to know which > family it came from? > > I think the intention was to use the length to infer the family. > > > > The term of art is reflexive address (or reflected address). > > Thanks, good to know! > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
