[hrpc] Two examples of drafts that have political consequences

[Stephane Bortzmeyer <[e-mail]>]

If you meet people who say "IETF does purely technical work, we don't
do politics", here are two good current examples that may seem technical but
have political consequences.

The first one is the most obvious, because it has clear privacy risks
and they are acknowledged in the draft:
draft-tale-dnsop-edns0-clientid "Client ID in Forwarded DNS Queries"
proposes to add something in the DNS requests that will identify the
client. This is already done in some proprietary products like Cisco
Umbrella
<https://docs.umbrella.com/developer/networkdevices-api/identifying-dns-traffic2>,
which uses the MAC address or the device serial number.

As expected, the discussion in DNSOP was the usual "It is deployed,
better to document it, so we could at least add some protections"
vs. "Bad ideas must not be published, it may be seen as endorsment".

The second one is more subtle. draft-ietf-tls-dnssec-chain-extension
"A DANE Record and DNSSEC Authentication Chain Extension for TLS"
describes a way to send DNSSEC records required for DANE
authentication into the TLS session, instead of having to retrieve
them from the DNS. It may reduce latency, and solve some bootstrap
problems (using DANE to authentify a DNS resolver…) But a consequence
is that the TLS client must accepts the same root trust anchor as the
TLS server, which prevents the use of signed alternative DNS roots.

I do not claim it is ground for rejection, just that technical choices
constrain what you can do with the network.