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

[Warren Kumari <[e-mail]>]

On May 15, 2012, at 2:32 PM, Paul Hoffman wrote:

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

<chair>
Thank you -- and I ask that if folk are unhappy with the current wording they  propose alternate. Simply grumping (and repeating yourself) isn't nearly as effective at communicating what you actually *mean* as providing suitable text...
</chair> 

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

This may be my fault -- a long time back (in this thread) I proposed having implmentations  default to not-strict and then, in a few years (once there is less DNSSEC breakage by CPE, etc), vendors would turn the knob to strict mode. Educated / security concious users would also be able to turn the knob if they so  desired.

This was just an idea, and perhaps a bad one!


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

This sounds good to me, but what does the user do in this case?  Simply remove the s from https:// (assuming a browser)? Do we need to mention anything, or leave this up to the application? There is already stuff like HSTS / web sec, etc for this…

Yes, I should be proposing text here, but I'm not really taking a stand, rather trying to get feedback...

W
> 
> --Paul Hoffman
> 
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>