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

[Paul Wouters <[e-mail]>]

On Mon, 14 May 2012, Paul Hoffman wrote:

> 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.
>
> Livable? Better specific suggestions?

Livable. I am a little confused about "signed TLSA", "insecure" or
"indeterminate" together with "the two criteria". Did you mean
"signed TLSA" and "insecure" as one criteria ("dnssec worked") or did
you mean "indicator" and "indeterminate" as the two criteria? How about:

    an application that sends a request for TLSA records will get
    either a valid signed response (containing TLSA records or not)
    or reaches an indeterminate state (for instance by lack of DNS
    replies)

    [...]

    that application MUST not start a TLS connection or abort a TLS handshake
    if TLSA processing is configured and the result was indeterminate.


I'm also not sure why the statement is limited to certficate usage 0 and
1. Is that because you assume no PKIX alternatives are available and
thus it always has to abort for insecure/indeterminate?

Paul