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

From: Ben Schwartz <[email-masked]>
Date: Thu, 9 Dec 2021 17:32:30 -0500

Hi DNSOP,

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.

Thanks,
Ben Schwartz

---------- Forwarded message ---------
From: <[email-masked]>
Date: Thu, Dec 9, 2021 at 5:18 PM
Subject: New Version Notification for draft-rebs-dnsop-svcb-dane-00.txt
To: Benjamin M. Schwartz <[email-masked]>, Robert Evans <
[email-masked]>

A new version of I-D, draft-rebs-dnsop-svcb-dane-00.txt
has been successfully submitted by Benjamin Schwartz and posted to the
IETF repository.

Name:           draft-rebs-dnsop-svcb-dane
Revision:       00
Title:          Using Service Bindings with DANE
Document date:  2021-12-09
Group:          Individual Submission
Pages:          9
URL:
https://www.ietf.org/archive/id/draft-rebs-dnsop-svcb-dane-00.txt
Status:         https://datatracker.ietf.org/doc/draft-rebs-dnsop-svcb-dane/
Html:
https://www.ietf.org/archive/id/draft-rebs-dnsop-svcb-dane-00.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-rebs-dnsop-svcb-dane

Abstract:
   Service Binding records introduce a new form of name indirection in
   DNS.  This document specifies DNS-Based Authentication of Named
   Entities (DANE) interaction with Service Bindings to secure endpoints
   including use of ports and transports discovered via Service
   Parameters.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Source for this draft and an issue tracker can be found at
   https://github.com/bemasc/svcb-dane.

The IETF Secretariat

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 10 Dec 2021 12:57:46 -0500

> On 9 Dec 2021, at 5:32 pm, Ben Schwartz <[email-masked]> 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.

---

From: Philip Homburg <[email-masked]>
Date: Sat, 11 Dec 2021 12:24:13 +0100

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

There is something I don't understand about this draft.

Support an attacker creates attack[1-3].example.com with 3 different setups:
1) attack1.example.com has a regular PKI cert and the attacker runs a 
   reverse proxy there that relays traffic to victim.example.com
2) attack2.example.com has a self signed cert and DANE with both
   attack2.example.com and victim.example.com in the DNS names of the cert.
   Again the attacker has a reverse proxy and relays to victim.example.com
3) attack3.example.com has a DANE record that refers to the cert of
   victim.example.com. There the attacker directly relays traffic to 
   victim.example.com.

>From the point of view of the victim client, how are these three setups
different? What makes it that 1) and 2) are fine, but 3) is not.

The only hint I can find in the draft is that when a client connects to
both attack3.example.com and victim.example.com, finds that both use the
same public key, that the client somehow merges them into a single security
context.

How does that work with CDNs? Does every CDN have a unique public key per
hosted client site?

In my experience, a hard part of PKI certs is to make sure that every name
that can be used to reach the cert is infact listed in the certificate.
It would be way better if for DANE, no name checks are done at all.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 11 Dec 2021 23:27:24 -0500

> There is something I don't understand about this draft.

The main thing to understand is that complex applications like browsers
allow data retrieved from one endpoint to script interaction with a
*different* endpoint, and possibly see the retrieved content, subject to
various CORS (Cross-origin resource sharing) controls.

If the client uses the same (client) certificate to identify itself to
both the attacker and victim servers, then if it believes that the
victim server is the same origin as the attacker's server, it may allow
cross-origin requests between them.

> Suppose an attacker creates attack[1-3].example.com with 3 different setups:
>

This does not achieve client cert authentication to victim server.

>    Again the attacker has a reverse proxy and relays to victim.example.com

This does not achieve client cert authentication to victim server.

>    victim.example.com. There the attacker directly relays traffic to 

This does would achieve client cert authentication to victim server, if
the client does not perform certificate name checks.

> It would be way better if for DANE, no name checks are done at all.

For applications other than browsers, sure.  Browsers go out of their to
run code served by the remote server, and then try to make that somehow
safe.  It's a miracle they sometimes succeed.

-- 
    Viktor.

---

From: Philip Homburg <[email-masked]>
Date: Sun, 12 Dec 2021 09:49:57 +0100

>various CORS (Cross-origin resource sharing) controls.

Indeed this is subject to CORS. Nothing new here. Any browser needs to get
this right.

>cross-origin requests between them.

This is broken. There is no reason why a client cerficate should lead the
browser to believe that two sites are the same.

As you describe above, we have CORS headers for that.

In particular, an attacker can always accept a client certificate. If
the mere acceptance of a client cert causes confusion, then the client is
already in deep trouble.

>This does not achieve client cert authentication to victim server.

Indeed. The draft does not mention client certs at all.
Where does that come from?

