Subject: [keyassure] dane-04 trust anchors

From: Yaron Sheffer <[email-masked]>
Date: Fri, 11 Feb 2011 09:26:33 +0200

Hi,

the new text is a major improvement over the previous version. But it is 
still missing some necessary guidance.

My reference scenario is this: I am a phisher. I'd like to trick 
BigBank's customers, so I acquire bigbang.com (an easy misspelling). Now 
I can get a certificate that they will use as a trust anchor, and 
include whatever I want in it, such as the Subject field, "Your trusted 
BigBank".

Moreover, even if I am the rightful owner, the current text does not 
allow me to restrict the certificate's use.

So I propose the following text added:

Client treatment of any non-key information included in the trust anchor 
is a matter of local policy. It is noted that this specification does 
not mandate that such information be inspected or validated by the 
domain registrar.

The client MUST obey any constraints included in the trust anchor, 
including but not limited to:
- Validity period.
- Key usage fields.
- Path length constraints.
- Name constraints.
The normal rules of RFC 5280 apply.

Thanks,
	Yaron

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 11 Feb 2011 09:01:39 -0500

This is an issue, but a fairly easy one to deal with and one that is already
dealt with when dealing with self-signed certs. The browser writers know
this stuff already.

Some of the people who were doing security code in 1995 were clueless. In
fact we all pretty much were (but in different ways). But that has not been
an issue since Netscape hired Taher and the brothers Weinstein.

There is a very simple principle here:

DNS cannot extend any positive claims beyond the DNS name itself

DNS can however extend negative claims and restrictions.

A domain can't say 'trust me I am a bank' but it can say 'take extra
security precautions, in case I am a bank'

On Fri, Feb 11, 2011 at 2:26 AM, Yaron Sheffer <[email-masked]>wrote:

> My reference scenario is this: I am a phisher. I'd like to trick BigBank's
> customers, so I acquire bigbang.com (an easy misspelling). Now I can get a
> certificate that they will use as a trust anchor, and include whatever I
> want in it, such as the Subject field, "Your trusted BigBank".
>
> Moreover, even if I am the rightful owner, the current text does not allow
> me to restrict the certificate's use.
>
> Client treatment of any non-key information included in the trust anchor is
> a matter of local policy. It is noted that this specification does not
> mandate that such information be inspected or validated by the domain
> registrar.
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 11 Feb 2011 08:44:09 -0800

> include whatever I want in it, such as the Subject field, "Your trusted

Good scenario.

> allow me to restrict the certificate's use.

Correct. That is on purpose.

> not mandate that such information be inspected or validated by the

Sounds good to me.

> The normal rules of RFC 5280 apply.

As Steve Kent pointed out earlier on the list, the normal rules of RFC 
5280 for trust anchors disagrees with that list you gave. I would prefer 
to follow the normal rules of RFC 5280 for trust anchors, and not come 
up with ones of our own.

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 12 Feb 2011 13:58:12 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Hoffman
> Sent: Friday, February 11, 2011 8:44 AM
> To: [email-masked]
> Subject: Re: [keyassure] dane-04 trust anchors
> 
> > the new text is a major improvement over the previous version. But it
> > is still missing some necessary guidance.
> >
> > BigBank's customers, so I acquire bigbang.com (an easy misspelling).
> > Now I can get a certificate that they will use as a trust anchor, and
> > include whatever I want in it, such as the Subject field, "Your
> > trusted BigBank".
> 
> Good scenario.
> 
> > Client treatment of any non-key information included in the trust
> > anchor is a matter of local policy. It is noted that this
> > specification does not mandate that such information be inspected or
> > validated by the domain registrar.
> 
> Sounds good to me.
> 
to follow
> the normal rules of RFC 5280 for trust anchors, and not come up with ones
of
> our own.

I think that it is perfectly reasonable to say that the information is to be
extracted from the provided certificate and used as the starting conditions
for the certificate validation process.  This does not change the rules for
5280 trust anchors as the information can come in from an external
configuration.

Many systems already will seed that initial configuration of the other
variables used in the process from the data contained in the trust anchor,
allowing for it to be changed or overridden by either system or trust
administrators.

Jim

---

From: Paul Wouters <[email-masked]>
Date: Sun, 13 Feb 2011 14:58:29 -0500 (EST)

On Fri, 11 Feb 2011, Yaron Sheffer wrote:

