Re: [TLS] draft-kinnear-tls-client-net-address comments

I have not looked at this draft yet, but what about DTLS/UDP?

Jim

> -----Original Message-----
> From: TLS <tls-bounces@ietf.org> On Behalf Of Tommy Pauly
> Sent: Wednesday, March 20, 2019 3:00 PM
> To: Martin Thomson <mt@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 <mt@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