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

[Paul Hoffman <[e-mail]>]

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

--Paul Hoffman