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

[Yoav Nir]

> On 25 Mar 2019, at 19:38, Hubert Kario  wrote:
> 
> On Monday, 25 March 2019 19:31:24 CET Yoav Nir wrote:
>>> On 25 Mar 2019, at 19:23, Hubert Kario  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 
  
 >> ?  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. 


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Hubert Kario]

On Monday, 25 March 2019 19:31:24 CET Yoav Nir wrote:
> > On 25 Mar 2019, at 19:23, Hubert Kario  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 
> >> > ?  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

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

> On 25 Mar 2019, at 19:23, Hubert Kario  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  
>> > ?  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.

Yoav

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Hubert Kario]

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

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

[Yoav Nir]

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