> On 9 Dec 2021, at 5:32 pm, Ben Schwartz <bem...@google.com> 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.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
