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

From: David Schinazi <[email-masked]>
Date: Mon, 25 Mar 2019 12:24:17 +0100

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

---

From: Yoav Nir <[email-masked]>
Date: Mon, 25 Mar 2019 14:58:29 +0100

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 <[email-masked]> wrote:
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Hubert Kario <[email-masked]>
Date: Mon, 25 Mar 2019 19:23:50 +0100

On Monday, 25 March 2019 14:58:29 CET Yoav Nir wrote:
> 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

---

From: Yoav Nir <[email-masked]>
Date: Mon, 25 Mar 2019 19:31:24 +0100

> On 25 Mar 2019, at 19:23, Hubert Kario <[email-masked]> wrote:
> 
>> https://www.whatismyip.com <https://www.whatismyip.com/> <https://www.whatismyip.com/ <https://www.whatismyip.com/>> ?  The answer is a

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.

Yoav

---

From: Hubert Kario <[email-masked]>
Date: Mon, 25 Mar 2019 19:38:30 +0100

On Monday, 25 March 2019 19:31:24 CET Yoav Nir wrote:
> >> 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.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 25 Mar 2019 20:37:20 +0100

> On 25 Mar 2019, at 19:38, Hubert Kario <[email-masked]> wrote:
> 
>>>> <https://www.whatismyip.com/ <https://www.whatismyip.com/> <https://www.whatismyip.com/ <https://www.whatismyip.com/>>> ?  The

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.