Subject: Re: [keyassure] Using trust anchor language

From: Yaron Sheffer <[email-masked]>
Date: Thu, 27 Jan 2011 08:40:34 +0200

Hi Paul,

if earlier I was confused, now I am extremely worried. It seems to me 
than with the goal of simplifying the protocol, you are removing all 
remnants of operational security.

If the DNS registrar signs anything more than the public key, in 
particular if it signs the Subject or Subject Alt Name on a certificate, 
and if we specify explicitly that this cert is to be used as a trust 
anchor, then the registrar acts as a CA. So, like it or not, it needs to 
play by CA rules.

If all you sign is the public key, and if you mandate that the cert MUST 
only be associated with a particular FQDN and the RP MUST ignore non-key 
material, then we can relax these rules. I think this is the path we 
should follow if we are to provide a credible, yet secure, alternative 
to PKI.

I am well aware of the failings of commercial PKI. But trying to replace 
them by a scheme that offers even less security doesn't make sense to me.

More below.

	Yaron

> Date: Wed, 26 Jan 2011 08:58:48 -0800
> From: Paul Hoffman<[email-masked]>
> Subject: Re: [keyassure] Using trust anchor language
> To: [email-masked]
> Message-ID:<[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 1/26/11 8:27 AM, Yaron Sheffer wrote:
>> 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.
>
> 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.
>
Yes, but the object that asserts a claim ("I am THIS subject, and I am 
the holder of THIS public key") is the cert itself, not its hash.

>> Second, we use a lower-case "can" for a critical process. A compliant
>>   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.
>
This is plain nonsense. Of course someone can be playing games. We are 
talking of someone using TLSA for the purpose for which TLSA was 
established, i.e. to set up a secure TLS connection.

And you ARE defining a security policy by saying these certs are to be 
used 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).
>
> 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.
>
So we are in complete agreement. I would like to focus on the 99.9% of 
the world who do not have fancy policies and will take you at your 
world: use these certs as trust anchors. We need to specify a 
*reasonable* secure policy for such clients. What we have now is not 
reasonable.

>> Does this mean the RP should not even try to validate the cert?
>
> Correct: that is the definition of a trust anchor.
>
No wonder. I consulted RFC 4949 before posting :-)

>> 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.
>
> There is no such thing as a "DNS registrar". Please choose a phrase that
> exists. Also, what does "have access" mean?
>
Please don't nitpick, Wikipedia seems to understand what I mean: 
http://en.wikipedia.org/wiki/Domain_name_registrar). "Have access" 
means: "can read and validate it".

>> - The registrar MUST ensure that the certificate is valid, and/or must
>> 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?
>
True. For self-signed certs, the Registrar needs to verify that the 
non-key information is correct. Like, call you on the phone to make sure 
you exist. Yes, just like a traditional CA.

>> - In particular the registrar MUST ensure that the certificate does not
>> 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.
>
You are telling the RP to add the cert as a trust anchor. Then you are 
saying I can have my certs include DNS:vpnc.org as a Subject Alt Name, 
and any RP will happily accept them.

>> - The registrar MUST establish a Certificate Practice Statement (CPS)
>> and make it publicly available.
>
> Why would an entity that does not issue certificates need a CPS?
>
It doesn't generate the cert. But it effectively signs it. So yes, it 
"issues" a certificate.

>> I have a feeling this is NOT what you meant. But I fail to understand
>>   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.
>
>
It is only too clear now.

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 27 Jan 2011 13:51:59 +0100

On 27 jan 2011, at 07.40, Yaron Sheffer wrote:

> If the DNS registrar signs anything more than the public key, in particular if it signs the Subject or Subject Alt Name on a certificate, and if we specify explicitly that this cert is to be used as a trust anchor, then the registrar acts as a CA. So, like it or not, it needs to play by CA rules.

With "DNS registrar" I assume you mean the person responsible for editing the DNS information. In the DNS world, the registrar is actually the organization registering new domains names in a DNS registry on behalf of the registrant - e.g., Godaddy is a registrar. I suggest we use the term "DNS administrator" instead.

> If all you sign is the public key, and if you mandate that the cert MUST only be associated with a particular FQDN and the RP MUST ignore non-key material, then we can relax these rules. I think this is the path we should follow if we are to provide a credible, yet secure, alternative to PKI.

The DNS administrator will sign the whole TLSA resource record (RR) - a cert or just a hash of a cert. Even though the whole RR is signed, the DANE specification can still mandate that the client should ignore the hostname part of the cert. Given this, I can generate a self-signed certificate with CN=www.paypal.com and publishing it as a TLSA RR as www.kirei.se. My DNS administrator doesn't need to understand what's in the TLSA RR - he/she just has to publish whatever I submit. The selective ignore part is all on the RP side.

	jakob

---

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

