Subject: [dane] simple key management (was: issue #37 I think)

From: Stephen Farrell <[email-masked]>
Date: Wed, 01 Feb 2012 12:21:26 +0000

Hi all,

Here's my take on what I think this topic is about.

If folks are unhappy with details of 5280 then the place
to deal with that is in PKIX. If you're radically unhappy
with PKIX, then we have a list for discussing possible
new approaches ([email-masked]) so go there.
Neither of the above are really appropriate for long
discussions on the DANE list. (And since there never
seems to be a *short* discussion on the DANE list,
I guess that means that they're just not appropriate:-)

Meanwhile, we have 5280 and its the standard way to
handle x.509-based PKI in IETF protocols. So when a
DANE client is doing PKIX/5280 then that's what they
should do. Whether or not existing implementations do
that well or badly is also not a topic for DANE.

When a DANE client is not using any CA then 5280 is not
very relevant, except for defining a container format
for public keys. It seems to me that -14 does support
this (as called for in 6394) but that that could be
made a good bit clearer.

In particular I reckon that the protocol doc should
make it more clear that if 2,0,0,V is the value in
the TLSA RR and C is the server cert provided in the
TLS handshake, and if V==C and the TLSA record
ValState is SECURE, then Finish(2) is the right
result. (And similarly for selector==1 and matching
rules 1 and 2, with appropriate changes.)

I also think that -14 section 5 is wrong in how it
describes how we meet the "simple key management"
requirement from 6394 - IMO it ought say that you
meet this requirement by supporting the mode of
operation in the paragraph I've just written above.

In terms of making the above clearer in the protocol
draft, one way (not the only possible way) I'd suggest
is to say that "PKIX validation" does mean 5280 section
6 (or however you want to say that) but also say
that in implementing usage 2, you can do anything
that's equivalent to first doing the test described
above and then following that with PKIX validation
with the same inputs if the test above doesn't
result in Finish(2). There are probably a few other
language tweaks that would flow from that but I'd
say those should be easy enough.

Note that the above is not based on re-reading all
the recent mail on the list, but from reading -14
and 6394 and the bits of the list discussion that I
managed to remember in my little head:-) So its
possible someone already said this and got shot
down for one reason or another. I'm fine with
arguing the point if that's the case.

Cheers,
S.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 1 Feb 2012 12:11:55 -0800

> this (as called for in 6394) but that that could be

It is *meant* to support it, but it became clear that some people think it does not.

> result.

That makes good sense. However...

> (And similarly for selector==1 and matching

It is in these details that some people have strong objections, so I would like to tease them apart.

For selector = 1 (SPKI instead of full cert), there is an argument that most/all PKIX libraries do not let you ask "what is the SPKI of this cert", so it would not make sense for a site to hope that a client could do this.

Matching rules 1 and 2 (hashes instead of full content) should be fine if done on the full cert.

With that, would you find it acceptable to say that usage type 2 MUST be used with selector type 1?

As for the definition, we could say "The target certificate either MUST match the one in the TLSA record, or MUST pass PKIX validation with any certificate matching the TLSA record considered to be a trust anchor for this validation". Alternately, one that is different than what we have specified for most of the time but is probably what most people want, is simply "The target certificate either MUST match the one in the TLSA record" and not have a way for DANE to give a new trust anchor. The second alternative is like type 1 but with no expectation that the cert chains to a trust anchor for the client.

Thoughts?

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 1 Feb 2012 12:26:11 -0800

> With that, would you find it acceptable to say that usage type 2 MUST be used with selector type 1?

Sorry, MUST be used with selector type 0.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 01 Feb 2012 22:45:49 +0000

Hi Paul,

>> For selector = 1 (SPKI instead of full cert), there is an argument that most/all PKIX libraries do not let you ask "what is the SPKI of this cert", so it would not make sense for a site to hope th…

Teasing it out sounds good.

Hmmm. I don't feel strongly about this but I
don't see why that needs to be the case nor
why things might not change if useful. I'm not
so sure we should drive this based on current
APIs offered by libraries. And its not like
its hard to pull an SPKI out of an encoded
cert.

What's really wrong with 2,1,[x],V in a TLSA
RR?

Has anyone written the client code for that?

Ta,
S.

---

From: Scott Schmit <[email-masked]>
Date: Thu, 2 Feb 2012 01:00:44 -0500

On Wed, Feb 01, 2012 at 10:45:49PM +0000, Stephen Farrell wrote:
> >>>In particular I reckon that the protocol doc should make it more
> >>>clear that if 2,0,0,V is the value in the TLSA RR and C is the
> >>>server cert provided in the TLS handshake, and if V==C and the TLSA
> >>>record ValState is SECURE, then Finish(2) is the right result.
> >>
> >>>(And similarly for selector==1 and matching rules 1 and 2, with
> >>>appropriate changes.)
> >>

I haven't seen a lot of strong objection?

> >>For selector = 1 (SPKI instead of full cert), there is an argument
> >>that most/all PKIX libraries do not let you ask "what is the SPKI of
> >>this cert", so it would not make sense for a site to hope that a
> >>client could do this.
> 
> Hmmm. I don't feel strongly about this but I don't see why that needs
> to be the case nor why things might not change if useful. I'm not so
> sure we should drive this based on current APIs offered by libraries.
> And its not like its hard to pull an SPKI out of an encoded cert.
> 
> What's really wrong with 2,1,[x],V in a TLSA RR?
> 

I've written some python code to generate the TLSA records. The openssl
and NSS python APIs don't provide a way to get the SPKI out of the
certificate.  I worked around the issue by using openssl's commandline
tool to do an ASN.1 parse of the cert and extract out the SPKI that
way.

I've thought about writing patches for those libraries to provide
functions to extract the data, but haven't found the time to do so. It
seems like it should be easy for someone already familiar with the code,
since the libraries need to be able to get at the various certificate
parts for themselves anyway.

I agree that the mechanism seems too useful to allow current lack of
code to prevent us from specifying it--it's not unimplementable, there
just hasn't been a reason to expose an API for extracting the SPKI from
a certificate until now.

> >Sorry, MUST be used with selector type 0.

IMHO, that's over-restrictive. This seems adequate to resolve the issues
you're alluding to (if I understand correctly, making sure the client
has enough information to know what the TA *is*):
a) If the TA is not known to the client and is omitted from the provided
   cert chain, the selector type MUST be 0 and the match type MUST be 0.
