On Monday, 25 March 2019 14:58:29 CET Yoav Nir wrote: > 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.
how is it property of device? at best, it's a property of a LAN. And a LAN may have multiple Internet uplinks, every other connection may end up with a different IP (albeit from a small pool), so a public IP of any particular connection does not reliably indicate public IP of subsequent connections. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
