Subject: [dane] UKS attacks on DANE

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Oct 2016 15:12:28 +1100

Richard, ekr and I have submitted a draft describing UKS attacks on
certain DANE usages:

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

The draft contains the details, but the short version is that usages 2
and 3 are potentially vulnerable to an unknown key share attack if the
client fails to verify the identity of the server.  Since Section 5.1
of RFC RFC 7671 explicitly states that client's should NOT verify the
identity of the server in these cases.

The draft describes how this attack can be used to circumvent
cross-origin safeguards on the web.  It also explains how to properly
avoid the attack.

As I understand it, email is believed to be unaffected since the mail
security model explicitly permits UKS attacks (MX).

Thanks to Karthik Bhargavan for pointing out this problem and in
helping to analyze it.

--Martin

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 10 Oct 2016 04:35:19 +0000

> identity of the server in these cases.

Thanks for the advance notice on this back in June.  As a result,
the DANE implementation in the OpenSSL 1.1.0 release by default
enforces name checks for all DANE certificate usages.  The
documentation mentions that for specific applications, that are
not at risk of cross-origin attacks,  may disable name checks for
DANE-EE(3), e.g. SMTP.

For the record, in RFC7671, only DANE-EE(3) was in scope for skipping
identity checks, no similar language is present for DANE-TA(2).
Indeed RFC7671 clearly states that name checks are required for
DANE-TA(2).

    https://tools.ietf.org/html/rfc7671#section-5.2

       With usage DANE-TA(2), the server certificates will need to have
       names that match one of the client's reference identifiers (see
       [RFC6125]).  When hosting multiple unrelated Customer Domains (that
       can't all appear in a single certificate), such a server SHOULD
       employ SNI to select the appropriate certificate to present to the
       client.

   https://tools.ietf.org/html/rfc7671#section-10.2

       With the exception of TLSA certificate usage DANE-EE(3), where name
       checks are not applicable (see Section 5.1), DANE clients MUST verify
       that the client has reached the correct server by checking that the
       server name is listed in the server certificate's SAN or CN (when
       still supported).  The primary server name used for this comparison
       MUST be the TLSA base domain; however, additional acceptable names
       may be specified by protocol-specific DANE standards.  For example,
       with SMTP, both the destination domain name and the MX hostname are
       acceptable names to be found in the server certificate (see
       [RFC7672]).

> security model explicitly permits UKS attacks (MX).

And I think the same analysis applies to XMPP as a result of SRV
records, and lack of cross-origin exposure.

    https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_dane_enable.html

	SSL_CTX_dane_set_flags() and SSL_dane_set_flags() can be
	used to enable optional DANE verification features.
	SSL_CTX_dane_clear_flags() and SSL_dane_clear_flags() can
	be used to disable the same features. The flags argument
	is a bitmask of the features to enable or disable. The
	flags set for an SSL_CTX context are copied to each SSL
	handle associated with that context at the time the handle
	is created. Subsequent changes in the context's flags have
	no effect on the flags set for the handle.

	At present, the only available option is
	DANE_FLAG_NO_DANE_EE_NAMECHECKS which can be used to disable
	server name checks when authenticating via DANE-EE(3) TLSA
	records. For some applications, primarily web browsers, it
	is not safe to disable name checks due to "unknown key
	share" attacks, in which a malicious server can convince
	a client that a connection to a victim server is instead
	a secure connection to the malicious server. The malicious
	server may then be able to violate cross-origin scripting
	restrictions. Thus, despite the text of RFC7671, name checks
	are by default enabled for DANE-EE(3) TLSA records, and
	can be disabled in applications where it is safe to do so.
	In particular, SMTP and XMPP clients should set this option
	as SRV and MX records already make it possible for a remote
	domain to redirect client connections to any server of its
	choice, and in any case SMTP and XMPP clients do not execute
	scripts downloaded from remote servers.

-- 
	Viktor.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Oct 2016 15:42:05 +1100

> identity checks, no similar language is present for DANE-TA(2).

This is correct.  The draft goes into this in more detail, and is more
correct than my short announcement writeup.  Usage 2 is only a problem
if implemented incorrectly (and we have no evidence that this is the
case anywhere).