At 8:40 AM +0200 1/27/11, Yaron Sheffer wrote:
>Hi Paul,
>
>if earlier I was confused, now I am extremely worried. It seems to 
>me than with the goal of simplifying the protocol, you are removing 
>all remnants of operational security.
>
>particular if it signs the Subject or Subject Alt Name on a 
>certificate, and if we specify explicitly that this cert is to be 
>used as a trust anchor, then the registrar acts as a CA. So, like it 
>or not, it needs to play by CA rules.
>
>If all you sign is the public key, and if you mandate that the cert 
>MUST only be associated with a particular FQDN and the RP MUST 
>ignore non-key material, then we can relax these rules. I think this 
>is the path we should follow if we are to provide a credible, yet 
>secure, alternative to PKI.
>
>I am well aware of the failings of commercial PKI. But trying to 
>replace them by a scheme that offers even less security doesn't make 
>sense to me.
>
>More below.
>
>	Yaron

Yaron,

I agree that we have to be careful in the design that DANE adopts, to avoid
undermining the current level of security offered for TLS. I think 
this can be done safely with either a "bare" key or a cert as the 
contents of the signed record. An advantage of using a cert is that 
it might be easier to make use of the rest of the TLS cert processing 
software, i.e., minimize the impact of using DNS. For example, we 
could require that the cert contain a SAN of the form DNSname, and 
mandate checks to ensure that the SAN is consistent with the
DNS context from which it was acquired (he said, imprecisely).

I disagree that the client (RP) needs to ignore everything in a cert acquired
in this fashion. If we impose appropriate rules, we can make this 
safe. I view the rules as a form of pre-processing applied to the 
cert before accepting it for use, e.g., as a TA.

Steve

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 28 Jan 2011 01:31:08 +0200

Hi Steve,

I am fine with the idea of a limited trust anchor, relevant only for 
that specific host name.

I am very suspicious of the "code reuse" argument. I agree with you that 
a set of rules is needed (I assume you mean RP-side rules), so that the 
RP is not fooled into trusting unverified pieces of the cert. But that 
would only add complexity to the already complex cert processing code, 
and might end up undermining its security. This would not be a good thing.

Can you please explain (informally) what stuff in the cert can be 
trusted by the RP, other than the public key? For example, if the cert 
contains some future X.509 extension ("the Subject's eyes are blue") - 
should it be trusted by the RP as applying to the TLS endpoint?

And lastly, referring to your other email, can you please be more 
specific about the domain name constraints, i.e. what exact part of the 
SIDR spec you propose that we adopt here?

Thanks,
	Yaron

On 01/27/2011 05:56 PM, Stephen Kent wrote:
>> certificate, and if we specify explicitly that this cert is to be used
>> as a trust anchor, then the registrar acts as a CA. So, like it or
>> not, it needs to play by CA rules.
>>
>> MUST only be associated with a particular FQDN and the RP MUST ignore
>> non-key material, then we can relax these rules. I think this is the
>> path we should follow if we are to provide a credible, yet secure,
>> alternative to PKI.
>>
> undermining the current level of security offered for TLS. I think this
> can be done safely with either a "bare" key or a cert as the contents of
> the signed record. An advantage of using a cert is that it might be
> easier to make use of the rest of the TLS cert processing software,
> i.e., minimize the impact of using DNS. For example, we could require
> that the cert contain a SAN of the form DNSname, and mandate checks to
> ensure that the SAN is consistent with the
> in this fashion. If we impose appropriate rules, we can make this safe.
> I view the rules as a form of pre-processing applied to the cert before
> accepting it for use, e.g., as a TA.
>
> Steve

---

From: Martin Rex <[email-masked]>
Date: Fri, 28 Jan 2011 02:05:37 +0100 (MET)

> I am fine with the idea of a limited trust anchor, relevant only for 

I think that notion of "valid for only the specific hostname"
that was used for retrieving this cert or cert hash through TLSA
under DNSSEC protection has always been silently assumed -- and
needs to / is going to be spelled out.
 
> 
> I am very suspicious of the "code reuse" argument.

Me2.   :)

> I agree with you that a set of rules is needed (I assume you mean
> RP-side rules), so that the RP is not fooled into trusting unverified
> pieces of the cert. But that would only add complexity to the already
> complex cert processing code, and might end up undermining its security.
> This would not be a good thing.

Personally, I think there is actually _nothing_ besides the public key
that can be trusted in a cert purely identified by DANE (TLSA) and
authenticated through DNSSEC.

What should be described is which particular usage restrictions contained
in the cert should be honoured, that are _not_ sensitive to a
particular context.  Any name-related attributes in a certificate
are highly context sensitive and need to be entirely ignored.

(Mostly) context-free attributes would be
  - KeyUsage
  - Validity
and _maybe_ "ExtendedKeyUsage"

-Martin

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 28 Jan 2011 10:15:27 +0200

Hi Martin,

I completely agree. Just a note on terminology: I am confused by the 
terms "context sensitive" and "context free" in this setting; I think a 
better distinction would be between "informative" versus "restrictive" 
attributes. But we probably just need to spell out the individual 
properties, as you did in your mail.

Thanks,
	Yaron