Subject: [keyassure] EV certificates and 'must validate'

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 16 Sep 2010 17:11:31 -0400

While I completely agree with the intention to establish a means of
communicating security policy, it is a special case of a bigger problem that
needs a bigger scope than the CERT record.

The attack Adam describes is a downgrade attack. There are multiple forms of
downgrade attack that are relevant:

* Site has an EV certificate but an attacker achieves a redirect to a site
with a DV certificate
* Site supports SSL but attacker achieves a redirect to a non-SSL site
* Site supports SSL but the attacker achieves a man-in-the-middle to an SSL
site with a bogus cert

The EV downgrade attack that worries me is the downgrade attack in which SSL
is disabled completely. I can't see how we can address this problem unless
the CERT record is also performing the function of the security policy
record.

Trying to solve this in the CERT record means that the browser has to pull a
CERT record for every browser interaction regardless of whether SSL is used.

I see the security policy record as a separate issue:

http://tools.ietf.org/html/draft-hallambaker-esrv-00

Now that draft does not actually give the linkage to the assurance mechanism
because I was trying to avoid the dangling reference problem. There are two
ways this could be addressed in ESRV:

1) an ESRV tag that says 'must have a corresponding CERT assurance'

2) an ESRV tag that says 'must have a cert with a chain that includes a root
with digest=x

On Wed, Sep 15, 2010 at 6:31 PM, Adam Langley <[email-masked]>wrote:

> On Wed, Sep 15, 2010 at 5:42 PM, Phillip Hallam-Baker <[email-masked]>
> wrote:
> > My main point of disagreement is the following paragraph in 2.1 which I
> > would simply delete. A relying party should not take this type of
> direction
> > from any TTP and certainly not the certificate subject. The DNS
> > administrator has no real idea how the relying application is going to
> use
> > the data.
> >
> >    o  A one-octet value, called "validation preference", specifying the
> >       preferences for further validation of the certificate in TLS.  A
> >       certificate association that contains a validation preference..
>
> The intent of this is to better support EV certificates. There
> currently exist security concerns when someone can get ahold of a DV
> cert for, say, www.bankofamerica.com. Since the DV and EV cert are in
> the same browser origin, the DV cert can poison the browser cache and
> subvert the true, EV site.
>
> Because of this, it would be good for EV sites to publish DNSSEC
> secured records so that DV certs can be rejected. However, a client
> which is willing to accept DNSSEC authorised certs will do so and stop
> at that point. However, with the indication byte, the client can know
> to perform PKIX validation and find out that it's an EV cert and
> therefore gets a different UI.
>
> Not to mention that some folks that I talk to are keen on keeping the
> PKIX expiry/revocation infrastructure in place for their sites and
> this indication allows them to do so.
>
> Given the, very minor cost, it's something that I'm in favour of.
>
>
> AGL
>
> --
> Adam Langley [email-masked] http://www.imperialviolet.org
>

-- 
Website: http://hallambaker.com/

---

From: Adam Langley <[email-masked]>
Date: Thu, 16 Sep 2010 17:30:53 -0400

On Thu, Sep 16, 2010 at 5:11 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> The attack Adam describes is a downgrade attack.

I see three problems here.