> certificate that they will use as a trust anchor, and include whatever I want 
> in it, such as the Subject field, "Your trusted BigBank".

This is another reason for a "bare public key" type. This is indeed an issue
that browser vendors have to deal with now.

> Client treatment of any non-key information included in the trust anchor is a 
> matter of local policy. It is noted that this specification does not mandate 
> that such information be inspected or validated by the domain registrar.

Why mention "domain registrar"? Those are not a party at all in anything here.

> The client MUST obey any constraints included in the trust anchor, including 
> but not limited to:
> - Validity period.

What to do if that period does not match the DNS TTL/RRSIG period?

> The normal rules of RFC 5280 apply.

I'd rather see something saying everything except the public key should be "local
policy", and no "MUST obey" items are present.

Especially since that reduces the amount of ASN.1 parsing. Remember, now we don't
even have the flawed SSL providers sanity checks on anything.

Paul

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 13 Feb 2011 23:44:55 +0200

Hi Paul,

please see my comments below.

Thanks,
	Yaron

> that browser vendors have to deal with now.
I am all in favor of bare public keys. But if people insist on having a 
self-signed certificate instead, we should specify what its semantics are.

> Why mention "domain registrar"? Those are not a party at all in anything
Some person/organization signs the TLSA record. I would like to mention 
explicitly that this person/organization does not validate anything that 
is referenced from this record.

> What to do if that period does not match the DNS TTL/RRSIG period?
I guess the more constrained validity prevails.
> policy", and no "MUST obey" items are present.

"Local policy" is an OK statement for intra-enterprise deployment. It 
makes little sense in consumer cases. Do we want each browser to have 
its own security policy?
> even have the flawed SSL providers sanity checks on anything.

Again, if the application is given a cert, it should parse it. It cannot 
just ignore it. If we say that bare public keys are the RECOMMENDED 
option, fine with me.

---

From: Scott Schmit <[email-masked]>
Date: Sun, 20 Feb 2011 00:35:10 -0500

> What to do if that period does not match the DNS TTL/RRSIG period?

The DNS TTL should be used to determine when the client MUST forget the
certificate association and refetch the TLSA record if it needs it
again.  I think that's the DANE equivalent to revocation (if the TLSA
record is replaced, the old cert was revoked).

The RRSIG period serves a similar role to the Validity period in X.509,
though it'll be much shorter than we're used to for PKIX. I would think
that the most restrictive value wins. The notAfter field can always be
set to be never to avoid needing to regenerate the certificate.

You could probably argue that what I'm saying to use the TTL for is what
the RRSIG period is for, but in my experience with DNSSEC tools, it's a
lot more obvious to me how I'd control (without affecting the period for
other records) the rate a client rechecks the certificate validity via
the TTL.

-- 
Scott Schmit

---

From: Martin Rex <[email-masked]>
Date: Mon, 21 Feb 2011 22:38:10 +0100 (MET)

> record is replaced, the old cert was revoked).

There seems to be confusion about the purpose of TTLs in DNS
(and and the fact that TTL is _not_ protected by DNSSEC).

See previous discussion, e.g.
http://www.ietf.org/mail-archive/web/keyassure/current/msg01190.html

While expiring cached records at TTL time make sense with or without
DNSSEC, one must be aware that an attacker could replay DNSSEC signed
records for as long as the RRSIG signature allows.  Therefore, TTL
can not be considered a revocation mechanism.

-Martin

---

From: Henry Story <[email-masked]>
Date: Mon, 21 Feb 2011 23:01:31 +0100

> record is replaced, the old cert was revoked).

<webid parallel="cool" thread="http://www.ietf.org/mail-archive/web/keyassure/current/msg01877.html">

 1. the DNS Time To Live (TTL) is in WebID the HTTP Expires header
 2. In WebID if the public key is no longer listed at the WebID Profile then the client certificate is revoked. In Dane when the key is removed from DNSsec the same happens.
 3. In WebID there is an interesting twist: the client certificate not-before, not-after time constraints can be very useful for end users that are perhaps on less trusted machines and wish to create themselves a time limited certificate. Those people should get their Social Web server to create them a 1 hour certificate so that misuse of the certificate can only last so long.

</webid>

> other records) the rate a client rechecks the certificate validity via

Social Web Architect
http://bblfish.net/