I think I might have guessed the reasoning.
The IETF draft is rather long, hard for me to read it, I will try but I
lose concentration quickly, and I did not detect the reason within it.
I think however that maybe the issue has to do with DANE libraries.
If a 0 x x or a 1 x x record is used, then a DANE validation library
must verify the certificate with the CA chain of trust for the library
to give a return value of success.
With a 2 x x or a 3 x x record, it only has to validate the DNSSEC and
that the certificate sent matches the record.
So with MTA servers on port 25 where they very well may not have a
comprehensive PKI including the the myriad of CAs, signed certificates
will fail DANE validation if sent as 0 x x or 1 x x because the library
can not verify the CA chain of trust.
If that is the issue, I would suggest such validation libraries have a
relaxed mode where they don't need to do CA chain of trust validation in
cases where all that is needed is hostname validation.
That way system administrators don't have to mis-represent the
certificate being used.
Or the DANE RFC could be updated to specify that 2 and 3 can be used
with signed certificates as long as hostname validation is all that is
needed for the provided port and protocol.
On 08/21/2015 10:41 PM, Alice Wonder wrote:
I received a rather weird e-mail, it seems to have been generated by an
MTA because it was sent to the e-mail listed as the contact in my
certificate, the e-mail listed in whois for my domain, and the
postmaster e-mail.
It claims:
---
Only certificate usages DANE-TA(2) and DANE-EE(3) are supported
with SMTP. See:
https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-3.1.3
---
The certificate is a 1 0 1 and not a 3 0 1
It seems to suggest that I change the TLSA record to 3 0 1
-=-=-
I get that other SMTP servers shouldn't be expected to do CA validation,
but should one really mis-identify a CA signed cert as self-signed just
because the other MTAs are not going to be able to validate it?
It seems more logical to me that if an MTA is using DANE validation and
encounters a certificate with a 0 or 1 that it treat the certificate as
if it was a 2 or 3 rather than asking the other MTA to mis-identify the
certificate.
A certificate has to be used for TLS communication, whether it is
self-signed or not doesn't matter - the TLSA fingerprint can still be
validated whether it is a 1 0 1 or 3 0 1 TLSA entry.
So why would an IETF draft suggest that they shouldn't be used?
It seems logical to me that if two parties are communicating via TLS and
one of the parties is using DANE to validate but is not doing CA
validation, that it should treat 1 x x the same as 3 x x and 0 x x the
same as 2 x x.
Expecting administrators with signed certificates to break the RFC for
DANE just because some (all?) MTAs will not check with a CA seems bad.
What am I missing?
