Subject: [keyassure] Hashing certificates vs hashing keys

From: Adam Langley <[email-masked]>
Date: Tue, 14 Dec 2010 11:19:07 -0500

When connecting with HTTPS, browsers validate certificates using a
`certificate pool' model. Initially the pool consists of the root CAs.
Once the server's certificate chain has been received, intermediate
certificates are added to the pool. (Intermediate certificates from
previous connections may, or may not be retained in the pool. Firefox
does this, Chrome doesn't.) Then the browser attempts to build a chain
from the leaf certificate, upwards. If no valid steps can be taken
then the browser will try AIA fetches to fill in the blanks.

This differs from the PKIX standards, but it's needed in order to
function with the existing set of HTTPS servers in the world.

There is also the reality that CA certificates (intermediate or root)
get `renewed' from time to time. The expiry date of the old
certificate is advanced whilst maintaining the same Subject,
SubjectPublicKeyInfo, etc fields. This means that signatures from the
old certificate are also valid signatures for the new certificate.

These two behaviours, in combination, mean that one cannot know what
chain a browser will build for a given connection. There often several
possible, and equally valid, chains from a leaf certificate to a root
CA.

Therefore, if a domain were to claim that "valid chains for this
domain will contain a certificate with hash $h", then that may not be
true for all valid chains. Clients may randomly fail depending on the
order of sites previously visited (as that affects the contents of the
pool).

Hashing the SubjectPublicKeyInfo, rather than the full certificate,
solves this issue.

Cheers

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org

---

From: "Carl Wallace" <[email-masked]>
Date: Tue, 14 Dec 2010 11:43:45 -0500

> Hashing the SubjectPublicKeyInfo, rather than the full certificate,
solves this
> issue.

+1

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 14 Dec 2010 13:33:40 -0500

Agree for Cert Signing certs, strongly disagree for end entity certs.

If we are hashing an end entity cert then there is no path ambiguity. The
path is DNSSEC->EE.

But the attributes in the EE cert are still important. for example, critical
flagged attributes.

I don't care about the cert signing certs as I have never had any real
confidence that the policy constraint mechanism works anyway.

On Tue, Dec 14, 2010 at 11:19 AM, Adam Langley <[email-masked]>wrote:

> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 14 Dec 2010 10:36:16 -0800

At 11:19 AM -0500 12/14/10, Adam Langley wrote:
>There often several

Sounds right.

--Paul Hoffman, Director
--VPN Consortium

---

From: Martin Rex <[email-masked]>
Date: Tue, 14 Dec 2010 20:18:54 +0100 (MET)

> function with the existing set of HTTPS servers in the world.

Yuck!  I would _never_ do something like that in my software.
Pooling certs from other requests makes your software behaviour
non-deterministic and chasing AIA is a serious security problem.
Personally, I do not consider this reasonable behaviour.

TLS implementations that send out incomplete or unordered certificate
chains are clearly violating the TLS protocol specification and
those that are sending expired certificate deserve to face a
fatal certficate expired alert.

-Martin

---

From: Adam Langley <[email-masked]>
Date: Tue, 14 Dec 2010 14:30:25 -0500

> fatal certficate expired alert.

Yes, I agree. However all the economic incentives push clients towards
maximum compatibility and don't encourage server operators to fix
anything.

That's why browsers still have workarounds for SSLv3 implementations
which don't ignore extensions, for servers which claim DEFALTE support
but can't actually do it, for stacks which can't handle fragmented
handshake messages etc

AGL

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 14 Dec 2010 16:16:10 -0500

+1 for a single mechanism that works for both CA certs and EE certs.

--Richard

On Dec 14, 2010, at 1:33 PM, Phillip Hallam-Baker wrote:

> If we are hashing an end entity cert then there is no path ambiguity. The path is DNSSEC->EE.
> 
> But the attributes in the EE cert are still important. for example, critical flagged attributes.
> 
> 
> I don't care about the cert signing certs as I have never had any real confidence that the policy constraint mechanism works anyway. 
> 
> On Tue, Dec 14, 2010 at 11:19 AM, Adam Langley <[email-masked]> wrote:

---

From: Martin Rex <[email-masked]>
Date: Tue, 14 Dec 2010 23:04:54 +0100 (MET)

