Subject: Re: [keyassure] Using trust anchor language

From: Yaron Sheffer <[email-masked]>
Date: Wed, 26 Jan 2011 18:27:34 +0200

Hi Paul,

I am extremely confused by the wording of the new draft, and my 
confusion is even more exacerbated by your clarification below :-) 
Please help me!

Quoting the new text in full:

Items received in TLSA resource records can be treated like trust 
anchors by the TLS client.  The trust anchor MUST NOT be loaded for 
longer than the TTL on the TSLA record.

I have three issues with this text:

First, the text is imprecise. In some of the cases there are no "items 
received". The RP received a hash of a cert, and that cert is in fact 
what we want treated as a trust anchor.

Second, we use a lower-case "can" for a critical process. A compliant 
Relying Party SHOULD/MUST use these RRs as trust anchors.

And third, the way I understand "trust anchor" is you should trust it 
blindly, like you trust all those 60 certs in your browser. (I am not 
talking of enterprise/government cases, but of the other 99.9% of the 
world).

Does this mean the RP should not even try to validate the cert?

If this is so, we should make the certificate trustworthy. Here's a set 
of tentative rules:

- The DNS registrar MUST have access to the certificate at the time it 
generate the TLSA record.
- The registrar MUST ensure that the certificate is valid, and/or must 
validate any non-key information included in the certificate.
- In particular the registrar MUST ensure that the certificate does not 
refer to any DNS address outside of that registrar's scope of authority.
- The registrar MUST establish a Certificate Practice Statement (CPS) 
and make it publicly available.

I have a feeling this is NOT what you meant. But I fail to understand 
exactly what security policy we now assume.

Thanks,
	Yaron

