Suppose a query a known signed zone:
Q: _25._tcp.mail.example.com. IN TLSA ?
and I receive a signed CNAME referral:
A: _25._tcp.mail.example.com. IN CNAME 3.1.1._tlsa.example.edu.
and suppose further that the example.edu zone is unsigned with FWIW
an insecure (zone is not signed) TLSA record published there:
3.1.1._tlsa.example.edu. IN TLSA 3 1 1 <hash and eggs>
Is this a a case of "no TLSA records" or "no usable TLSA records"?
The domain owner of the secure zone thought they were publishing
TLSA records, so one might think (draft-ietf-dane-srv) that one
MUST use TLS for this service (be it with whatever non-DANE policy
applies when one does that).
On the other hand, the error is rather similar from an implementation
sanity viewpoint to a failure to find validated records, as opposed
to use of parameters not understood by the client, ...
The simplest stub resolver logic for DNSSEC when chasing CNAMEs is
to return the boolean AND of the validation status of the final
answer with the status for any CNAMEs chased along the way. All
this is nicely layered inside a library (so the application does
not have to do the chasing itself), and now it is impossible to
distinguish between the first zone being unsigned, and some
intermediate CNAME being unsigned.
So to retain some implementation sanity I'd like to vote for "not
found" rather than "unusable", though the owner of "example.com"
may be surprised by the outcome, it is IMHO his fault for CNAMEing
the TLSA at a domain outside his control. We can reasonably hope
such cases will be rare, and that domains once signed, will mostly
tend to stay signed.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
