From: DNSOP <[email protected]> on behalf of Viktor Dukhovni <[email protected]>
Quoting from the draft: ... > If the initial TLSA base domain is the start of a secure CNAME chain, > clients MUST first try to use the end of the chain as the TLSA base > domain, with fallback to the initial base domain, as described in > Section 7 of [RFC7671]. ... If we don't expect prolific use of SVCB or HTTPS targets that are in turn CNAMEs, perhaps it is time to reconsider the advice in 7671 which was written when operational experience was still evolving. As an interim step, what do you think about this addition: https://github.com/bemasc/svcb-dane/pull/6/files ? My hope is that this gives us room to make a change like you're imagining in the future, while also ensuring that a client for this draft can be implemented entirely as a wrapper around an existing, non-SVCB-aware DANE implementation. > If a TLSA RRSet is securely resolved, the client MUST set the SNI to > the TLSA base domain of the RRSet. In usage modes other than DANE- > EE(3), the client MUST validate that the certificate covers this base > domain, and MUST NOT require it to cover any other domain. Note that after 7671 was published it was pointed out by Richard Barnes in https://datatracker.ietf.org/doc/html/draft-barnes-dane-uks-00 that not verifying the server name with DANE-EE(3) is problematic in the web browser use-case, because it can lead to cross-origin issues that are absent in protocols such as SMTP. FWIW, I believe that draft overlooks the defense against misdirected requests in HTTP: https://datatracker.ietf.org/doc/html/rfc9110#name-rejecting-misdirected-reque. I believe that UKS attacks are not possible from HTTP/1.1 onwards. Therefore, barring specific knowledge that the application protocol in question faces no similar issues, the certificate name should by default always be checked. This is reflected in the OpenSSL DANE implementation, which requires a non-default flag to turn off name checks when validating a peer via a matching DANE-EE(3) TLSA record. I don't think it helps to check the certificate against the TLSA base domain, if (as here and in SRV) the TLSA base domain is independent of the original QNAME. Perhaps you mean to check it against the original QNAME, but this seems extremely limiting, as it would prevent a CDN from publishing a single TLSA record for use by numerous customers. How about this text on the topic: https://github.com/bemasc/svcb-dane/pull/7 ? ...
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