> maximum compatibility and don't encourage server operators to fix

If Browsers implement the "workarounds" that you described in a
completely covert fashion, then they are actually making the problem
MUCH worse _and_ make it last MUCH longer.

There are a number of folks that do black-box testing with browsers
only, and what the particular browser that is used does not report
as an error is considered "fine".

Silently forgiving just about _everything_ with a smile is a sure way
to spoil kids and technologies.

More and more often I'm seeing support calls "but it works in the browser",
and I'll have to ask for a network trace -- in order to confirm that
our TLS client in compliance with the spec and that they need to
get the server fixed if they want to connect/interoperate.  And our
client is pretty conservative in what it sends out (e.g. no TLS extensions).

-Martin

---

From: Adam Langley <[email-masked]>
Date: Tue, 14 Dec 2010 17:13:50 -0500

> MUCH worse _and_ make it last MUCH longer.

I still agree :)

Chrome will not add workarounds to TLS because they are a proven
failure. We're also willing to take some pain to enforce this.

(For example, some servers were found to be misconfigured and
negotiating DHE with a 256-bit multiplicative group. Chrome made this
a hard error and we've had some negative press[1] and user anger
because of that. It's good to see that Firefox will be removing their
workaround for this and making it a hard error in Firefox 4.)

But we were too late to the game to do anything about the many
workarounds which are too common to ignore.

[1] http://www.theage.com.au/business/theres-no-space-like-chrome-20101209-18rj8.html

AGL

---

From: Martin Rex <[email-masked]>
Date: Tue, 14 Dec 2010 23:36:31 +0100 (MET)

> >Hashing the SubjectPublicKeyInfo, rather than the full certificate,

Curiously, public key fingerprints and (Subject/Authority)KeyIdentifiers
are calculated over the "SubjectPublicKey" BitString _contents_ only, rather
than the entire SubjectPublicKeyInfo structure that includes the AlgId and
and ASN.1 sequence container.

SubjectPublicKeyInfo  ::=  SEQUENCE  {
     algorithm            AlgorithmIdentifier,
     subjectPublicKey     BIT STRING  }

-Martin

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 14 Dec 2010 16:12:27 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Martin Rex
> Sent: Tuesday, December 14, 2010 2:37 PM
> To: Paul Hoffman
> Cc: [email-masked]; [email-masked]
> Subject: Re: [keyassure] Hashing certificates vs hashing keys
> 
> Paul Hoffman wrote:
> >
are
> calculated over the "SubjectPublicKey" BitString _contents_ only, rather
than
> the entire SubjectPublicKeyInfo structure that includes the AlgId and and
ASN.1
> sequence container.

I don't know about public key fingerprints, (which might or might not be in
X.509 certificates and therefore would not have the structure) but the fact
that one suggested way of maybe computing SKI/AKI values which is supposed
to result in a value (not necessarily even random value) uses only the most
random portion of the input I find as being not the list bit interesting.

Jim

---

From: Adam Langley <[email-masked]>
Date: Tue, 14 Dec 2010 19:01:02 -0500

> and ASN.1 sequence container.

I believe that OpenSSL calculates fingerprints over the
subjectPublicKey while NSS calculates over the whole
SubjectPublicKeyInfo.

But I do think that hashing SubjectPublicKeyInfo is better. Maybe an
elliptic curve (x,y) pair will never be interpreted as an RSA (e, n)
pair but, rather than have to verify that, I'd hash the algorithm in.

AGL

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 14 Dec 2010 16:22:33 -0800

> Behalf Of Adam Langley
> Sent: Tuesday, December 14, 2010 8:19 AM
> To: [email-masked]
> Subject: [keyassure] Hashing certificates vs hashing keys
> 
`certificate
> pool' model. Initially the pool consists of the root CAs.
certificates
> are added to the pool. (Intermediate certificates from previous
connections
> may, or may not be retained in the pool. Firefox does this, Chrome
doesn't.)
> Then the browser attempts to build a chain from the leaf certificate,
upwards.
> If no valid steps can be taken then the browser will try AIA fetches to
fill in the
> blanks.
> 
> This differs from the PKIX standards, but it's needed in order to function
with
> the existing set of HTTPS servers in the world.

You have lost me here, PKIX says how to validate a chain.  I don't remember
anything that says this is how you construct the one or more possible chains
that need to be validated.  
> 
> There is also the reality that CA certificates (intermediate or root) get
> `renewed' from time to time. The expiry date of the old certificate is
advanced
> whilst maintaining the same Subject, SubjectPublicKeyInfo, etc fields.
This
> means that signatures from the old certificate are also valid signatures
for the
> new certificate.

