Re: [DNSOP] New Version Notification for draft-rebs-dnsop-svcb-dane-00.txt

[Viktor Dukhovni <[e-mail]>]

> On 9 Dec 2021, at 5:32 pm, Ben Schwartz <[e-mail]> wrote:
> 
> This is a very small draft explaining how to do DANE with SVCB, mostly following the pattern of DANE-SRV.  It also updates DANE for use with QUIC.
> 
> Please review.

Initial observations:

1.  While DANE certificate validation as described in RFCs 7671,7672 and 7673
    is fine in SMTP, IMAP, XMPP, ... for HTTP (and perhaps some other applications)
    skipping validation of the target name with DANE-EE(3) records introduces a "UKS"
    (i.e. "Unknown Key Share") issue, that would definitely be a concern for "h3".

    https://datatracker.ietf.org/doc/html/draft-barnes-dane-uks-00

    Thus, unless "UKS" is known to not be a concern, applications should also
    validate the target name against the server certificate even with DANE-EE(3).

2.  In 7671 CNAME chasing for the target zone is more detailed than in this draft.

	* Either every record in a chain of CNAMEs leading to an unaliased target
          is "secure" (DNSSEC-signed and validated), and there's an associated
          TLSA record for the end of the chain.  In which case that's used.

        * Or else, the TLSA record lookup is performed at the initial unaliased
          target.

    There are no "middle of chain" TLSA lookups, or TLSA lookups at the end of a
    chain that is not end-to-end secure.

3.  Are the targets of SVCB/HTTPS records allowed to be CNAME aliases?  Experience
    since 7672 was written shows that TLSA records at CNAME-expanded targets are
    rare, and supporting these correctly is complex.  Also the original target
    owners can, if they wish explicitly redirect their TLSA records to point at
    the TLSA records expected at the expanded name.

    So perhaps adding CNAME-expansion into 7672/7671 was a mistake.  There's
    an opportunity here to not repeat it if that's the case.  Mind you aliased
    MX exchange names are a violation of RFC5321 (one that's tolerated by many
    MTAs, some obliviously, because they just look up IP addresses without taking
    steps to exclude possible CNAME expansion along the way).

4.  If there are opportunistic applications in scope for this draft, they may
    want to follow the advice of 7672 to only check for TLSA records if the
    target zone is determined to be signed after first performing the IP (v4/v6)
    address lookup.  Here a related CNAME detail comes into scope, the target
    zone may be signed, but the CNAME expanded zone with the IPs might not.

    Therefore, if HTTPS/SVCB targets are allowed to be aliased, the client
    would have to issue an explicit "CNAME query" in the address lookup
    comes back as an "insecure" answer via CNAME/DNAME expansion.  This
    assumes that the client is delegating DNSSEC-validation to a local recursive
    resolver and trusting its "AD" bit.  If the client is doing its own DNSSEC
    validation, its DNS library will know whether the origin of the CNAME chain
    is secure or not, and this information may be available to the client without
    a follow-up explicit type "CNAME" lookup (to suppress CNAME expansion).

-- 
	Viktor.