Re: [DNSOP] DNSOPReminder: Please review draft-ietf-dnsop-svcb-dane

[Viktor Dukhovni <[e-mail]>]

Ben Schwartz <bemasc=[e-mail]> writes:

> I wanted to remind DNSOP to take another look at
> draft-ietf-dnsop-svcb-dane [1], which is intended as a straightforward
> clarification of how DANE interacts with SVCB/HTTPS records (and
> QUIC/HTTP/3).  I don't think this document is controversial, and I'd
> like to proceed to WGLC soon.

Quoting from the draft:

>    3.  Using DANE with Service Bindings
>
>       Section 6 of [RFC7671] says:
>
>	  With protocols that support explicit transport redirection via DNS
>	  MX records, SRV records, or other similar records, the TLSA base
>	  domain is based on the redirected transport endpoint rather than
>	  the origin domain.
>
>       This draft applies the same logic to SVCB-compatible records.
>       Specifically, if SVCB resolution was entirely secure (including any
>       AliasMode records and/or CNAMEs), then for each connection attempt
>       derived from a SVCB-compatible record,
>
>       *  The initial TLSA base domain MUST be the final SVCB TargetName
>	  used for this connection attempt.  (Names appearing earlier in a
>	  resolution chain are not used.)
>
>       *  The transport prefix MUST be the transport of this connection
>	  attempt (possibly influenced by the "alpn" SvcParam).
>
>       *  The port prefix MUST be the port number of this connection attempt
>	  (possibly influenced by the "port" SvcParam).
>
>       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].

I should perhaps mention, without necessarily implying a burden on this
draft to correct the past sins of others (primarily myself), that the
CNAME chasing of the target specified in RFC7671 was in retrospect
perhaps a mistake:

        - CNAMEs in MX records are rarely used.  At least in SMTP the
          vast majority of published TLSA records are direct.
          CNAME-derived TLSA base domains occur only in:

		* 182 out of 20,397 MX host TLSA base domains
                * 3,035 out ouf 4,053,744 email domains

                (less than 0.5% or even 0.1% of cases).

	- Such CNAME chasing is not compatible with the DANE chain
          extension:
          https://datatracker.ietf.org/doc/html/rfc9102#section-3
          https://datatracker.ietf.org/doc/html/rfc9102#name-virtual-hosting

        - It is difficult to explain to implementors and users.

        - If deduplication for the TLSA RRSet across multiple aliases to
          the same ultimate host is desired, a parallel CNAME can always
          be added:

            some.host.example. IN CNAME other.host.example.
            ; Choose either of the below:
            _8080._tcp.some.host.example IN CNAME _8080._other.host.example.
            _tcp.some.host.example IN DNAME _tcp.other.host.example.

However, if CNAME chasing is no longer required then the final server
may need to present a much more diverse set of certificates, with a
matching name for each alias, rather than just one for the
CNAME-resolved name.  Of course in a mixed ecosystem with only some
clients supporting DANE, the server will need to do that anyway (with
even more names for the various domains at the start of the SVCB or
HTTPS indirection).


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.

>       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.

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.


>    5.1.  Recommended configurations
>
>       Service consumers are expected to use CNAME or SVCB AliasMode to
>       point at provider-controlled records, e.g.:
>
>       alias.net.                  HTTPS 0 xyz.provider.com.
>       www.alias.net.              CNAME xyz.provider.com.
>       xyz.provider.com.           HTTPS 1 . alpn=h2 ...
>       xyz.provider.com.           A     192.0.2.1
>       _443._tcp.xyz.provider.com. TLSA  <provider keys>

In particular if CNAME chasing for the TLSA base domain is dropped,
then it may be appropriate to also publish:

    _443._tcp.www.alias.net. IN CNAME _443._tcp.xyz.provider.com.

>       For ease of management, providers may want to alias various TLSA
>       QNAMEs to a single RRSet:
>
>       _443._tcp.xyz.provider.com. CNAME dane-central.provider.com.
>       dane-central.provider.com.  TLSA  <provider keys>

The latter primarily when using DANE-TA(2) records with a shared issuer
for all the servers.  In less common cases with distributed service
clusters employng multiple names, but a shared underlying public key,
DANE-EE "3 1 1" records could also be dedupplicated as above.

>    5.2.  Accidental pinning
>
>       When a service is used by third-party consumers, DANE allows the
>       consumer to publish records that make claims about the certificates
>       used by the service.  When the service subsequently rotates its TLS
>       keys, DANE authentication will fail for these consumers, resulting in
>       an outage.  Accordingly, zone owners MUST NOT publish TLSA records
>       for public keys that are not under their control unless they have an
>       explicit arrangement with the key holder.

Sound advice.  This problem is quite rare, but has of course been
observed.  Now and then some vanity-domain owner will publish TLSA RRs
for an MX host is logically in the user's domain, but whose IP address
is that of their email provider.

>       To prevents the above misconfiguration and ensure that TLS keys can
>       be rotated freely, service operators MAY reject TLS connections whose
>       SNI does not correspond to an approved TLSA base domain.

Sure, break early, even if the keys happen to match.

>       This document only specifies the use of TLSA records when the SVCB
>       records were resolved securely.  Use of TLSA records in conjunction
>       with insecurely resolved SVCB records is not safe in general,
>       although there may be some configurations where it is appropriate
>       (e.g. when only opportunistic security is available).

This roughly matches the Postfix "half-dane" feature, where securely
published TLSA records for an MX host obtained via insecure DNS are
honoured, but the connection is not logged as "verified".  This helps
to integrity protect audit logs (yes you really did reach that MX host
if it has signed TLSA RRS), but not delivery (the attacker could have
redirected the delivery elsewhere via forged MX records).

No strong opinion on whether similar considerations apply in non-SMTP
contexts.


>    7.3.  QUIC and CNAME
>
>       Given service URI https://api.example.com and records:
>
>       www.example.com.  CNAME api.example.com.
>       api.example.com.  HTTPS 1 svc4.example.net alpn=h2,h3 port=8443
>       svc4.example.net. CNAME xyz.example-cdn.com.
>
>       If the connection attempt is using HTTP/3, the transport label is set
>       to _quic; otherwise _tcp is used.
>
>       The initial TLSA QNAME would be one of:
>
>       *  _8443._quic.xyz.example-cdn.com
>
>       *  _8443._tcp.xyz.example-cdn.com
>
>       If no TLSA record is found, the fallback TLSA QNAME would be one of:
>
>       *  _8443._quic.svc4.example.net
>
>       *  _8443._tcp.svc4.example.net

See tedious discussion above, perhaps only the "svc4" names should be
used???

-- 
    Viktor.