---

From: [email-masked] (Martin Rex)
Date: Mon, 10 Oct 2016 11:24:38 +0200 (CEST)

> identity of the server in these cases.

The description of the problem sounds vaguely familiar.

https://www.ietf.org/mail-archive/web/dane/current/msg03737.html

-Martin

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Oct 2016 21:11:53 +1100

> https://www.ietf.org/mail-archive/web/dane/current/msg03737.html

If only they had listened eh?  And they went ahead and published anyway.

I didn't do a complete search of mailing list archives when writing
this.  Unsurprisingly, your concerns turned out to be well-founded.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 11 Oct 2016 10:04:21 -0400

> On Oct 11, 2016, at 6:11 AM, Martin Thomson <[email-masked]> wrote:
> 

I am confused as to what "they went ahead anyway" this references.

The linked message from 2011, was part of the discussion of RFC6698.
RFC6698 makes no mention of eliding hostname checks.  The UKS issue
that is the subject of this thread pertains to RFC7671, work on which
did not begin until May of 2013, and which was published in Oct 2015.

> this.  Unsurprisingly, your concerns turned out to be well-founded.

Well, the UKS issue is rather narrowly applicable to special TLS
applications in which cross-origin concerns apply.  That's
basically just browsers, and browsers are not doing DANE, and
certainly not DANE-EE(3).

No browsers support DANE at this time.  One of the recommendations
of RFC7671 is that in each DANE application a decision be made
whether to support PKIX-TA(0)/PKIX-EE(1) or alternatively
DANE-TA(2)/DANE-EE(3).  One might expect DANE in browsers to
only support the PKIX-?? TLSA variants...

Also, as the draft notes, DNSSEC record discovery for DANE with
HTTPS will likely be server-mediated (via TLS extensions), which
entirely addresses the issue, since the TLSA record is then signed
by the EE key.

In any case, the suggested remediation in the UKS draft is too
broad.  It needlessly requires name checks across the board,
even in applications where none UKS is not a concern.  It
consequently substantially limits the applicability of RFC7250
raw public keys.

While I support the publication of the draft, I'd like to see
the recommendations changed from MUST check names to SHOULD
check names.  Or, if you prefer, MUST unless UKS is not a concern.

As I mentioned, OpenSSL 1.1.0 performs name checks for all
DANE certificate usages by default, but provides a flag
to disable them for usage DANE-EE(3).  The documentation
of the flag notes the UKS issue.

-- 
-- 
	Viktor.
-- 
	Viktor.

---

From: [email-masked] (Martin Rex)
Date: Tue, 11 Oct 2016 16:45:11 +0200 (CEST)

> certainly not DANE-EE(3).

I believe your concept is much to narrow.

The issue affects *EVERY* TLS client that will in at least one usage
scenario perform rfc2818 section 3.1 endpoint identification for
a TLS server certificate issued from a public CA.

Every such client, when adopting an alternative TLS server certificate
validation through DANE, probably ought to check the end-entity certificate
for appearance of the Certificate Policy with the OID 2.23.140.1.2.2
and for any TLS server certificate that carries this OID, enforce
the rfc2818 section 3.1 endpoint identification for the hostname,
no matter what kind of TLSA record/usage exists for that server.

-Martin

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 11 Oct 2016 11:19:35 -0400

> On Oct 11, 2016, at 10:45 AM, Martin Rex <[email-masked]> wrote:
> 
> Viktor Dukhovni wrote:
>> 

I am not going to quibble over which HTTPS use-case are in scope.
The relevant application-specific decisions can and will be made.

> no matter what kind of TLSA record/usage exists for that server.

Likely not all HTTPS use-cases are beholden to the policies of the CA/B
Forum.

One thing I should point out, that the authors of the UKS draft may
not have noticed, is that RFC7671 not only says that name checks are
optional for DANE-EE(3), but also specifies that DANE clients accept
certificate hostnames derived from DNSSEC-validated CNAME records,
when the TLSA records are associated with the target of the CNAME.

Thus, given DNSSEC-validated records as below:

	www.impostor.example. IN CNAME www.victim.example.
	www.victim.example. IN A 192.0.2.1
	_443._tcp.www.victim.example. IN TLSA ...

