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
