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

[Mark Andrews <[e-mail]>]

In message <[e-mail]>rp>, Martin Rex writes
:
> Eric Rescorla wrote:
> > 
> > > 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 a
> re
> > > 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 serv
> er
> > 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..."
> 
> Similar to OCSP, any hard-fail requirement is going to create a
> significant usability issue, and at worst, cause users to fallback
> from a HTTPS-but-not-DANE-verifiable URL for a login page to
> a plain HTTP login page -- which is making things *MUCH* worse.

No. It is NOT similar to OCSP.  OSCP answers come from somewhere
else.  For 99.99% of TLSA answers they come from the *same* zone
as the address/CNAME/SRV records of the server you are connecting
to.  If you can get one you should to 99.99% be able to get the
answer to the other.

If you get a answer to the address query but not the TLSA query you
will almost certainly have a broken DNS proxy and if I was a web
browser vendor I would be putting up a big message saying:

	You appear to have a broken DNS proxy.  Please contact
	you DNS proxy vendor for a fix.  For more information
	click hear: http://browser.vendor/broken_DNS_proxy.html

> I do not believe in DANE hard-fail without a DNSSEC records stapling
> TLS extension (similar to the OCSP stapling TLS extension).
>  
> And as a fallback, browsers could use a TLSA & server-cert lock, i.e.
> memorizing information from the last visit of a site and using that
> to perform server endpoint identification in case that DNSSEC lookups
> fail when roaming.
> 
> 
> -Martin
> 
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]