a client would accept a certificate for "www.victim.example" when
establishing a DANE-authenticated connection to www.impostor.example".

This is probably an issue for browsers in the same way as
directly binding the EE key of "www.victim.example" at
"_443._tcp.impostor.example. IN TLSA ?".

So likely the same applications that SHOULD perform name checks
for all certificate usages, SHOULD also not include expanded
CNAMEs in the set of reference identifiers acceptable from the
server or use such expansions in SNI.  By which point, in
such applications, it probably makes no sense to look for TLSA
records at the CNAME target.

-- 
-- 
	Viktor.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 12 Oct 2016 11:31:47 +1100

> I believe your concept is much to narrow.

I tend to agree, though that hinges on your definition of
"cross-origin".  In the web world, that has a very specific meaning.
What you could say that "if the client doesn't care who it is talking
to, or it has some secondary means of validating the identity of a
server, then this isn't a concern".

In the mail case, I continue to be astonished that this isn't a
material problem, but I guess that there really must be these
secondary mechanisms.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 11 Oct 2016 22:54:52 -0400

> On Oct 11, 2016, at 8:31 PM, Martin Thomson <[email-masked]> wrote:
> 

No, it is not "don't care".  It is rather that it is quite sufficient
to know that mail is being delivered to whichever server the next-hop
domain designates as its mailhost.  If some domain wants to publish
(DNSSEC-signed) records:

	example.com. MX 0 mail.ietf.org.
or
	_xmpp-server._tcp.example.com. SRV 0 100 5222 jabber.ietf.org.

to the effect that its email or XMPP servers are running on some
outsourced host, it is free to do so.  The target host may not
offer the service, and may turn away clients trying to send email
or instant messages to [email-masked], but there is no security
impact on either the client or ietf.org beyond any extra load.  And
of course extra load be imposed much more effectively by other means.

> material problem, but I guess that there really must be these

No secondary mechanisms are present or needed.  The issue is
simply moot.  The attacker gains no advantage by redirecting
his own domain's SMTP, XMPP, ... traffic to an unwitting target
server.

What's odd is not that SMTP and XMPP are immune, but rather
the astonishing subtlety of the Web security model, which
makes web applications vulnerable.

-- 
	Viktor.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 12 Oct 2016 11:29:40 +0300

> makes web applications vulnerable.

It is combination of HTTP servers being pretty widely misconfig'd in a
manner that results in bogus responses to requests (pretty much nobody
has similarly misconfig'd SMTP server (as it would be a major problem
in other ways), and AFAICT XMPP servers can't even configured that
way), combined with the very brittle nature of the same-origin policy.

-Ilari

---

From: John Gilmore <[email-masked]>
Date: Thu, 13 Oct 2016 17:15:13 -0700

I'm a bit puzzled by this "UKS" (Unknown Key Share) attack concept.

The attack scenario, presented in section 2 of 

  https://www.ietf.org/id/draft-barnes-dane-uks-00.txt

is that a user connects to the "attacker" site (say google.com) but
actually google.com has published Facebook.com's public key and is a
man-in-the-middle (MITM) forwarding all the traffic to facebook.com.

Now this MITM can't actually read or modify any of the traffic, they
are just a passive conduit.  The most they can see is the timing of
the traffic and the number of bytes involved.  The user sees
Facebook's site, secured with Facebook's key, even though they
connected to google.com.  (How or why the user was somehow convinced
to connect to google.com while seeking facebook.com is unexplained.)

So the threat is...  uh...  ?

... something about some cross-origin scripting firewall policy
elsewhere in the system?  

Why do we care?

	John

---

From: Martin Thomson <[email-masked]>
Date: Fri, 14 Oct 2016 12:05:00 +1100

The draft explains this in more detail.

To use your example, there is now confusion over the identity of the
server.  The client thinks that they have connected to google.com,
when in fact they have connected to facebook.com.

That's where the attacks start.  Requests made to facebook.com over
that connection will be treated as *same-origin* to google.com.  That
violates the SOP and could allow google.com to read confidential data
from facebook.com.