In https://tools.ietf.org/html/draft-ietf-dane-srv-02#section-3.2 we have:
The client SHALL construct the TLSA query name as described in
[RFC6698] section 3, based on fields from the SRV record: port from
the SRV RDATA, protocol from the SRV query name, and the TLSA base
domain is the SRV target host name.
thus in case a target hostname in the SRV RR is a CNAME:
_imap._tcp.example.com. IN SRV 0 0 143 imap.example.com.
imap.example.com. IN CNAME mail.example.net.
mail.example.net. IN A 192.0.2.1
the associated TLSA RRset would be at:
_143._tcp.imap.example.com.
rather than:
_143._tcp.mail.example.net.
I would like to suggest that this choice is not robust:
- It creates an unexpected difference between two previously
equivalent configurations:
; SRV target is an alias
_imap._tcp.example.com. IN SRV 0 0 143 imap.example.com.
; SRV target is the underlying host
_imap._tcp.example.com. IN SRV 0 0 143 imap.example.net.
In both cases the service end-point is the same, and a TLSA
association may well be published by the example.net service
provider. However, the domain owner who decided to be flexible,
and point at the provider through an alias misses out on the
TLSA record.
- It creates difficult to manage synchronization problems:
If the domain owner is aware of the TLSA association not
"following the CNAME", and decides to publish:
_143._tcp.imap.example.com. IN TLSA ?
he cannot simply clone the provider's TLSA record, for this
can change without coordination with the referring domain.
Also the use of TA associations would be problematic, as the
verifier would be looking for the wrong names in the service
provider's certificate.
Alternatively, he has to delegate to the service provider a
a certificate + private key pair, and rely on SNI support in
the server and all verifiers to make this work. A service
provider hosting a large number of domains would have to
securely manage a large number of keys, carefully coordinated
with the published TLSA records of the referring domains.
I think we can do much better than that, by eliminating the complexity:
- When target hostname of an SRV record is a CNAME, the verifier MUST
follow the CNAME (making sure each CNAME record traversed is DNSSEC
validated).
- The name used to construct the TLSA query domain is the final
validated hostname.
- The name verified in the peer certificate (when name checks are
appropriate) is the final validated hostname.
This substantially reduces the chances of outages when SRV records
use indirection. This also removes the need for SNI (which is not
universally supported) and the concomitant operational headaches
of moving key material across organizational boundaries.
Unlike browsers which expect to find the hostname from the URL
in the peer certificate (since CNAMEs are not assumed secure
pre DNSSEC), the TLSA verifier obtains all CNAMEs with DNSSEC
validation, and can safely follow these to the right base name
for the TLSA lookup.
Basing TLSA lookups on the canonicalized name substantially reduces
opportunities for errors (outages) and removes the associated need
for SNI support and cross-org key management headaches.
Please consider changing the draft accordingly. The Postfix DANE
implementation follows CNAMEs (in MX RRs, but these as you well
know are simplified SRVs) before doing TLSA lookups.
I should note that I've read:
https://tools.ietf.org/html/rfc6698#appendix-A.2.1
and have come to the conclusion that the content there serves to
explain the risks of mixing CNAMEs with TLSA records, and should
be viewed as "what to avoid" guide rather than "what to do" guide.
I don't see an explicit directive in 6698 to use one particular
base domain over another. The various dangerous corner cases
brought to light in A.2.1 strongly motivate a preference for using
the real hostname (post all alias expansion) as the base domain
for TLSA records.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
