On 08/26/2015 09:52 PM, Viktor Dukhovni wrote:
On Wed, Aug 26, 2015 at 09:43:39PM -0700, Alice Wonder wrote:
Furthermore, support for 1->3 mappings might lead users to erroneously
expect 0->2 mappings, but the latter are in fact problematic. So
supporting neither of the potential mappings is simpler and cleaner.
Okay, thank you.
so
1 [0|1] 1 hash
is not incorrect, just useless for opportunistic.
Yes, liable to be treated as "unusable", and thus lead to mere
unauthenticated TLS (analogous to Postfix "encrypt" security level).
Is it safe to assume there are not any (current) downsides to using
1 [0|1] 1 hash
w/ submission port 587?
Given that there are no MUAs that support DANE, there's no upside
either. As I said before, there is no security advantage to
publishing "1 1 1" over "3 1 1", unless the latter is prohibited
by the application protocol. When you think you want to publish
"1 1 1", you're likely misled by bad advice, and should use
"3 1 1" instead.
Note that just because your certificate might be issued by some
public CA is not reason to use a "1 1 1" TLSA record, certificates
issued by public CAs (often via "intermediate issuers) are just as
compatible with "3 1 1" as any other end-entity (leaf) certificate.
Thank you. I think the root of my confusion may have been that TLSA as
written gives the impression (at least to me) there is value to
specifying a signed cert is signed in the TLSA record, but it seems that
nothing implementing DANE actually benefits from that.
Maybe 0 and 1 for Certificate Usage field should be deprecated in DANE
altogether, especially if there ever are plans to move away from
Certificate Authorities in the future.