Firstly, given that EV certs exist, how do we make sure that CERT
records don't `override' them? By `override' I mean the case where a
client validates a cert based on DNSSEC while, had they performed PKIX
validation, they would have found that it's also EV.

Secondly, some people have expressed a desire that, even if they
published CERT records, they would still wish the PKIX expiry and
revocation infrastructure to come into play.

Thirdly, how do we prevent downgrade attacks?

> * Site supports SSL but the attacker achieves a man-in-the-middle to an SSL

By listing CERT records, clients can reject bogus certs, even if they
are PKIX valid.

> * Site supports SSL but attacker achieves a redirect to a non-SSL site

Chrome has preloaded HSTS for this[1] and support for tagging
HTTPS-only /may/ be in scope for keyassure stuff although the HSTS
folks seemed luke-warm to the idea.

For the first problem, clients could scan the certificate chain to see
if it might be EV valid and always try PKIX validation if so. I just
worry that it's going to be a pain for clients who don't have a
sufficiently expressive API. Having to parse ASN.1 is a huge problem
and leads to more security issues etc.

For the second problem, the indicator byte seemed like an easy
solution. And, if it's already there, seems easy enough to use it for
the first problem also.

[1] http://dev.chromium.org/sts

AGL

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 16 Sep 2010 14:45:55 -0700

At 5:11 PM -0400 9/16/10, Phillip Hallam-Baker wrote:
>While I completely agree with the intention to establish a means of communicating security policy, it is a special case of a bigger problem that needs a bigger scope than the CERT record.

The field is called "validation preference" and not "security policy" for a very good reason: we are not trying to communicate security policy.

Also, the field is called "validation preference" and not "must validate" for a very good reason: we are not specifying what the TLS client must do.

>I see the security policy record as a separate issue:

We are in full agreement on that!

--Paul Hoffman, Director
--VPN Consortium

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Thu, 16 Sep 2010 15:51:17 -0600

> -----Original Message-----
> 
> > * Site has an EV certificate but an attacker achieves a redirect to a
> > site with a DV certificate

Ok, what does a redirect mean?  What form does it take?  I want to make sure I'm dealing with the proper types of attacks before I speculate on exact countermeasures.

> > * Site supports SSL but attacker achieves a redirect to a non-SSL site

Same for this.   We view (H)STS as a separate policy mechanism from certificate validation.  Every protocol handles its SSL handshakes slightly differently, and need ways to communicate its policy choices.   Web browsers are  "problematic" because they are the bit of technology that most often takes an identifier such as a hostname, and tries to convert it into some sort of request.  The way they do this typically involves taking the string, seeing if it can be looked up in DNS, and then automatically trying HTTP.  Nowhere in the current chain is there any policy lookup, or even indirection between the string the user types, and how the browser performs a lookup.  As such browsers are one of the most vulnerable components to the MiTM attacks we've used HSTS to help prevent.

> Chrome has preloaded HSTS for this[1] and support for tagging HTTPS-only
> /may/ be in scope for keyassure stuff although the HSTS folks seemed luke-
> warm to the idea.

My objection was simply that whether/when to use TLS, is separate from the method used to convey keying information.  We're big supporters of the pre-loaded list, and also supportive of putting the policy data into DNS.  There are lots of other client-specific security policies we'd like to convey as we described in our paper at W2SP.  We'd like to at least contemplate all of them as part of a policy mechanism, rather than just picking off a few.  Already security policies are spread around in too many places, and one of our goals is consolidation of security policy mechanisms.

- Andy

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 16 Sep 2010 18:06:46 -0400

> validation, they would have found that it's also EV.

The way that I would do this if I was writing a browser would be to perform
validation for the strongest chain first.

EV validation criteria are set by CA-Browser Forum and are additional to
anything proposed in IETF.

> revocation infrastructure to come into play.

OK, so the semantics you want are 'only trust this certificate if it also
has a current PKIX chain'. That seems quite reasonable to me.

> By listing CERT records, clients can reject bogus certs, even if they

This is the bit where you lose me. I don't think you achieve that and I
don't see that type of assertion mentioned anywhere in the text.

In order to draw that conclusion you need an assertion that says that the
DNS CERT records are exhaustive. That is not an assertion I would expect to
be making in a CERT record.

Lets take the HTHS discussion offline.

---

From: Adam Langley <[email-masked]>
Date: Thu, 16 Sep 2010 18:11:34 -0400

> be making in a CERT record.

I feel that certificate exclusion is a very useful property. More
useful than validation currently because exclusion can be achieved
without DNSSEC.

In hindsight I realise that it hasn't been articulated anywhere yet,
but I've always assumed that CERT records would be exclusive. (Chrome
currently assumes so if the command line flag is given.)

AGL

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 16 Sep 2010 18:25:41 -0400

Well at the very least, that expectation would have to be made explicit in
the spec and I would really think you need to make it explicit in the record
as well.

It is not an assumption I would be comfortable with from an operational
point of view. Particularly since DNS has caching issues.

---

From: Adam Langley <[email-masked]>
Date: Thu, 16 Sep 2010 18:32:36 -0400

> the spec and I would really think you need to make it explicit in the record

I agree that it should be explicit in the spec. It was also explicit
in the record in some of the early sketches (and in code), but it was
removed. As I recall, simply for simplicity's sake.

> point of view. Particularly since DNS has caching issues.

Yes, you can shoot yourself in the foot with this. However, you can
also shoot yourself in the foot with an A record if you need to
fallover quickly or if you let a PKIX certificate expire. I don't have
any magic ideas how to ameliorate this although obvious best practices
suggest themselves: have backup certificates listed and/or don't set
excessive TTLs.

AGL

---

From: Tony Finch <[email-masked]>
Date: Fri, 17 Sep 2010 00:32:11 +0100

On 16 Sep 2010, at 22:11, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> Trying to solve this in the CERT record means that the browser has to pull a CERT record for every browser interaction regardless of whether SSL is used.

If you do the A and AAAA and CERT lookups concurrently, and cache the results, this should not cause any extra delay. (modulo middleboxes)

Tony.
--
f.anthony.n.finch  <[email-masked]>  http://dotat.at/

---

From: Mark Andrews <[email-masked]>
Date: Fri, 17 Sep 2010 14:01:25 +1000

In message <[email-masked]>, Adam
> validation, they would have found that it's also EV.

You say "don't do that".

> revocation infrastructure to come into play.

Which just means that one honours those fields in the CERT.

> By listing CERT records, clients can reject bogus certs, even if they

You don't trust the DNS unless the response is signed *and* validates as
secure.  Neither of these attacks is possible if you only trust validated
as secure responses.

> > * Site supports SSL but attacker achieves a redirect to a non-SSL site

This either already happens or not.  This is not a new threat.

> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Jakob Schlyter <[email-masked]>
Date: Fri, 17 Sep 2010 10:01:59 +0200

On 17 sep 2010, at 00.06, Phillip Hallam-Baker wrote:

> The way that I would do this if I was writing a browser would be to perform validation for the strongest chain first.

If you want to optimize for speed, this is probably not very efficient.

The primary use case we've seen for validation preference is where a site owner publish a DV cert in the DNS and believe that the binding provided by DNSSEC is enough. If the client choose to follow this "advice", the client may skip PKIX validation and gain a lot of speed as OCSP lookups and whatnot are no longer needed. If the cert is revoked it needs to be pulled from DNS, but that is something the site owner needs to responsibility for just as she needs to contact the CA to revoke the cert.

One should note that clients that does not perform DNSSEC validation, will not receive any validation preference and will continue with PKIX validation just as before.

There is a possible scenario where the site owner publish an EV cert in DNS, but still thinks DNSSEC is enough. This would of less us, as clients will base their trust on DNSSEC only and skip the fancy green bar UI enhanced EV thingy, but if the site owner does that one can ask why she did buy an EV cert in the first place.

	jakob

---

From: Jakob Schlyter <[email-masked]>
Date: Fri, 17 Sep 2010 10:08:01 +0200

> secure.  Neither of these attacks is possible if you only trust validated

The word "bogus" is overloaded in this context. What I believe Adam said was that by publishing a certificate in the DNS, you state that this certificate MUST be presented by the server. Other certs, which may or may not pass PKIX validation, are excluded and are not accepted.

	jakob

---

From: Ben Laurie <[email-masked]>
Date: Fri, 17 Sep 2010 12:50:03 +0100

> If you do the A and AAAA and CERT lookups concurrently, and cache the results, this should not cause any extra delay. (modulo middleboxes)

I have a feeling of deja vu here - if you retrieve CERT records from
the name then sites with large numbers of different certs have a
problem.

---

From: Jakob Schlyter <[email-masked]>
Date: Fri, 17 Sep 2010 15:51:15 +0200

> the name then sites with large numbers of different certs have a

few certs goes into CERT directly. fast.
many certs goes into hash-prefixed CERT, but cannot be fetched until half way through TLS. slow.

if you want performance, the choice is easy.

	j

---

From: [email-masked]
Date: Mon, 27 Sep 2010 19:03:12 +0000

> If you do the A and AAAA and CERT lookups concurrently, and cache the results, this should not cause any extra delay. (modulo middleboxes)

	if you are doing DNSSEC validation, the A, AAAA, and CERT are all going to be part of
	the same RRset.

--bill

---

From: Tony Finch <[email-masked]>
Date: Mon, 27 Sep 2010 21:15:13 +0100

>    if you are doing DNSSEC validation, the A, AAAA, and CERT are all going to be part of

This must be some strange new version of DNSSEC of which I was not previously aware.

Tony.

---

From: [email-masked]
Date: Mon, 27 Sep 2010 20:24:00 +0000

> This must be some strange new version of DNSSEC of which I was not previously aware.

	maybe so... dnssec uses the artifact of an RRset, where all RR's that share 
	the same label are "bundled" into a set.  Validation pulls the whole RRset, not
	just a single RR.  Perhaps this section of RFC 2181 will illuminate:

5. Resource Record Sets

   Each DNS Resource Record (RR) has a label, class, type, and data.  It
   is meaningless for two records to ever have label, class, type and
   data all equal - servers should suppress such duplicates if
   encountered.  It is however possible for most record types to exist
   with the same label, class and type, but with different data.  Such a
   group of records is hereby defined to be a Resource Record Set
   (RRSet).

5.1. Sending RRs from an RRSet

   A query for a specific (or non-specific) label, class, and type, will
   always return all records in the associated RRSet - whether that be
   one or more RRs.  The response must be marked as "truncated" if the
   entire RRSet will not fit in the response.

-- bill

---

From: Adam Langley <[email-masked]>
Date: Mon, 27 Sep 2010 16:28:15 -0400

Ah, I think you are misunderstanding. The above does not follow from this:

>   It is however possible for most record types to exist

Specifically, the set of A records for a domain would be one RRSet and
the set of AAAA records would be another RRSet. Each are signed
independently.

AGL

---

From: [email-masked]
Date: Wed, 29 Sep 2010 05:26:30 +0000

> the set of AAAA records would be another RRSet. Each are signed

	yes - my bad.