Yeah, so this looks very much like the IKE mechanism (the draft even says so)
In IKE the reason for this is to detect NAT because IPsec does not traverse NAT. We need to detect the NAT so as to choose an IPsec variant that traverses NAT. If the server (or IKE Responder) lies, you might use the NAT Traversing method when it’s not required, or if the server is really good at lying, you might not use NAT Traversal when you should. With the proposed TLS extension, I would like to see a better analysis for what happens if the server lies. What happens if the client uses the answer to do geolocation? We can easily take this to a “gay kid in Uganda” scenario. But I think the more interesting question is why do it at this layer? Why not use some web service such as the API version of https://www.whatismyip.com <https://www.whatismyip.com/> ? The answer is a property of the device, not to the socket. We might as well have the device figure this out. Yoav > On 25 Mar 2019, at 12:24, David Schinazi <dschinazi.i...@gmail.com> wrote: > > Hi Tommy, thanks for the presentation. > > I do not think the draft succeeds at addressing its goals. The mechanism is a > fine way for the client to receive its public address (assuming the server is > honest) but I can't see anything useful the client can do with that > information. > > 1) Keepalives > The client cannot adjust its keep alive timeouts based on this > information because the network could contain stateful firewalls that require > keepalives similar to NATs but are not detectable this way because they do > not change addresses. > > 2) Unique Identifiers > The presence of a NAT does not provide client privacy guarantees. It is > trivial for network operators to deploy NATs that still allows 1-to-1 mapping > of public address+port to private address+port. The most common example is > NPT66. Therefore you cannot use this information to decide whether to reuse > DoT connections. > > 3) ASN > If the goal is for the client to find its ASN, you might as well build a > mechanism for the server to send the ASN to the client instead of its > address. Otherwise you will need to save the entire database of > address-to-ASN mappings on all clients which isn't feasible on smartphones. > > Thanks, > David > _______________________________________________ > 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
