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

[Eric Rescorla <[e-mail]>]

On Mon, May 14, 2012 at 7:45 PM, Paul Wouters <[e-mail]> wrote:
> 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)
>
>   [...]
>

I don't think this is what we want.. There appear to be five relevant
states:

* secure, bogus, indeterminate, or insecure [specified in section 4.1]
* no response, DNS error, etc. [the state in question here]

The relevant point here is that in the case where you were expecting
DNSSEC but you get some error in the last category, then in order
to get security benefit from restrictive modes, you must treat that as
if it were bogus. That's different from cases where you weren't
expecting DNSSEC (insecure, indeterminate), and therefore you
should just be ignoring the TLSA records.


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

The security logic is different for restrictive records and additive records.
Say that you're not willing to hard fail on TLSA failures but you're willing
to suppress error warnings if you get resolvable records of type 2 and 3.
Then you are getting security benefit for those records, but you're not
getting any security benefit if type 0 or 1 records exist.

With that said, I haven't completely worked through 2 and 3, so it might
be that they have some restrictive value, in which case the above
analysis applies.


Arguably, it would be best to serve two different classes of records to
make this clearer.

-Ekr