>the client does not perform certificate name checks.

Which is fine, because this connection is still secure. 

Note that the server gets a request asking for attack3.example.com. So
this should immediately return a failure.

Of course, if the server ignore the host header and then sends private
information to client only based on the client cert, this will cause the
client to be confused.

>safe.  It's a miracle they sometimes succeed.

It seems that this is an attempt to solve an insecure server problem at
the client in the context of clients with certificates.

It is a pity that the draft doesn't spell that out at all.

The web security is already complex enough. Maybe we should not fix broken
servers in the client by adding obscure requirements to DANE certificate
processing.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 12 Dec 2021 15:14:41 -0500

> Indeed this is subject to CORS. Nothing new here. Any browser needs to get

Perhaps I failed to explain the issue, but that does not mean that there
is no issue.

The browser may be communicating with a victim server believing its name
to be the same as the attacker's server, and therefore allowing attacker
served scripts (from a prior connection) to script the interaction with
the victim server.  The victim server may believe it has a secure
connection with the client (based perhaps a client-certificate-signed
handshake) and may allow it retrieve sensitive data.

Cookie-based authentication does not appear to be vulnerable here, since
the browser would presumably not send victim site cookies to a site
it believes to be the attacker.

If the victim site uses https, but authenticates clients by internal IP
alone, again there could be an issue.

I don't know how to explain this better, you could ask on a cryptography
or TLS-related forum, this is DNSOP, where the expertise tends to be of
a different nature.

-- 
    Viktor.

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 13 Dec 2021 10:04:55 -0500

>     validate the target name against the server certificate even with

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.

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

>     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
>     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
>     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
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 13 Dec 2021 14:06:50 -0500

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

> since that draft expired several years ago, I think we would need a new or

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?

> clarity: https://github.com/bemasc/svcb-dane/pull/3/files.

I'll take a look soon.

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

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

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?

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

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.

> AD bit, not a problem specific to DANE or to this draft.

The issue is not about DNAMEs.

-- 
    Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 13 Dec 2021 20:01:29 +0000

> would "dnsop" be an appropriate home for such work?

That would likely be much worse than creating a DNAEbis WG and having the couple of DANE-related documents there.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Mon, 13 Dec 2021 15:08:00 -0500 (EST)

> That would likely be much worse than creating a DNAEbis WG and having the couple of DANE-related documents there.

I agree :)

Paul

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 22 Dec 2021 15:52:22 -0500

On Mon, Dec 13, 2021 at 2:07 PM Viktor Dukhovni <[email-masked]>
wrote:

> should also

I don't want this draft to become an omnibus update to RFC 7671.  My goal
is to produce a short draft that is basically parallel to RFC 7673.

If you want to pursue a broader revamp of DANE, I think that could be
valuable, but I don't think it needs to be connected to this.

> would "dnsop" be an appropriate home for such work?

I'm not a relevant chair, but perhaps the DANISH charter could be expanded
to include "any corrections and deprecations needed to simplify correct
usage of DANE".  After all, DANISH clients would likely also be DANE
clients, and overcomplicated client logic would be unwelcome in an IoT
context.

> so perhaps CNAMEs will be much more common in this context?

I think it's too early to predict the popular deployment strategies here.
Also, SVCB + TLSA is "green field" territory, so it's up to us what we want
to allow.

> outcome, using the initial or expanded name in SNI?

Generally the expanded name, as it is likely to reveal less information
(when combined with the destination IP address, which is necessarily
public).  However, in practice the TargetName is expected to already be
generic, and CNAME-after-SVCB should be rare, so this is likely not a major
issue when SVCB is actually in use.  It's more relevant in the case of
fallback to non-SVCB connection.

>   The SNI name is

TLS 1.3 doesn't encrypt the SNI by itself.  TLS 1.3 "Encrypted ClientHello"
(now in interop testing) does, but it is not final, and is far from trivial
to deploy.

> This is why the "optimisation" in question is in fact an essential

If it's an essential element of 7671, maybe it should be mentioned in 7671!

I think this is an interesting workaround, but I'm not sure it will be
necessary here.  SVCB is to a large extent a "green field" territory, which
may exclude a lot of buggy legacy systems.  Also, SVCB specifically renders
this kind of misbehavior into a hard-fail condition already [1], and
large-scale experiments have confirmed that this does not result in a
significant error rate.

[1]
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-08#section-3.1

> > > local recursive resolver and trusting its "AD" bit.
...

> but there are in fact signed TLSA records for the qname.

Yes, so the client issues a query for TLSA at
_443._tcp.www.secure.example.  This seems like the standard RFC 7671 CNAME
handling.  There is no need for the client to issue a query with
QTYPE="CNAME".