But also means that you may or may not have a valid PKIX chain using the old
certificate.

> 
> These two behaviours, in combination, mean that one cannot know what chain
> a browser will build for a given connection. There often several possible,
and
> equally valid, chains from a leaf certificate to a root CA.

There may be more than one valid chain.  If this is the case then both (all)
of the currently valid intermediate certificates should be contained in TLSA
records.  The TLSA record would be removed if the CA certificate became
invalidate for any of a number of reasons.  But if it is considered to be
invalidate by the domain administrator it would generally have been rendered
invalid by the issuing CA as well.  

The interesting question that comes up - but does not necessarily appear to
be addressed in the document is the question of this affecting the PKIX
validation protocol in the case of multiple valid chains.  If the processing
is done serially rather than in parallel, the chain validation code could
return only one of the many valid chains which would then be disallowed by
the TLSA record.  This might be an issue if cross certificates are created
which produce additional valid chains.  I don't think that either of these
cases would be common but they might need to be addressed in the document.

> 
> Therefore, if a domain were to claim that "valid chains for this domain
will
> contain a certificate with hash $h", then that may not be true for all
valid
> chains. Clients may randomly fail depending on the order of sites
previously
> visited (as that affects the contents of the pool).
> 
> Hashing the SubjectPublicKeyInfo, rather than the full certificate, solves
this
> issue.

Hashing just the public key does not fix the problem if you care about
statements being made in the certificate besides just the key.  I.e. name
constraints and so forth.  This means that there may be additional
information in the certificate that would affect validation that could
possibly be ignored.

Jim

---

From: Paul Wouters <[email-masked]>
Date: Tue, 14 Dec 2010 19:55:32 -0500 (EST)

> records.  The TLSA record would be removed if the CA certificate became

The TLSA is not meant to validate CA chains. It is meant to validate the
algorithm and pubkey of the dns entry it is associated with. It should never
be needed to have more then 1 TLSA. From the draft:

    Instead of trusting a certification authority to have made
    this association correctly, the user might instead trust the
    authoritative DNS server for the domain name to make that
    association.

Though I realise this is somewhat at odds later on with the certificate
type.

> constraints and so forth.

You don't. The name constrains are in the DNS label.

Paul

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 14 Dec 2010 17:55:03 -0800

It is my belief that you are not picking up the entirety of the proposal.

> From: Paul Wouters [mailto:[email-masked]]
> Sent: Tuesday, December 14, 2010 4:56 PM
> To: Jim Schaad
> Cc: 'Adam Langley'; [email-masked]
> > There may be more than one valid chain.  If this is the case then both
> > (all) of the currently valid intermediate certificates should be
> > contained in TLSA records.  The TLSA record would be removed if the CA
> > certificate became
> 
> algorithm and pubkey of the dns entry it is associated with. It should
never be
> needed to have more then 1 TLSA. From the draft:
> 

This is the first and simplest way to look at things.  And even in this case
you could have more than one TLSA in the DNS.  If you are running an array
of load-balanced servers and each has its own private key, then you could be
setup to have n self-signed certificates to place in TLSA records.  Another
case where you would do this is to advance publish a new certificate in the
event the certificate is getting ready to expire or the key is to be
changed.  After you have done the publication and caches have timed out then
you change the private key on the server and remove the old TLSA record.
Again in this case you are doing the simple thing but would have more than
one TLSA record in the DNS.

type.

This is where the addition the chain validation comes in.  What is the
reason for having the types 3 and 4 certificate types if this is not
allowed.  I don't know if you were at the f2f, but Paul talked extensively
about using a CA certificate and having a chain of certificates that passed
through the certificate marked in the TLSA record - potentially with the
certificate in the DNS being treated as a trust anchor for this one name
space.

NEW ISSUE: If you have a CA certificate in the TLSA record, and don't have
an EE certificate in a TLSA record do you ignore the set of names in the
published certificate and assume that the DNS name is correct?

> > statements being made in the certificate besides just the key.  I.e.
> > name constraints and so forth.
>

---

From: Martin Rex <[email-masked]>
Date: Wed, 15 Dec 2010 03:08:09 +0100 (MET)

>     authoritative DNS server for the domain name to make that

Two issues come to mind why a single cert is insufficient.

 - key rollover for your server (same algorithm, new keypair)
 - support for two different crypto algorithm during migration
   at some point in the future (e.g. from RSA-cert to EC-DSA cert)

I don't think the "I could build different cert chains for validation"
bears any relevance.  The TLS protocol provides room for exactly
ONE chain that the server _MUST_ send, and the TLSA(s) should match
the chain(s) that the server is (capable of) sending.

-Martin

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 14 Dec 2010 18:52:00 -0800

> From: Martin Rex [mailto:[email-masked]]
> Sent: Tuesday, December 14, 2010 6:08 PM
> To: Paul Wouters
> Cc: [email-masked]; [email-masked]; [email-masked]
> > The TLSA is not meant to validate CA chains. It is meant to validate
> > the algorithm and pubkey of the dns entry it is associated with. It
> > should never be needed to have more then 1 TLSA. From the draft:
> >
> bears any relevance.  The TLS protocol provides room for exactly ONE chain
> that the server _MUST_ send, and the TLSA(s) should match the chain(s)
that
> the server is (capable of) sending.

I would agree.  If a single full chain is provided then that would be the
one chain that I would expect to be able to validate via the TLSA record(s).

Jim

---

From: Paul Wouters <[email-masked]>
Date: Wed, 15 Dec 2010 01:41:40 -0500 (EST)

On Tue, 14 Dec 2010, Jim Schaad wrote:

> setup to have n self-signed certificates to place in TLSA records.

I'm not sure I see why you would use different private keys (or certs) on different
load balancers for the same website?

>  Another
> changed.

That would be only if those certificate properties are used at all. I think the
most basic and simple case for this draft should be to only take the minimum key
material, and not take anything else, including a certificate lifetime. The whole
idea is that this is now controlled with DNS TTL and RRSIG.

> After you have done the publication and caches have timed out then

But I can see the use case here for multiple TLSA records.

> certificate in the DNS being treated as a trust anchor for this one name

I could live with these, if there would be at least one sub type that would
be the type where all this information is not used, for those with no interest
in any CA validation, but just want to validate the public key from the cert
with the fingerprint in the TLSA.

> published certificate and assume that the DNS name is correct?

This is why redundant in tricky. With DNS the DNS name is known already outside
the certificate, so in the most "basic" type certificate, you could have an empty CN.
Which would work better for vhost'ing and SSL as well, as there is no hostname
mismatch.

Paul

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Wed, 15 Dec 2010 09:24:52 -0700

> Behalf Of Paul Wouters

> I'm not sure I see why you would use different private keys (or certs) on
> different load balancers for the same website?

At least one large financial institution is rumored to require private key generation in hardware for all use cases, and its easier to make them unique, than transport them between multiple hardware-security-modules.  Regardless of whether they are typical, are you saying you view this is an invalid practice (generating separate private keys for each server/load-balancer) or that you simply don't want to support it in this spec?  
 
- Andy

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 15 Dec 2010 08:37:02 -0800

>load balancers for the same website?

This was covered in our pre-WG drafts: some CAs actually require it (although the requirement is often ignored). Regardless, if the TLSA record can say "this is my CA", that is sufficient for the use case.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Wouters <[email-masked]>
Date: Wed, 15 Dec 2010 13:00:33 -0500 (EST)

> At least one large financial institution is rumored to require private key generation in hardware for all use cases, and its easier to make them unique, than transport them between multiple hardwar…

I have no issue supporting it.

Paul

---

From: Steve Schultze <[email-masked]>
Date: Thu, 16 Dec 2010 00:00:09 -0500

I wanted to highlight the following set of comments and flag a potential issue:

> But the attributes in the EE cert are still important. for example, critical flagged attributes.

The current draft says:
"All data in a self-signed certificate other than the key itself can be ignored as untrusted unless a client validates the self-signed certificate to a trust anchor that is identical to the certificate."

> You don't. The name constrains are in the DNS label.

If we are sticking with the language in the draft (which I think we should), and anybody can suggest other constraints or attributes that might be necessary, we need to consider them as we work on the structure of the RR.  If we don't think that we can predict all future constraints/attributes, then we need some flexible way of specifying them.  This might lead down the path of (gasp) the Kaminsky TXT-record-with-key-value-pairs approach:
http://dankaminsky.com/2010/12/14/dnssec-ch2/

---

From: Paul Wouters <[email-masked]>
Date: Thu, 16 Dec 2010 00:19:47 -0500 (EST)

> If we are sticking with the language in the draft (which I think we should),

So the issue with this that was brought to my attention by a browser
vendor, is that their CA policies don't allow them to "take in" unverified
data. So having a CN and then not vouching for it cannot work, because
they would end up displaying unvouched data to the user if TLSA checks
were done over just the key and not the CN. So I think we need something
besides "can be ignored", because its a real problem we cannot ignore.

I think we can address this with adding the new TLSA cert type that only
vouches for the public key.  For any other TLSA cert type, I believe the
the above test could then remain, but perhaps a warning should be added:

"Some client policy might not allow unverified certificate data in
  self-signed certificates and might reject the TLSA record in such cases
  and fall back to non-TLSA certificate validations"

Perhaps a pointer to not using a CN= allowing TLS vhosting with one certificate
could be useful as well.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 16 Dec 2010 05:57:02 +0000

Well the draft is wrong then.

These certs are signed under the DNSSEC trust path, they are not equivalent
to a self-signed cert.

Limitations on the use of a cert have always been valid when using
self-signed certs.

On Thu, Dec 16, 2010 at 5:00 AM, Steve Schultze <[email-masked]> wrote:

> "All data in a self-signed certificate other than the key itself can be
> ignored as untrusted unless a client validates the self-signed certificate
> to a trust anchor that is identical to the certificate."
>
> Then Jim Schaad said:
> If we are sticking with the language in the draft (which I think we
> should), and anybody can suggest other constraints or attributes that might
> be necessary, we need to consider them as we work on the structure of the
> RR.  If we don't think that we can predict all future
> constraints/attributes, then we need some flexible way of specifying them.
>  This might lead down the path of (gasp) the Kaminsky
> TXT-record-with-key-value-pairs approach:

---

From: Steve Schultze <[email-masked]>
Date: Thu, 16 Dec 2010 11:18:20 -0500

The question is not either-or, it is how.  If it can be done well within the DNS record itself (for example, as it is done via the DNS label for name constraints) then there seems to be no reason not to do it there.  Indeed, if it turns out that there good reasons to stick the hash of the key in DNS instead of the hash of the cert (for example, Adam's reasons), the DNS record is the most secure place to put it.

But what about my original question?  What constraints other than domain name constraints do we envision being relevant?

On Dec 16, 2010, at 12:57 AM, Phillip Hallam-Baker wrote:
> These certs are signed under the DNSSEC trust path, they are not equivalent to a self-signed cert.
> 
> Limitations on the use of a cert have always been valid when using self-signed certs.
> 
>

---

From: Paul Wouters <[email-masked]>
Date: Thu, 16 Dec 2010 12:16:37 -0500 (EST)

On Thu, 16 Dec 2010, Steve Schultze wrote:

> label for name constraints) then there seems to be no reason not to do it there.  Indeed, if it turns out that there good reasons to
> stick the hash of the key in DNS instead of the hash of the cert (for example, Adam's reasons), the DNS record is the most secure
> place to put it.
> 

Looking at "constraints" is more the CA/X.509 way. The DNSSEC way is
more binary. It's either OK or not OK to trust and use this.

There is no value judgement on anything else. If you need value judgements
(strength, expiry, proprerties, EV, etc) you end up in CA space. I think
people here mostly want the simple DNSSEC case to work, and trust on CA's
for any extended type of constraints.

The corner case here is if someone wants to use TLSA and perhaps also wants to
use their own CA that's not recognised by browser/software vendors, because
those vendors don't want to seem to vouch for any data from a "rogue" CA.

Paul