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

[Viktor Dukhovni <[e-mail]>]

On Mon, Dec 13, 2021 at 10:04:55AM -0500, Ben Schwartz wrote:

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

Correct, but since draft post-dates the UKS I-D, it is worth keepin the
latter in mind.  And an update to 767[123] may be warranted (based on
the "UKS" I-D).

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

Likely so, or it can be incorporated into a separate update document, if
that's deemed more efficient.  With DANE working group no longer around,
would "dnsop" be an appropriate home for such work?

> 2.  In 7671 CNAME chasing for the target zone is more detailed than in this
> > draft.
> 
> 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.

I'll take a look soon.

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

I think that mechanism alignment makes sense, the key question is
whether this is an opportunity to reconsider some of the RFC7671
choices.  In particular, CNAME chasing may have been too much
effort for too little gain.

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

So this is different from the situation with MX (and IIRC SRV) records,
so perhaps CNAMEs will be much more common in this context?  But if so,
one can always publish parallel CNAMEs:

            example.org. IN HTTPS 0 www.example.org.
            www.example.org. IN CNAME example-org.cdn.example.
            _443._tcp.www.example.org. IN CNAME _443._tcp.example-org.cdn.example.

The downside is that some CDN customers would need to more explicitly
opt-in to DANE, it would no longer be sufficient for the TLSA records to
be present on the provider side of the CNAME chain.

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

For SMTP it turns out that such CNAME chain TLSA records are not
especially common, but perhaps with SVCB/HTTPS they'd prove more
useful?  This is worth a second look, I don't have a strongly held
view either way at this point.

I think it is definitely possible, and 6 years later (8 from the time
that work on 7671 started) is a reasonable time to revisit the
decisions.  The protocol is pretty much only used in SMTP, and it
would not be too difficult to deprecate CNAME chasing.  Just a few
MTAs to update (Postfix, Exim, Halon, PowerMTA, Cisco ESA, and a few
more).

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

Can you be more explicit about this?  Which is the better privacy
outcome, using the initial or expanded name in SNI?  The SNI name is
IIRC encrypted in TLS 1.3, so perhaps this is not a long-term issue?

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

It is very much *NOT* an optimisation.  Rather it is an essential
element of robustness of the protocol in the face of the reality
of the DNS ecosystem:

    - For DANE to be useful it must not be trivially subject to
      downgrade by not responding to TLSA records, returning REFUSED,
      NOTIMP, SERFVAIL or bogus replies.

    - However, many unsigned zones are served by functionally limited
      to mostly-broken load-balancers that just know how to return
      A/AAAA records and not much else.

    - When you send a TLSA query to such a nameserver, you often end
      up with a lookup failure, rather than a valid "insecure" denial
      of existence (proof of an insecure delegation at some parent
      node + insecure NODATA or NXDOMAIN).

    - For DANE to avoid downgrades, TLSA query SERVFAIL needs to lead
      to connection failure.

This is why the "optimisation" in question is in fact an essential
element of 7671.

I should also mention that "opportunistic" here is a much broader class
of applications that one might think.  It covers applications that
strictly perform peer authentication, but whose use of DANE is "when
published", rather than as an exclusive authentication mechanism.

So any application that has a fallback to some other way of establishing
trust when the peer does not have TLSA records is one where the above is
applicable.  This is perhaps something we should discuss off-list on a
voice call to make sure we're on the same page...

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

No, I am talking about a situation where AD=0 despite the fact that the
original name is in a signed zone, because the target of the CNAME
lookup is not in a signed zone:

    ; signed zone
    www.secure.example. IN CNAME www.insecure.example.
    www.secure.example. IN RRSIG CNAME 13 3 ...
    _443._tcp.www.secure.example. IN TLSA 2 1 1 ...
    _443._tcp.www.secure.example. IN RRSIG TLSA 13 5 ...

    ; unsigned zone
    www.insecure.example. IN A 192.0.2.1

An "A" record query for "www.secure.example" via recursive resolver will
return an insecure answer" with AD=0:

    www.secure.example. IN CNAME www.insecure.example.
    www.insecure.example. IN A 192.0.2.1

but there are in fact signed TLSA records for the qname.  The alias
from a secure to an insecure zone may happen at a later "hop" in
the CNAME chain, if it is longer than one element.

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

The issue is not about DNAMEs.

-- 
    Viktor.