b) If the TA is known to the client and/or is included in the provided
   cert chain, selector type 1 and/or match type 1 or 2 MAY be used.

Now, using an SPKI *as* the TA is another matter. My interpretation of
the draft (though it's not crystal clear on this point because of its
mixed use of the word "certificate") and the consensus around issue #29
is that the selector is intended to select a certificate (using the SPKI
as match criteria) not a SPKI.  This would prevent us from omitting a TA
unknown to the client from the certificate chain and having a TLSA 2 1 0
record (because there's no certificate for the client to match). Well,
you could do it, but it wouldn't work.

Using a SPKI as the TA would require a new cert usage type.

> >>As for the definition, we could say "The target certificate either
> >>MUST match the one in the TLSA record, or MUST pass PKIX validation
> >>with any certificate matching the TLSA record considered to be a
> >>trust anchor for this validation"

> >>Alternately, one that is different than what we have specified for
> >>most of the time but is probably what most people want, is simply
> >>"The target certificate either MUST match the one in the TLSA
> >>record" and not have a way for DANE to give a new trust anchor. The
> >>second alternative is like type 1 but with no expectation that the
> >>cert chains to a trust anchor for the client.

I think there is a typo in the above: you probably meant to strike
the "either" in the MUST statement (or you left out the "or" clause).
I'll go with the former.

Let's say hypothetically that we have the following usages:
0 - PKIX+CA (i.e., same as current spec)
1 - PKIX+EE (i.e., same as current spec)
2 - PKIX with the specified TA (i.e., same as current spec)
3 - Exactly this EE cert, ignore how it's signed ("match the record")
    [Another way to put this is that it's really signed by the DNS key]

(Incidentally, this is how the current set of cert usage types were
initially proposed, except that 3 was marked as "future".)

For small domains, 1 & 3 will probably get the most use.  For large
domains, I could imagine that 0 & 2 would be more popular so that the
zone administrators don't need to keep up with the certificate rollovers
(depending on how easy/difficult it is for them to hook into whatever
process keeps track of certificate renewals and generate the appropriate
TLSA records). So it doesn't seem like any of the types would be unused.
(i.e., I don't see a reason to eliminate the current usage type 2.)

That said, if we're trying to reduce complexity, we could probably drop
type 1 because the domain could always use type 3 and get the same (or
from their point of view better) effect in most cases. AFAICT, the only
advantage type 1 has over type 3 is that if the EE cert is revoked
(appropriately), and the domain doesn't do anything with the TLSA
record, the clients are protected. On the other hand, the domain doesn't
need to worry about whether the CAs/TAs attesting to their cert is
trusted by all/most of their clients if they use type 3 instead of type
1. Most domains will probably see more benefits in type 3 than type 1.

If I'm associating to a public CA, I would probably prefer to use type 0
rather than type 2, since I would otherwise put my users (and my
reputation) at risk if a CA key is compromised. If I have my own private
CA, I would use type 2 (otherwise it wouldn't work).

HTH

-- 
Scott Schmit

---

From: Martin Rex <[email-masked]>
Date: Thu, 2 Feb 2012 20:49:04 +0100 (MET)

> 3 - Exactly this EE cert, ignore how it's signed ("match the record")

Seperating 2 into 2+3 is extremely desirable, because of the other

>    cert chain, selector type 1 and/or match type 1 or 2 MAY be used.

While a TLS server must always send his TLS certificate with the
public key that was used for the crypto operation in the TLS protocol
itself (including when the TLS server is using a self-signed cert),
there is a significant difference about path certificates.

  TLSv1.0 rfc2246 7.4.2 Server Certificate
  http://tools.ietf.org/html/rfc2246#page-39

   certificate_list
       This is a sequence (chain) of X.509v3 certificates. The sender's
       certificate must come first in the list. Each following
       certificate must directly certify the one preceding it. Because
       certificate validation requires that root keys be distributed
*>     independently, the self-signed certificate which specifies the
*>     root certificate authority may optionally be omitted from the
*>     chain, under the assumption that the remote end must already
*>     possess it in order to validate it in any case.

For Usage 2 with path certificates (or their SPKI) from a private CA,
rather than the server's own certificate, the exemption from above no
longer applies, because the remote end does _not_ already possess
that cert.  TLS Servers that should be used with Usage 2 MUST always
send the full certificate path, including the self-signed rootCA cert
at the end.
   
-Martin