The sample size of responses seems too small to reach a meaningful
consensus.
Perhaps posting something a bit more controversial will get the
silent majority to speak up. :-) To wit:
- Assign explanatory names only to usages 2 and 3:
2 - TRUST-ANCHOR
3 - END-ENTITY
- Since usages 0/1 merely complicate DANE implementation without[*]
enhancing security, they can remain anonymous, or be given names
that clearly indicate that these are discouraged/deprecated.
0 - SECURITY-THEATRE-0
1 - SECURITY-THEATRE-1
This would remove all confusion about the DANE usages. If someone
can justify the existence of 0 and 1 in a pair of pithy acronyms
then those are the names. Otherwise, out they go!
[ I have begun design/implementation of general-purpose DANE support
for OpenSSL. Supporting all four usages is rather more complex
than one might imagine, and is largely wasted effort, but the
protocol requires 0/1 for now, so I have no choice. I would be
thrilled to bits were the above to be taken seriously, and usages
0/1 dropped from DANE TLSA in a future revision of the protocol. ]
--
Viktor.
* If DNSSEC *is not* compromised, 2/3 are sufficient.
If DNSSEC *is* compromised, the attacker will publish 2/3, thus
a domain owner's use of 0/1 offers no protection against DNS attacks.
There will be no measurable deployment of out-of-band mechanisms
that harden 0/1 or application protocols that implement DANE, with
just usages 0 and 1.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