> Date: Tue, 25 Jan 2011 11:59:00 -0800
> From: Paul Hoffman<[email-masked]>
> Subject: [keyassure] Using trust anchor language:
> 	draft-ietf-dane-protocol-03.txt
> To: "[email-masked]"<[email-masked]>
> Message-ID:<[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Greetings again. There was not an open issue on how TLSA deals with
> non-key information in PKIX certificates, but Phill had brought up
> strong reservations and Steve Kent responded. There was then a longish
> thread on alternatives, but Jakob and I had never clarified the
> document. Thus, we put out -03 with some proposed wording that should
> make clear that the keys in certificate associations are trust anchors.
> The side effect of making that clear is that we could wipe out all the
> wishy-washy stuff from the old 3.1.
>
> The diffs are at
> <http://tools.ietf.org/rfcdiff?url2=draft-ietf-dane-protocol-03.txt>.
>
> If folks are happy with this clarification, it will close some of the
> open issues that were spurred by the language in 3.1.
>
> --Paul Hoffman
>
>
> ------------------------------
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>
>
> End of keyassure Digest, Vol 6, Issue 38
> ****************************************

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 26 Jan 2011 08:58:48 -0800

On 1/26/11 8:27 AM, Yaron Sheffer wrote:
> First, the text is imprecise. In some of the cases there are no
> "items received". The RP received a hash of a cert, and that cert is
> in fact what we want treated as a trust anchor.

Now I'm the one confused. If the TLS client received a hash of a cert 
(either type 1 or type 3), then they received an item.

>  Relying Party SHOULD/MUST use these RRs as trust anchors.

Not at all. RFC 2119 has specific uses, and none of them apply here 
(unless the WG wants to make such an assertion). Your proposal would 
force a security policy on someone who, for example, just wanted to know 
whether or not a site had a TLSA record.

>  blindly, like you trust all those 60 certs in your browser. (I am
> not talking of enterprise/government cases, but of the other 99.9% of
> the world).

Every TLS client has its own rules for what to do with each individual 
trust anchor. Most TLS clients have the policy that "anything that 
chains to any trust anchor I have is allowed", but that policy is not 
mandated anywhere. More careful TLS clients will have more careful 
policies. Our protocol should not force a careless policy on anyone.

> Does this mean the RP should not even try to validate the cert?

Correct: that is the definition of a trust anchor.

> If this is so, we should make the certificate trustworthy. Here's a
> set of tentative rules:
>

There is no such thing as a "DNS registrar". Please choose a phrase that 
exists. Also, what does "have access" mean?

> validate any non-key information included in the certificate.

This makes no sense for a self-signed end-entity certificate. How can 
one validate such a certificate?

> refer to any DNS address outside of that registrar's scope of authority.

By "DNS address" I assume you mean "host name". What is the problem with 
any of the four types defined so far referring to a host name outside 
the "scope of authority" (whatever that is)? These are being used ad 
trust anchors.

> and make it publicly available.

Why would an entity that does not issue certificates need a CPS?

>  exactly what security policy we now assume.

The policy for these four types is "treat them as a trust anchor". I'm 
not sure how to make that any clearer.

---

From: Zack Weinberg <[email-masked]>
Date: Wed, 26 Jan 2011 09:12:48 -0800

On Wed, Jan 26, 2011 at 8:58 AM, Paul Hoffman <[email-masked]> wrote:
...
> Every TLS client has its own rules for what to do with each individual trust
> anchor. Most TLS clients have the policy that "anything that chains to any
> trust anchor I have is allowed", but that policy is not mandated anywhere.
> More careful TLS clients will have more careful policies. Our protocol
> should not force a careless policy on anyone.
...
> The policy for these four types is "treat them as a trust anchor". I'm not
> sure how to make that any clearer.

Precisely because of what you say in the first paragraph I've quoted,
I think DANE needs to be more specific about appropriate client policy
than "treat [a certificate with a valid TLSA record] as a trust
anchor".

At the very least, I think we need language to the effect that a
certificate with a TLSA record SHOULD NOT be promoted to trust anchor
for any certificate chain other than the one received from the server
at the domain name where the TLSA record appears.  (Possibly even MUST
NOT.)  (I may have my PKIX/TLS terminology all wrong, but I hope my
meaning is clear.)

zw

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 27 Jan 2011 06:36:22 -0800

On 1/26/11 9:12 AM, Zack Weinberg wrote:
> On Wed, Jan 26, 2011 at 8:58 AM, Paul Hoffman<[email-masked]>  wrote:
> ...

Arrrgh. I apologize for assuming that folks understand the use of 
limited trust anchors, given that most of us are used to trust anchors 
with unlimited power. This is a trust anchor *only* for this host name. 
Words to that effect needs to be added, and needs to be a MUST.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 27 Jan 2011 10:04:22 -0500

At 6:36 AM -0800 1/27/11, Paul Hoffman wrote:
>limited trust anchors, given that most of us are used to trust 
>anchors with unlimited power. This is a trust anchor *only* for this 
>host name. Words to that effect needs to be added, and needs to be a 
>MUST.

You might note how to effect this, in a PKI-compliant fashion,. e.g., by
associating name constraints for the FQDN with the cert.  Carl 
Wallace's I-D on TA constraints provides one example of how to do 
this, as does the local TA management I-D now in SIDR (only a tiny 
part of that functionality would be needed here).

Steve

---

From: Paul Wouters <[email-masked]>
Date: Thu, 27 Jan 2011 11:13:12 -0500 (EST)

On Thu, 27 Jan 2011, Stephen Kent wrote:

>> Arrrgh. I apologize for assuming that folks understand the use of limited 
>> trust anchors, given that most of us are used to trust anchors with 
>> unlimited power. This is a trust anchor *only* for this host name. Words to 
>> that effect needs to be added, and needs to be a MUST.
>
> associating name constraints for the FQDN with the cert.  Carl Wallace's I-D 
> on TA constraints provides one example of how to do this, as does the local 
> TA management I-D now in SIDR (only a tiny part of that functionality would 
> be needed here).

You might not want to do that though, and rely on DNSSEC to provide the name,
and possibly re-use the same cert for multiple domains without needing to
use wildcards or a long list of subjectAltnames.

Paul

---

From: Stephen Kent <[email-masked]>
Date: Thu, 27 Jan 2011 12:01:11 -0500

At 11:13 AM -0500 1/27/11, Paul Wouters wrote:
>>>anchors with unlimited power. This is a trust anchor *only* for 
>>>this host name. Words to that effect needs to be added, and needs 
>>>to be a MUST.
>>

Paul,

My understanding has been that the primary motivation for wild cards in
web site certs was to avoid the need to pay for multiple certs.  Since we
are avoiding that concern here, and since one could even choose to put the same
key in multiple certs, each with a different name, what is the major
concern over putting a DNS name in a cert? It's not hard to generate multiple
certs, e.g., one per site.

Steve

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Thu, 27 Jan 2011 10:28:22 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Stephen Kent
> 
> Paul,
> 
> My understanding has been that the primary motivation for wild cards in web
> site certs was to avoid the need to pay for multiple certs.  Since we are
> avoiding that concern here, and since one could even choose to put the
> same key in multiple certs, each with a different name, what is the major

A model that doesn't require a name embedded in the cert allows us to get wider TLS deployment without IP exhaustion without requiring SNI.  For what that is worth.

- Andy

---

From: Stephen Kent <[email-masked]>
Date: Thu, 27 Jan 2011 12:47:30 -0500

At 10:28 AM -0700 1/27/11, Steingruebl, Andy wrote:
>A model that doesn't require a name embedded in the cert allows us 
>to get wider TLS deployment without IP exhaustion without requiring 
>SNI.  For what that is worth.
>
>- Andy

Andy,

Sorry for being dense, but can you explain how the SNI extension and 
IP exhaustion relate to the issue of extracting a DNS name from a 
cert vs. inferring it from the DNS record?

Steve

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Thu, 27 Jan 2011 11:13:57 -0700

> From: Stephen Kent [mailto:[email-masked]]
> 
> Sorry for being dense, but can you explain how the SNI extension and IP
> exhaustion relate to the issue of extracting a DNS name from a cert vs.
> inferring it from the DNS record?

Ordinarily, in order to host multiple TLS-endpoints (web virtual hosting) on a single-IP, you have two choices:

1. A cert with multiple SANs
2. use SNI so a client can indicate which end-endpoint (hostname) it is trying to reach.

#1 is extremely problematic when virtual-hosting services for different entities, or lots of entities.  For example, CDNs will often try to virtual a number of websites at the same IP, and will have a certificate with SANs that span a multitude of organizations/businesses.

#2 is problematic because SNI isn't supported in Windows-XP.

Currently, #1 or a single-IP per "website/hostname" is required.

With TLSA if we don't have to embed the hostname in the certificate offered during the TLS handshake, we don't care about SNI if a client supports TLSA.  Now, what client will support TLSA and not SNI, well, that's why this isn't really that big a deal I suppose..

- Andy

---

From: Martin Rex <[email-masked]>
Date: Thu, 27 Jan 2011 22:16:32 +0100 (MET)

Steingruebl, Andy wrote:
> With TLSA if we don't have to embed the hostname in the certificate
> offered during the TLS handshake, we don't care about SNI if a
> client supports TLSA.  Now, what client will support TLSA and not
> SNI, well, that's why this isn't really that big a deal I suppose..

Conceptually, there _is_ a significant difference. (see last sentence
of section 1 of every TLS spec in existence).

Support for DANE/TLSA could be added entirely at the app layer without
a single change to the underlying TLS implementation.  The use of SNI,
on the other hand, has the inevitable prerequisite that the underlying
TLS implementation itself must support it.

So for implementations running on top of Windows SChannel, supporting
DANE/TLSA is conceivable even for Windows XP and completely independent
of what Microsoft does.  This applies to _all_ environments with currently
extrension-free TLS implementations (WinXP is probably the single largest
example, but there are _many_ more such environments&devices).

In some environments, there may be dozens or even hundreds of
virtual hosts on the same IPv4-address, and having to re-issue
a cert everytime a virtual host is added or removed would be
a real problem without SNI.  Having a self-signed server cert
change every few weeks sounds like a very bad idea, because
it precludes clients from sensible "pinning" of server certs
as a means to improve trust through memorizing prior experience.

-Martin

---

From: "Carl Wallace" <[email-masked]>
Date: Thu, 27 Jan 2011 23:16:15 -0500

> You might not want to do that though, and rely on DNSSEC to provide
the
> name, and possibly re-use the same cert for multiple domains without
> needing to use wildcards or a long list of subjectAltnames.
> 
> Paul

Is there no concern for backwards compatibility at all?  Should folks
who do not use the DANE validation approach have no means to determine
if a certificate is valid and appropriate for a given site?  Should
folks have to learn to accept any name in a certificate validated via
DANE while checking for proper names when DANE is not used?