Re: [dane] Behavior in the face of no answer?

[John Gilmore <[e-mail]>]

Here's my review of the text Paul Hoffman posted Monday 14 May 19:12:23:

> An attacker who is able to divert a user to a server under his control is also
> likely to be able to block DNS requests from the user or DNS responses being
> sent to the user. Thus, in order to achieve any security benefit from
> certificate usage 0 or 1, an application that sends a request for TLSA records
> needs to get either a valid signed response containing TLSA records or
> verification that the domain is insecure or indeterminate. If a request for a
> TLSA record does not meet one of those two criteria but the application
> continues with the TLS handshake anyway, the application has gotten no benefit
> from TLSA and should not make any internal or external indication that TLSA
> was applied. If an application has any indication that TLSA is in use (such as
> through a configuration setting), that application MUST not start a TLS
> connection or abort a TLS handshake if either of the two criteria above are
> not met.

An attacker who is able to divert a user to a server under his control
is also likely to be able to block DNS requests from the user or DNS
responses being sent to the user.  Thus, in order to achieve any
security benefit from certificate usage 0 or 1, the protocol requires
that when DNS responses have not arrived or are not valid, the TLS
connection must not succeed.

To proceed with a DANE TLSA transaction, an application MUST get
either a Secure response containing TLSA records for the relevant
domain name, a Secure response proving that there are no TLSA records
for the relevant domain name, or verification that the domain name is
Insecure.  (Secure and Insecure are defined in section 4.3 of RFC
4035.)

If the response(s) from a TLSA record query do not meet any of the
above criteria, but the application continues with the TLS handshake
anyway, the application is in violation of this protocol
specification.  It MUST NOT make any internal or external indication
that the DANE TLSA protocol is in effect.  If an application has any
indication that the DANE TLSA protocol is in use (such as through a
configuration setting), that application MUST NOT start a TLS
connection, and MUST abort any pending TLS handshake, if none of the
criteria in the previous paragraph are not met.

(End of text for somewhere in RFC.)

It isn't clear where in the RFC this text would go.  Some of it
seems to be explanatory and other parts seem to be normative.

My comments are that this text is not usable, even after my
modifications.  It chats about motivations.  It tries to define a
protocol specification, saying what the application should do to
follow that spec.  It then says "if you violate this spec in this
particular way, don't call it DANE TLSA".  Then it says that twice, or
three times.  I don't see the point of that.  If they violate the spec
in any other way, they shouldn't call it DANE TLSA either.

I would remove the last paragraph entirely.  I would move the first
paragraph off into a security-related section.  I'd keep the short
paragraph beginning "To proceed with a DANE TLSA transaction,".

I think it's progress to have text that defines the VALID ways to
proceed with the protocol, rather than getting lost in the weeds of
all the possible INVALID ways to fail.

	John