Paul,
On 06/08/15 09:23, Paul Wouters wrote:
On Wed, 5 Aug 2015, Carsten Strotmann wrote:
for OPENPGPKEY/SMIMECERT zones, operators could (maybe SHOULD) use
NSEC/NSEC3 "narrow" signing to prevent "zone-walking".
email addresses are not secret. That is not the privacy you can protect
at all. Anyone can either do a internet search or just attempt to
deliver an email to figure out if the email address is valid.
That doesn't address my issue with this as a precedent. Nor the
case of negative DNS responses trivially leaking that someone at
my IP address wants to send a mail to <here> at this time. (And
yes, the trivially is a required part of the argument.)
And "are not secret" isn't, I think, the right comparison. For me,
the question is "if we want to experiment with user identifiers in
DNS names, can we do it in the least privacy unfriendly, but yet
practical, way as possible?"
Yes, some people may oversell the benefits of hashing or may believe
hashing is stronger than it is. Such mistaken beliefs however do not
make hashing worse than b32. Hashing is still a bit better.
I might agree but I think the gain for this is so incredibly small, that
I think the gain for use of online signers plus email address
corrections by the smtp+dnssec combined server is actually a more likely
and minorly useful thing to have.
Can you point me at a DNS server (or real specification for one)
that generates responses in any similar fashion? I'm not aware of
any that actually do, (even if they could do), but that my just be
my ignorance.
IMO even if there is a niche of DNS authoritative servers that
can operate in that manner, requiring that that niche be used
for the experiment makes it highly likely the experiment will
fail.
So my logic would be: if b32 is needed, the experiment will
likely fail as you can't do it on many servers. If b32 is not
needed, then let's just hash since that is less bad.
And don't get me wrong. I'd rather see zonefiles with a hash than with
base32 cut from an esthetical point of view.
Well, let's do that then:-)
S.
Paul
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp