Re: [dane] UKS attacks on DANE

[Viktor Dukhovni <[e-mail]>]

On Mon, Oct 10, 2016 at 03:12:28PM +1100, Martin Thomson wrote:

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

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

> As I understand it, email is believed to be unaffected since the mail
> 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.