[Cryptography] Preliminary review of the other Applied Cryptography

ianG iang at iang.org
Sun Apr 13 12:08:42 EDT 2014


On 12/04/2014 01:44 am, Viktor Dukhovni wrote:
> 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.


Right, belief is the ideal result of the marketing.  My general tactic
there is to refer believers to the contracts that support that belief
and point out that IMO the contracts expressly won't and don't.

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


I agree.  In more precise terms, I would say it comes down to the
statement that is claimed by the cert.  Making various assumptions here,
there should be a statement of reliance that can be tied to the cert,
and that statement and reliance is not something that can be tied into
something as simple as an evil bit.  (Or the so-called "trust bits" for
that matter.)


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


Hmmm.  A highly nuanced answer that sidesteps the foundations of those
beliefs.  But yes, I can imagine this is the polite and politic answer.


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


Google and Mozilla developers have apparently expressed a desire to only
support HTTP2 if it is TLS only.  This is good news.  This indicates
some willingness to at least move the game forward, and to go against
inertia.


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


Long but interesting reply!  I had to read it twice to grasp it.

The answer as I suspect you know is found not so much in the allocation
of the resource (one programmer) but in the employer-mindset.  Who is
paying to do the work will be key, at both an individual level (am I for
it?) and an aggregate level (are we against it?).

For the most part, all the work surrounding this area in the browsers
has been conducted by engineers that have been focussed on preserving
the PKIX solution.  So, that's what they have done;  done their job.
It's hard to fault them for it.  As their interests are in preserving
the franchise they have tended to act against alternates in subtle,
deniable ways.

It was for this basic motive that no alternates found favour until CT
came along.  CT afaics was no better or worse than any other idea, it
just had the one thing that makes a difference, google.

(Whether that latter can be attributed to brand, resource, interest or
other is probably beyond scope... but it's a really interesting question.)


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


What is the DNSSEC last-mile problem?  It's the week for displaying
ignorance, seemingly.



iang


More information about the cryptography mailing list