[Cryptography] Preliminary review of the other Applied Cryptography

[Viktor Dukhovni]

On Fri, Apr 11, 2014 at 05:09:42PM -0400, ianG wrote:

> > [ HTTPS libraries would need a configurable switch to choose between
> > PKIX-style TLSA and non-PKIX DANE-only TLSA records.  The switch
> > would be set by default to match general-purpose browser policy,
> > whatever that might be.  Here we run into some major philosophical
> > obstacles.
> 
> This question:
> 
> > Is it the job of TLS certificates to ensure that you're
> > connected to whichever server you asked to connect to, or is it to
> > protect you from your own folly when you visit the websites of
> > typo-squatters, phishers, ... The presumed value-add of PKIX EV
> > validation rests I believe on the premise that users need protection
> > from themselves as much or more than from MiTM attackers, and that
> > it is the job of browser TLS to address this problem. ]
> 
> I really doubt the latter choice, I'd be pretty sure we get the former
> choice, and even that is suspect.

My personal bias is quite transparent from the language I used to frame
the question.  So while you and I unlikely to disagree on this point, I
run into rather experienced folks who indeed believe that the PKI ought
to protect users in the manner I allude to, and that therefore the PKIX
CAs in this manner offer a higher level of assurance than DNSSEC ever
can by allowing each domain to self certify its own keys.

> Although EV was started because of this question, the result was not to
> answer it.  I do not recall anything from EV documents that spoke to
> actually taking on liabilities.  CAs will not at any time disavow your
> misinterpretation, nor will they at any time take on any liability that
> isn't easily dumped to another party.  It's just not the business they
> are in.

Spin resists precise measurement, you can simultaneously only measure its
magnitude and one of the bias directions.

My objection is more fundamental.  I believe that any connection
between a domain name and some business name that consumers trust
needs to be at a higher level than the security mechanism that
builds a secure channel to a service at some domain name.  The
basic network security plumbing cannot and should not in my view
attempt to correctly set the "evil bit" on network flows.

If one accepts the view that TLS connects you to the owner/operator
of a domain, then I think it is quite clear which pair of DANE
usages is the right one for HTTPS on the public Internet.

If one believes that EV is the best way to protect consumers on
the Internet, and that without EV consumers would be subject to
substantially greater fraud, and no better ways can be found to
bind popular brands to their DNS domains, then one would choose
to standardize DANE for HTTPS with the PKIX pair of usages.

In this thread, I just wanted to highlight the fact that we're not
quite done designing DANE yet.  The Postfix DANE implementation is
the first real test case for RFC 6698 and considerable additional
work needed to be done to define the use of DANE with SMTP.

Regardless of the final design, I expect that considerable additional
work also needs to be done to properly scope DANE for HTTPS.  Thus,
in my view broad adoption in browsers is premature.  The base DNS
record format has been defined.  Now begins the hard work of applying
it to real applications.

Someone has to be sufficiently motivated to do this work.  It took
me a year to get from RFC 6698 to a reasonably complete I-D for
SMTP with DANE and a production-ready implementation.

Many of the implementations I've seen along the way are experimental
at best.  Given the state of the browser industry, a key developer
at Google, Mozilla or Microsoft would have to marshal the time,
resources and mind-share to flesh out DANE for HTTPS.  This despite
competing efforts to shore-up PKIX via CT.

I should explain that I have no personal gripes with CT, it is an
interesting idea and may well substantially help to keep the public
CAs trusted by browsers accountable.  As far as I can tell, it is
as yet unclear exactly how one might apply CT to private CAs as
with DANE-TA(2) or the CA-less case of DANE-EE(3).

So if the browser architecture remains committed to public CAs and
EV, but with enhanced accountability via CT, then we're looking at
PKIX-{TA,EE} usages for DANE in browsers.

If browsers on the other hand implement DANE with DANE-{TA,EE}
usages, then the security model largely excludes the public CAs,
EV, CT, and all that, and allows any domain to self-certify its
keys (after enrolling DNSSEC zone KSKs via its registrar).

One might imagine a hybrid approach where "secure" connections are
protected with PKIX and CT (and maybe a bit of DANE for extra safety
with PKIX-{TA,EE}), while "opportunistic" connections employ
DANE-{TA,EE} to achieve SMTP-like downgrade-resistant encryption
that is not represented as "secure" in the browser UI.

Of course all of this is predicated on the notion that the DNSSEC
last-mile problems will be solved, which may require pressure for
them to be solved, which may require some non-trivial adoption, a
catch-22 perhaps.

-- 
	Viktor.