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

[Ben Schwartz <[e-mail]>]

On Fri, Dec 10, 2021 at 12:58 PM Viktor Dukhovni <[e-mail]>
wrote:

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

This is interesting, but I think it's orthogonal.  That vulnerability
analysis applies equally before and after this draft.

I'd be happy to add a reference to draft-barnes-dane-uks to the text, but
since that draft expired several years ago, I think we would need a new or
updated draft first.

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

Yes, the intent is to incorporate that behavior by reference without
restating it.  I've proposed an adjustment to this text for improved
clarity: https://github.com/bemasc/svcb-dane/pull/3/files.

More generally, the goal is to be able to treat each connection attempt
with exactly the same logic, whether or not SVCB is used.  SVCB produces a
TargetName, which (if securely resolved) can then be passed into the RFC
7671 machine exactly as if it were the original name.

3.  Are the targets of SVCB/HTTPS records allowed to be CNAME aliases?


Yes: Section 3 of draft-ietf-dnsop-svcb-https-08 says "the TargetName MAY
be the owner of a CNAME record".


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


I can see the appeal of the CNAME-expansion behavior, but it also strikes
me as an awkward compromise.

Diverging from RFC 7671 here seems a bit unfortunate.  I would prefer to
Update RFC 7671 to deprecate the complex CNAME behavior, but I'm not sure
whether that's really possible now.

There are also some nontrivial privacy implications due to the effect on
SNI.


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


This doesn't seem like a very good optimization.  For optimal latency, the
client would issue any queries as soon as it can.

  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.


Let me try to understand.  RFC 4035 says:

> a recursive name server MAY set the AD bit when a response includes
unsigned CNAME RRs if those CNAME RRs demonstrably could have been
synthesized from an authentic DNAME RR that is also included in the response

Are you referring to the case where the recursive resolver does _not_ do
this?  In that case, the client cannot simply fail when AD=0, because it
would break compatibility with DNAME.

This is interesting, but it seems like a generic problem with DNAME and the
AD bit, not a problem specific to DANE or to this draft.

  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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>