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

[Yoav Nir <[e-mail]>]

> On 25 Mar 2019, at 19:38, Hubert Kario <[e-mail]> wrote:
> 
> 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/> <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.

True.  As far as NAT detection, the answer would be the same — such a client is behind NAT regardless of which Internet link the router chooses, so keepalives are necessary anyway.  For the other use cases, I’m not so sure.  If a client has two “real” IP addresses, what is it supposed to do about identifying ASNs?  Deciding whether to reuse connections to DNS is directly related to the presence of a NAT, so it’s the same as NAT detection.