On Wed, 7 Jul 2021, Warren Kumari wrote:
"Another potential, optional mechanism for limiting the number of
queries is to assume that labels that begin with an underscore (_)
character do not represent privacy-relevant administrative
boundaries. For example, if the QNAME is "_25._tcp.mail.example.org"
and the algorithm has already searched for "mail.example.org", the
next query can be for all the underscore-prefixed names together,
namely "_25._tcp.mail.example.org"."
The description is correct....
Viktor is suggesting that QNAME Minimization should be stopped when
you run into an underscore ("_") label, instead of this being worded
as a potential, optional mechanism.
I agree. The _underscore directly conveys information about the qname
parts up to that label. There is no distinct privacy realm here, and
query minimalization SHOULD stop, and the entire QNAME should be
requested.
Obviously there is a tradeoff here -- privacy vs deployment.
1: while it's **possible** that there is a delegation point at the
underscore label, (IMO) it is unlikely. If there is no delegation, you
will simply be coming back to the same server again and again, and so
you are not leaking privacy sensitive information.
It is possible there is a delegation. For example, at Fedora we ran
into an issue that _openpgp reocrds got quite big, and a delegation
to a separate name server would have been nice. And while this may
be under a different IT branch, from a privacy point of view, it is
still within the same privacy realm.
2: some recursives are less likely to enable QNAME minimization
because of the non-zero ENT and slight performance issues.
I doubt that, but sure. auth servers could stuff it in the Additional
section too :)
What does the WG think? Does the privacy win of getting this deployed
and enabled sooner outweigh the potential small leak if there *is* a
delegation inside the _ territory of the name?
I don't think there realistically is a "potential small leak".
Should the advice above be strengthened to SHOULD / RECOMMENDED?
Yes.
Paul
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
