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

[Hubert Kario <[e-mail]>]

On Monday, 25 March 2019 19:31:24 CET Yoav Nir wrote:
> > On 25 Mar 2019, at 19:23, Hubert Kario <[e-mail]> wrote:
> > 
> > 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/>
> >> <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.
> It’s perhaps a property of the device at the current connection
> configuration. Pretty much any consumer device will have a preferred
> network where the default route is. Any phone with a metered and a
> non-metered connection will prefer the non-metered connection, and PCs will
> use the link where the default route is.  It is a reasonable approximation
> to assume that the web service connection to whatismyip will follow the
> same path as your other TLS connection.
> 
> Servers may have more complicated routing tables, where the “regular” TLS
> connection might be using a dedicated link while the connection to
> whatismyip is going to the “Internet”.  I don’t think this is the scenario
> that this draft is working on.
> 
> An interesting twist even for consumer devices may be where one of the two
> connections chooses IPv4 while the other chooses IPv6.  In that case, they
> might end up on different links if, for example, the metered connection
> offers IPv6 while the non-metered connection does not, or vice versa.

I already gave you an example of situation where that's not the case.

You can have a router with two Internet links that routes the connections to a 
different ISP either based on a round-robin fashion or as a fallback when a 
connection dies.

Neither of which would be visible to the device connected to a WiFi behind 
such a router. The client in the context of this I-D.

-- 
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