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

[Yoav Nir <[e-mail]>]

On May 8, 2012, at 2:16 AM, John Gilmore wrote:

> I think that if the DANE TLS implementation can't get either a
> dnssec-validated TLSA rrset, or a dnssec-validated absence of a TLSA
> rrset, then to meet its security responsibilities, it has to fail to
> connect.
> 
> Where the document is imprecise about that (or requires too many
> indirections through obscure corners of the DNSSEC RFCs to understand
> the implications) then I think we should say that more
> straightforwardly in our RFC.
> 
> In browsers there will likely be a switch to "Use DANE TLS" just like
> today there's a preference checkbox in Firefox for "Use SSL 3.0" and
> "Use TLS 1.0".  When behind a broken coffeeshop gateway, the human may
> need to manually turn off that switch.  But trying to operate in a
> place that makes secure communication impossible should make enough
> trouble for the user that they'll also complain to the coffeeshop
> owner to fix their $*(@#@ gateway - or pick a different coffee shop
> next time.

I agree.

However, I'm wondering how many of the Firefox users who click "I understand the risks" actually understand the risks.

Also a likely scenario is that the user unchecks the "use DANE TLS", complains to the owner, and leaves the box unchecked forever.

The fact that there's quite a few places where you'll have to uncheck the box, and users are unlikely to find it by themselves, Firefox and the other browsers are not likely to have this box checked out of the box. To work securely, the UI has to pop up a warning that this place has insecure DNS, and you can disable the check for this session if you "understand the risks", and it turns back on automatically when you go somewhere else.

Even that is unlikely to be implemented, as browsers are moving in the direction of bothering the user with geek-speak less.

Yoav