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

[Paul Hoffman <[e-mail]>]

(Going back a bit in the discussion, using the only wording we have.)

On May 14, 2012, at 7:31 PM, Eric Rescorla wrote:

> On Mon, May 14, 2012 at 7:12 PM, Paul Hoffman <[e-mail]> wrote:
>> There doesn't seem to be convergence here, and the WG chairs and AD have asked the authors to propose wording that might bring consensus. The following text may be insufficient, but it's the best I can do at the moment, and if it isn't good enough, having you propose specific changes may be helpful.
>> 
>> This proposed text tries to pull together:
>> 
>> - Ekr's security analysis
>> 
>> - The desire for a MUST that is likely to be deployed, not ignored
>> 
>> - Acknowledgement that if the user doesn't know TLSA is being used, they are not losing anything from the attack
>> 
>> (And, yes, I think that the chairs should be doing this bit instead of Jakob and I. Oh, well.)
>> 
>> 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.
> 
> I think this is generally fine, modulo Stephen's concerns about types 2 and 3,
> which I haven't worked through yet.

Nor have I, but at least we're sure that we agree on 0 and 1.

>> 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.
> 
> I feel like this is confusing. There are two senses in which TLSA might
> be "in use". (1) The application is trying to retrieve it. (2) The DNS server
> is serving it. We're clearly in the first case, and it's the second which
> is unknown to us b/c under control of the attacker. Perhaps you
> mean to say "Applicaions SHOULD offer a setting to allow users to
> set strict TLSA checking, in which case..."

I don't think people have been talking about suggesting that the application let the user choose between strict and not-strict; I think most people here are against that. But I agree that the sentence is confusing because it makes "configuration setting" a subset of TLSA indication. Instead of that sentence, I propose:

If an application has a configuration setting for turning on TLSA use,
or has any indication that TLSA is in use (regardless of whether or not
this is configurable), that application MUST not start a TLS
connection or abort a TLS handshake if either of the two criteria above are
not met.

This does not say "and you might have hard failure configurable", but instead says "if the user might think that TLSA is in use, you have to hard fail if they are not getting the security that they might expect".

--Paul Hoffman