Subject: [keyassure] Introducing draft-josefsson-keyassure-tls-00.txt

From: Simon Josefsson <[email-masked]>
Date: Mon, 23 Aug 2010 10:00:25 +0200

Folks,

I have published the following document:

http://www.ietf.org/id/draft-josefsson-keyassure-tls-00.txt

It is similar to the draft-hoffman-keys-linkage-from-dns-00 document and
my inspiration for writing this came from that draft (thanks guys!).
However, there are a number of essential differences:

A) It uses the CERT RR with no alternatives.  I believe the CERT RR is
   intended for this, or at least a very similar purpose, and it is
   exensible enough to support this approach.

B) It confirms the entire TLS Certificate structure rather than just a
   X.509 public key.  There are two important advantages with this:

   1) OpenPGP in TLS is supported directly, as is any other certificate
      based authentication scheme that is using the TLS Certificate
      structure.

   2) The entire certificate, and even its chain, is confirmed by Secure
      DNS.  This allows the client to store the certificate locally and
      mark it as verified for a particular domain.  Further, some
      applications is relying on the content of certificates (think
      X.509 extensions).  With this proposal, the entire certificate is
      confirmed by DNSSEC, but with
      draft-hoffman-keys-linkage-from-dns-00 only the public key is
      directly confirmed.

C) It makes it possible to have different services on the same port but
   on different protocols (TCP vs UDP).  In
   draft-hoffman-keys-linkage-from-dns-00 I do no see a way to run a
   DTLS service on UDP and a TLS service on TCP on the same port number
   and reliably learn the intended hash.

D) It reduces DNS transfer sizes by splitting unrelated services into
   separate domain names.  Consider if EXAMPLE.COM has 100 different
   services running all using TLS.  With the CERT RR type in
   draft-hoffman-keys-linkage-from-dns-00, a client querying for any
   service will get the hash of the key used for all 100 services.  This
   causes an unnecessary high load on the DNS servers and increased
   message sizes.

E) The RR data is only a hash value, and there are no binary integer
   encoding and variable length string issues.  Administrators can add
   the hash value in DNS zone files by adding the record easily.

F) There is a one-to-one mapping between the RR in the zone file and a
   particular TLS-enabled service.  This means that it is possible to
   delegate authority for the RR to the person responsible for that
   TLS-enabled service.  In draft-hoffman-keys-linkage-from-dns-00, if a
   service on port 4711 changes RSA key, this leads to a CERT RR change
   even for the CERT RR used for port 443.  In production environments,
   I would not want to touch the 443 CERT RR just because someone is
   adding an unrelated and potentially experimental service.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 23 Aug 2010 14:14:03 +0200

> However, there are a number of essential differences:

I forgot this nice feature:

G) The TLS library does not have to do ASN.1/DER decoding to find the
   public key to hash before comparing with the DNS data.

A TLS library without ASN.1/DER but with X.509 certificate validation
via CERT would be possible.  Yay.

/Simon

---

From: Steve Schultze <[email-masked]>
Date: Mon, 23 Aug 2010 09:22:57 -0400

Does this allow for wildcards in these CERT records?
What happens when there are multiple certs per service?  How many certs is too many?
Where in the record can you place options such as additional hash algorithms, or do you expect this to remain static for all time?

On signing the entire cert (B.2.), I do not believe that the zone operator is in the position to assert anything about the contents of the cert other than the domain-to-key mapping.  Any additional assertions (such as company name) are validated by the CA that issued the cert, and trusted because the CA is trusted.  Even if bank-of-america.com signs a cert saying that the domain owner is "Bank of America Corp.", there's no reason for me to blindly trust that assertion simply because the zone controller says it is so.  The only reason to trust it is if a trusted CA has signed the cert (in particular, the EV cert) and in that case it's irrelevant whether the zone controller published the hash of the entire cert or not.  On the other hand, publishing a hash of only the key means that client protocols that do not use X.509 certs can simply do basic key exchange and check that against DNS.

On Aug 23, 2010, at 4:00 AM, Simon Josefsson wrote:
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 23 Aug 2010 09:45:32 -0400

Reading asn.1 is really not difficult. Writing out DER encoding is painful in the extreme because the designers made a major goof. 

I have written code to parse asn.1 in JavaScript. It is really no biggie.

The hash has to go over the full cert data or else you are passing trusted attributes in an untrusted fashion. That would be utterly abominable security practice. 

We could do with a set of design goals. I suggest as starters

* multiple has algorithms
* multiple certs per host for different protocols
* multiple certs per service for multiple hosts
* support dynamic port assignment 
* nat friendly
* client side certs for machine to machine protocols
* validation of a cert that is in hand
* discovery of a cert bound to a service

I can meet all of these with either the CERT record or a new RR

On the constraints side we have

* must be wildcard safe 
* ability to use wildcards to specify certs for wild carded services.

I believe we still need a new RR for the purpose of telling clients what protocol enhancements to use when connecting to a service. For example, is tis on offer for imap. DNSSEC should allow me to answer that question with certainty. I do not want to overload CERT for that purpose.

Sent from my iPad

---

From: Steve Schultze <[email-masked]>
Date: Mon, 23 Aug 2010 10:47:18 -0400

> The hash has to go over the full cert data or else you are passing trusted attributes in an untrusted fashion. That would be utterly abominable security practice. 

How so?  The only way those attributes should be trusted is if a CA that signed the cert is trusted, as I described.  If you trust the CA, then the attributes are passed in a trusted fashion because the cert is signed.  As such, it is irrelevant whether the hash presented by the zone controller covers those attributes.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 23 Aug 2010 11:01:28 -0400

SSL use can be controlled by key use bits and extensions in the cert.

Given the choice between giving people with brains the information
they need to do the job right and not giving the information in case
it is misused by cretins, I suggest taking the first approach.

Part of what I would like to see happen here is to focus attention on
the difference between what is asserted in a cert and what is
trustworthy.

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

---

From: Paul Wouters <[email-masked]>
Date: Mon, 23 Aug 2010 11:08:13 -0400 (EDT)

>      draft-hoffman-keys-linkage-from-dns-00 only the public key is

This seems wrong to me. This is now mixing two authority sources, DNSSEC
and the CA. And it introduced the possibility of conflicting authoritve
sources. Other problems that come to mind are subjectAltnames that are
in the wrong spot in the DNS hierarchy.

I can understand using the container X.509 format, but it should really
(IMHO) be limited to just the verification of the public key.

>   causes an unnecessary high load on the DNS servers and increased

This also seems to be able to conflict with valid key use as specified
in the X.509 certificate extended properties.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 23 Aug 2010 11:15:24 -0400 (EDT)

> I have written code to parse asn.1 in JavaScript. It is really no biggie.

A search for "ASN.1" at http://web.nvd.nist.gov/ gives me 13 hits.

Openswan (the project I develop for) had to released two CVE's in 7 years.
One of those was an ASN.1 bug.

ASN.1 is not trivial, and it is really best avoided if possible.

> I can meet all of these with either the CERT record or a new RR

But your list can also be changed s/cert/pubkey/g

> I believe we still need a new RR for the purpose of telling clients what protocol enhancements to use when connecting to a service. For example, is tis on offer for imap. DNSSEC should allow me to…

Yes, and ideally that new RR should come in as additional record when the query had some kind of EDNS
option set.

Paul

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 23 Aug 2010 08:19:35 -0700

> (IMHO) be limited to just the verification of the public key.

Except that, IMO, there is a huge advantage to be had on simplicity of just verifying the ENTIRE certificate.  Who says CERT RR's need to be just X.509 format?  

If the model is the only part validated is the public key in the cert, that means that DNS resolver, DNS APIs, and authorities need to be aware of the X.509 format.  

But if the entire record is just validated as a single binary blob, this means that different certificate formats could be used in the future without needing to change anything other than the application which is the final consumer of the new certificate type.

---

From: Steve Schultze <[email-masked]>
Date: Mon, 23 Aug 2010 11:20:00 -0400

> it is misused by cretins, I suggest taking the first approach.

I'm having trouble figuring out who the cretins vs the people with brains are in your scenario, but fortunately it doesn't matter if we design a system in which people can assert only what they are trusted to assert.

If your concern is...
> SSL use can be controlled by key use bits and extensions in the cert.

Then the answer is twofold:
1. these bits can continue to be used, and will be trusted if the CA is trusted
2. if you wish to enforce this in the absence of a CA-trusted cert, we can include an option in the RR standard for requiring SSL (which is an assertion that the zone controller can be trusted to make)

---

From: Paul Wouters <[email-masked]>
Date: Mon, 23 Aug 2010 11:36:02 -0400 (EDT)

> Except that, IMO, there is a huge advantage to be had on simplicity of just verifying the ENTIRE certificate.  Who says CERT RR's need to be just X.509 format?

So what is wrong with RFC 4398? You already have that. Your app grabs
the CERT via CERT RR and then your application can do all its Cert/CA
based validation it wants to. I am not saying that is wrong - I just
don't understand why you need another RFC for that.

I think there is a strong desire to have the option of not using X.509
or PKIX at all, and base validation and verification purely on DNSSEC
as a trust model.

I thought this group was to work on a good standard for those
applications, and that those who want to use certs, can stick with using
RFC 4398 (or non-DNS based validation, eg EVR)

Paul

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 23 Aug 2010 08:39:45 -0700

> don't understand why you need another RFC for that.

Except you still need an API to understand the DNSSEC chain involved in validating that CERT binary blob and to handle failures in a reasonable manner...

> or PKIX at all, and base validation and verification purely on DNSSEC

I think of CERTs as not really requiring PKIX, eg, self-signed certs become much more useful if they are validated through DNSSEC.

> RFC 4398 (or non-DNS based validation, eg EVR)

In many ways, I somewhat agree, but for a different reason:  CERT RRs are just a perfectly fine container class.  We probably don't need new RR types.

What we need is ways of using such container classes with DNSSEC: this doesn't add any new to-the-wire representatiton, but does require new ways (APIs, naming conventions) of using the DNSSEC data, both at a low level (APIs) and high level ("cookbook recipies").

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 23 Aug 2010 11:41:26 -0400

I think the argument here is that making the hash cover only the key
means that the DNS processing layer needs to be aware of much more of
the internals of the cert format than he would like.

I agree.

Putting the authentication round the whole cert is much cleaner and
means that there is a better layer separation.

On Mon, Aug 23, 2010 at 11:36 AM, Paul Wouters <[email-masked]> wrote:
>> Except that, IMO, there is a huge advantage to be had on simplicity of
>> just verifying the ENTIRE certificate.  Who says CERT RR's need to be just
>> X.509 format?
>

---

From: Stephen Schultze <[email-masked]>
Date: Mon, 23 Aug 2010 12:00:21 -0400

On Aug 23, 2010, at 11:19 AM, Nicholas Weaver wrote:
> Except that, IMO, there is a huge advantage to be had on simplicity  
> of just verifying the ENTIRE certificate.  Who says CERT RR's need  
> to be just X.509 format?

If CERT RR's (or whatever RR we choose) contain public keys, then the  
standard supports an arbitrary number of cert formats without creating  
the need for an additional record every time an application wants a  
different type of cert.

> If the model is the only part validated is the public key in the  
> cert, that means that DNS resolver, DNS APIs, and authorities need  
> to be aware of the X.509 format.

Why is that?  Only the application needs to be aware of X.509 (or, in  
the case of OpenPGP via TLS, an OpenPGP key).  Once it gets the key  
out , it hashes it and checks it against the DNS hierarchy.

> But if the entire record is just validated as a single binary blob,  
> this means that different certificate formats could be used in the  
> future without needing to change anything other than the application  
> which is the final consumer of the new certificate type.

You would be forcing one of two things, either:
a. every application must be updated to use whatever cert standard you  
chose
b. you  must add duplicate entries for each public key for each new  
cert standard you chose

Neither seems optimal.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 23 Aug 2010 12:41:41 -0400

Why not have the DNSSEC module check the hash against the full certificate?

That way the TLS module does not even need to know it is using DNSSEC
key assurance?

There are two types of information in a certificate besides the key:

1) Assertions concerning properties of the certificate subject
2) Assertions concerning the permitted uses of the key.

Whatever you think about the desirability of authenticating the first.
You will break SSL if you do not authenticate the second set of
information.

The reason that I do not want to modify SSL to use raw keys is that it
was built on an assumption that the second type of information would
be authenticated and assured.

Changing the security assumptions on which an existing protocol is
built is the most common way of breaking them.

I see zero advantage to your approach and I see no way that you, I,
Paul Kocher or anyone else can fully convince themselves that they are
not breaking SSL in some subtle way. Take a look at our recent Client
cert issue which is a consequence of client certs being supported as
an afterthought.

On Mon, Aug 23, 2010 at 12:00 PM, Stephen Schultze <[email-masked]> wrote:
> standard supports an arbitrary number of cert formats without creating the
> need for an additional record every time an application wants a different
> type of cert.
>
>> If the model is the only part validated is the public key in the cert,
>> that means that DNS resolver, DNS APIs, and authorities need to be aware of
>> the X.509 format.
>
> Why is that?  Only the application needs to be aware of X.509 (or, in the
> case of OpenPGP via TLS, an OpenPGP key).  Once it gets the key out , it
> hashes it and checks it against the DNS hierarchy.
>
>> But if the entire record is just validated as a single binary blob, this
>> means that different certificate formats could be used in the future without
>> needing to change anything other than the application which is the final
>> consumer of the new certificate type.
>
> a. every application must be updated to use whatever cert standard you chose
> b. you  must add duplicate entries for each public key for each new cert
> standard you chose
>
> Neither seems optimal.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 23 Aug 2010 13:02:57 -0400 (EDT)

> be authenticated and assured.

The DNS location can show the permitted use. DNSSEC can provide the validation for that.

> built is the most common way of breaking them.

Arguing like that, all X.509 should be removed from DNS and we should all
stick to TXT records.

> not breaking SSL in some subtle way.

SSL currently *is* broken with the 95% self signed certs out there. That
shortcoming is something we're trying to fix - it's too late to prevent it.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 23 Aug 2010 13:18:03 -0400

> The DNS location can show the permitted use. DNSSEC can provide the

So now your proposal is

1) Only sign some of the bits in the cert
2) find some other way to define the other bits we need to sign.

> Arguing like that, all X.509 should be removed from DNS and we should all

No, this is just another way to validate an X.509 certificate path.

Since we already use self-signed certificates, anything that provides
more assurance of the chain above the EE cert is useful.

> shortcoming is something we're trying to fix - it's too late to prevent it.

No, Self-Signed was on the table before SSL v3. We have fifteen years
of experience.

---

From: Stephen Schultze <[email-masked]>
Date: Mon, 23 Aug 2010 14:23:31 -0400

Phillip accidentally sent his response only to me.  His full message  
is at the bottom, but my in-lines are below.

On Aug 23, 2010, at 11:38 AM, Phillip Hallam-Baker wrote:
> The idea of limiting the authentication to the key seems to be because
> people are worried that people 'might do the wrong thing' with it.

I think the idea is that hashing the entire cert indicates that the  
controller of the zone asserts that everything contained in the cert  
is accurate, which is something that they alone do not have the  
authority to do.  The only way to avoid this would be a to create a  
whitelist of cert properties that are to be trusted purely based on  
receiving a DNSSEC-validated answer.

> The only way to ensure that people use nothing but the key is to put
> nothing but the key in the record (which we can do already).

I'm confused, how is it possible already to "put nothing but the key  
in the record"?

> What we are trying to do here is to change the semantics of the CERT
> record so the act of publishing one in the DNS becomes in effect a CA
> certification of those bits. That is a validation path in its own
> right.

Certification of which bits?  All of the bits in the cert, or only  
those that you've decided are allowed?

I do think that I now better understand what you are proposing.   
Correct me if I'm wrong.  You want the ability for whoever controls a  
zone to hash certs and place them in DNS (essentially signing them) so  
that they can make any manner of assertions.  This turns them into  
their own little CA for their own domain.  You would define some  
subset of assertions that are trusted by default as long as they come  
from a signed record  (so far I've seen "text of public key" and "SSL  
required").  However, other assertions might become trusted if the end  
user decides to trust the controller of the zone to a greater degree  
(a degree not justified merely by the fact that they are the  
controller of the zone).  One way of obtaining this greater degree of  
trust might be for a certificate to be signed by a trusted third-party  
(like today's CAs), but evidently you envision some other validation  
path from the signed zone to a trusted root.

I suppose this is an interesting use case, but it would require  
additional client infrastructure to build in trust bits for individual  
zones.  Furthermore, I'm not sure why you wouldn't just use the CERT  
RR as-is, or even add a CERTHASH cert type to CERT.  Combining your  
approach with an approach that simply seeks to enable validated domain- 
to-key mapping based on the properties of DNSSEC itself has the  
following disadvantages:

1. mixing together assertions that require different authority
2. locking in applications to either implementing the cert format you  
choose, or adding duplicative cert hash DNS entries for each new cert  
format

> the reason we are using certs and not just keys is because we need
> those additional bits.

I think that the additional bits needed for fully featured operation  
of domain-to-key mapping (eg: "require SSL") can be easily built into  
the spec, whereas bits that assert other things can still ride in the  
cert itself and be validated by whoever signs the cert (if anyone).

On Aug 23, 2010, at 11:38 AM, Phillip Hallam-Baker wrote:
> The idea of limiting the authentication to the key seems to be because
> people are worried that people 'might do the wrong thing' with it.
>
> My experience is that this is a futile approach. If people are going
> to do the wrong thing with the subject field they are going to do that
> whether or not it is authenticated by the CERT hash.
>
> The only way to ensure that people use nothing but the key is to put
> nothing but the key in the record (which we can do already).
>
>
> What we are trying to do here is to change the semantics of the CERT
> record so the act of publishing one in the DNS becomes in effect a CA
> certification of those bits. That is a validation path in its own
> right.
>
> For example, I might have a device that ships with a device
> certificate. I want to use the device in my network. So I pull the
> cert from the device, take the hash and put the hash into my DNS, thus
> declaring that this is a device I authorize for use with my DNS zone.
>
> The device cert is CA issued and asserts a particular function. I am
> only going to put the cert in my DNS if I endorse that function.
>
> the reason we are using certs and not just keys is because we need
> those additional bits.
>
> Incidentally, one of the reasons we might want a new record is
> precisely because we are changing the semantics of CERT, even if what
> we are doing here is to give it the semantics it should have had in
> the first place.
>
> On Mon, Aug 23, 2010 at 11:20 AM, Steve Schultze <[email-masked]>  
> wrote:
>> I'm having trouble figuring out who the cretins vs the people with  
>> brains are in your scenario, but fortunately it doesn't matter if  
>> we design a system in which people can assert only what they are  
>> trusted to assert.
>>
>> If your concern is...
>> 2. if you wish to enforce this in the absence of a CA-trusted cert,  
>> we can include an option in the RR standard for requiring SSL  
>> (which is an assertion that the zone controller can be trusted to  
>> make)

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 23 Aug 2010 14:42:34 -0400

On Mon, Aug 23, 2010 at 2:23 PM, Stephen Schultze <[email-masked]> wrote:

> I do think that I now better understand what you are proposing.  Correct me
> if I'm wrong.  You want the ability for whoever controls a zone to hash
> certs and place them in DNS (essentially signing them) so that they can make
> any manner of assertions.  This turns them into their own little CA for
> their own domain.  You would define some subset of assertions that are
> trusted by default as long as they come from a signed record  (so far I've
> seen "text of public key" and "SSL required").  However, other assertions
> might become trusted if the end user decides to trust the controller of the
> zone to a greater degree (a degree not justified merely by the fact that
> they are the controller of the zone).  One way of obtaining this greater
> degree of trust might be for a certificate to be signed by a trusted
> third-party (like today's CAs), but evidently you envision some other
> validation path from the signed zone to a trusted root.

That is close but I don't think we can reuse the CERT record and then
put policy information in it such as 'SSL required'.

That should be separated out into another record. Otherwise we end up
treating CERT in the same manner as TXT has been (ab)used.

> I suppose this is an interesting use case, but it would require additional
> client infrastructure to build in trust bits for individual zones.
>  Furthermore, I'm not sure why you wouldn't just use the CERT RR as-is, or
> even add a CERTHASH cert type to CERT.  Combining your approach with an
> approach that simply seeks to enable validated domain-to-key mapping based
> on the properties of DNSSEC itself has the following disadvantages:
>
> choose, or adding duplicative cert hash DNS entries for each new cert format

Actually, this appears to me to be the disadvantage of requiring the
DNS systems to pull out the key from the cert.

I really don't have a problem with a draft that says 'here is how you
validate a trust chain in which portions of the chain are in DNSSEC
and here is the conclusions that you may draw'. We give that advice to
relying parties all the time.

There is going to be a list of caveats on these trust chains that is
going to be impressively long no matter what.

> I think that the additional bits needed for fully featured operation of
> domain-to-key mapping (eg: "require SSL") can be easily built into the spec,
> whereas bits that assert other things can still ride in the cert itself and
> be validated by whoever signs the cert (if anyone).

Logically speaking, you need to know about 'require SSL' before you
start processing the certificate that was presented in the SSL
transaction.

>>> I'm having trouble figuring out who the cretins vs the people with brains
>>> are in your scenario, but fortunately it doesn't matter if we design a
>>> system in which people can assert only what they are trusted to assert.
>>>
>>> If your concern is...
>>>>
>>> 2. if you wish to enforce this in the absence of a CA-trusted cert, we
>>> can include an option in the RR standard for requiring SSL (which is an
>>> assertion that the zone controller can be trusted to make)
>
>
>
>

---

From: Stephen Schultze <[email-masked]>
Date: Mon, 23 Aug 2010 14:48:19 -0400

> That way the TLS module does not even need to know it is using DNSSEC

If it does not know it is using DNSSEC key assurance, then it can't  
validate _anything_ without getting a third party involved.

> Whatever you think about the desirability of authenticating the first.

Desirable, but not able to be authenticated via DNSSEC key assurance.

> You will break SSL if you do not authenticate the second set of

Any assertions concerning the permitted uses of the key that the  
controller of a zone should be authorized to make could be represented  
in the RR.  Any uses that they are not authorized to make should not  
be respected unless there is some third-party validation.  Unless you  
can give a more concrete example of how you think this breaks SSL I'm  
not sure how to answer.

> be authenticated and assured.

To the extent that there are constraints or other features that  
currently appear in X.509 or other cert standards that can be  
authoritatively asserted by the person who controls a zone, those  
should be made part of the RR.  At that point it's not a "raw key."   
You're right, though, that to date that a DNSSEC-secured domain-based  
approach has not been a mode of operation for SSL.

In any case, the SSL handshake stays the same, and it can be an X.509- 
based handshake or OpenPGP-via-TLS or whatever other standard might  
exist.  The only difference is that the domain-to-key mapping portion  
of validation on the client, but this is work that has to be done  
regardless of whether you hash the whole cert or just the key.

> built is the most common way of breaking them.

And I think that giving controllers of zones the ability to assert  
things that only CAs used to be able to assert would be a changed  
security assumption.

---

From: Stephen Schultze <[email-masked]>
Date: Mon, 23 Aug 2010 14:51:34 -0400

> 2) find some other way to define the other bits we need to sign.

More or less, yes, I think so.  However I'd describe it as:

1) Only include elements that controllers of a zone should be able to  
assert in the RR (key text, some usage requirements)
2) Put everything else in a cert signed by a third-party that has  
authority to assert that stuff

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Mon, 23 Aug 2010 12:54:38 -0600

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Schultze
> 
> Certification of which bits?  All of the bits in the cert, or only those that
> you've decided are allowed?
> 
> Correct me if I'm wrong.  You want the ability for whoever controls a zone to
> hash certs and place them in DNS (essentially signing them) so that they can
> make any manner of assertions.  This turns them into their own little CA for
> their own domain.  

I think it would help me if we could put together a list of types of certificates and assertions that currently aren't conveyed via DNS but that we are proposing can be conveyed that way.  And, which of those that aren't currently conveyed via DNS implicitly rely somehow on DNS in their lifecycle.  

As Warren has pointed out quite well in previous emails and Dan Kaminsky has pointed out elsewhere, we're relying on DNS security and whoever controls a zone for a huge portion of the trust already, even if we don't realize it.  In those cases we're already trusting whoever administers DNS, we just haven't listed them in our trust model.

In those cases since we already have to extend trust to them, we might as well make it explicit and put all of that data into DNS. It solves more problems than it causes.

Should code-signing keys be in DNS, maybe not.  But it depends on how they are currently issued I suppose. If the current trust chain goes through DNS, then we either remove that dependency or explicitly embrace it.

I would like to see an enumeration of the keys/certs we're discussing, use-cases, etc. Phillip laid out several criteria here: http://www.ietf.org/mail-archive/web/keyassure/current/msg00177.html but I think we can flesh this out a little with explicitly listing what types of certs we will consider and which ones we won't.

- Andy

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 23 Aug 2010 11:58:03 -0700

On Aug 23, 2010, at 11:51 AM, Stephen Schultze wrote:

> 1) Only include elements that controllers of a zone should be able to assert in the RR (key text, some usage requirements)
> 2) Put everything else in a cert signed by a third-party that has authority to assert that stuff

This is significantly inferior:

a)  It requires that domain authorities now understand the semantics of the certificates rather than just treating them as opaque binary blobs.

b)  It requires that all validators understand the semantics of the certificates rather than just treating them as opaque binary blobs.

c)  It prevents the framework from ever accommodating other types of certificates.

B is especially bad:  Although I argue that DNSSEC validation on the not-end-host caches is a bad idea, people want to do it.  A new record type MUST NOT require a new validation algorithm that only covers portions of the data, rather it MUST use the existing defined mechanism of 'an unknown record is simply opaque data'.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 23 Aug 2010 15:00:28 -0400

> treating CERT in the same manner as TXT has been (ab)used.

Definitely agree with not using CERT for that sort of policy  
information, but I would go further to say that policy isn't the  
domain of this group.  The definition of "SSL required" will vary  
quite a bit between applications, so policy work is more appropriately  
done in more application-specific groups, such as the proposed HASMAT  
group for HTTP:
<http://tools.ietf.org/html/draft-hodges-strict-transport-sec>

--Richard

>> additional
>>>> 1. these bits can continue to be used, and will be trusted if the  
>>>> CA is
>>>> trusted

---

From: Stephen Schultze <[email-masked]>
Date: Mon, 23 Aug 2010 15:06:13 -0400

explicit:
- hash algorithm
- "use SSL"
- other handshake-related variables like secure renegotiation

implied:
- domain constraints within the zone in question
- expiration (TTL)
- pathLenConstraint=0 (I think this makes sense in order to limit  
DNSSEC key assurance to leaf nodes only)

On Aug 23, 2010, at 2:54 PM, Steingruebl, Andy wrote:
>> From: [email-masked] [mailto:keyassure- 
>> [email-masked]] On Behalf Of Stephen Schultze
>>
> I think it would help me if we could put together a list of types of  
> certificates and assertions that currently aren't conveyed via DNS  
> but that we are proposing can be conveyed that way.  And, which of  
> those that aren't currently conveyed via DNS implicitly rely somehow  
> on DNS in their lifecycle.
>
> As Warren has pointed out quite well in previous emails and Dan  
> Kaminsky has pointed out elsewhere, we're relying on DNS security  
> and whoever controls a zone for a huge portion of the trust already,  
> even if we don't realize it.  In those cases we're already trusting  
> whoever administers DNS, we just haven't listed them in our trust  
> model.
>
> In those cases since we already have to extend trust to them, we  
> might as well make it explicit and put all of that data into DNS. It  
> solves more problems than it causes.
>
> Should code-signing keys be in DNS, maybe not.  But it depends on  
> how they are currently issued I suppose. If the current trust chain  
> goes through DNS, then we either remove that dependency or  
> explicitly embrace it.
>
> I would like to see an enumeration of the keys/certs we're  
> discussing, use-cases, etc. Phillip laid out several criteria here: http://www.ietf.org/mail-archive/web/keyassure/current/msg00177.html 
>  but I think we can flesh this out a little with explicitly listing  
> what types of certs we will consider and which ones we won't.
>
> - Andy

---

From: Stephen Schultze <[email-masked]>
Date: Mon, 23 Aug 2010 15:15:51 -0400

On Aug 23, 2010, at 2:42 PM, Phillip Hallam-Baker wrote:
>> Combining your approach with an

Can you explain?  I'm not grokking.

> start processing the certificate that was presented in the SSL

Is the same not true for knowing whether the cert (or key) you were  
presented with hashes to what's in DNS?  If so, the blocking is the  
same.  You have to wait until you get the RR.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 23 Aug 2010 15:18:15 -0400 (EDT)

On Mon, 23 Aug 2010, Stephen Schultze wrote:

> To the extent that there are constraints or other features that currently 
> appear in X.509 or other cert standards that can be authoritatively asserted 
> by the person who controls a zone, those should be made part of the RR.

Data authorisation duplication is an extremely bad idea. Multiple authorities
could give different answers and then what do you end up doing? Again, it
makes no sense to reproduce X.509 in DNS and then use out-of-bounds CA
validation requirements.

> And I think that giving controllers of zones the ability to assert things 
> that only CAs used to be able to assert would be a changed security 
> assumption.

That's right. We no longer trust CA's. That's a feature, not a bug.

Anyone who wants to use CA's, can stick to what's deployed today. Any new trust
or usage or authorization constraints can be resolved within the X.509 attribute
space.

I feel like I'm time travelling into the past.

Paul

---

From: Stephen Schultze <[email-masked]>
Date: Mon, 23 Aug 2010 15:21:53 -0400

On Aug 23, 2010, at 2:58 PM, Nicholas Weaver wrote:
>> 1) Only include elements that controllers of a zone should be able  
>> to assert in the RR (key text, some usage requirements)
> a)  It requires that domain authorities now understand the semantics  
> of the certificates rather than just treating them as opaque binary  
> blobs.

By "domain authorities" you mean the administrator of the zone data?   
If so, then yes you are right.

> b)  It requires that all validators understand the semantics of the  
> certificates rather than just treating them as opaque binary blobs.

Certainly not all DNSSEC validators (that's what you seem to be  
implying below).  Only the TLS module needs to be changed to first  
pull out the key.  The rest of the DNSSEC chain works as normal.

> c)  It prevents the framework from ever accommodating other types of  

I don't think this is the case.  The framework supports any kind of  
certificate that uses public keys, and application developers are free  
to develop such certs/protocols (eg. OpenPGP over TLS) without forcing  
anyone that wants to use it to put new certs into DNS.

> B is especially bad:  Although I argue that DNSSEC validation on the  
> not-end-host caches is a bad idea, people want to do it.  A new  
> record type MUST NOT require a new validation algorithm that only  
> covers portions of the data, rather it MUST use the existing defined  
> mechanism of 'an unknown record is simply opaque data'.

---

From: Stephen Schultze <[email-masked]>
Date: Mon, 23 Aug 2010 15:34:37 -0400

On Aug 23, 2010, at 3:18 PM, Paul Wouters wrote:
>> should be made part of the RR.
>

This is going to be an issue regardless of the decision on this  
issue.  What do you do if you have an expired or revoked certificate/ 
key that nevertheless has a valid hash in DNS?

The real problem is that if you do not explicitly separate the DNS  
answer and the certificate answer, especially if the cert is signed by  
a third party, it is not clear who is asserting the answer.  Sure, you  
could pick out which X.509 fields are considered asserted by a DNS  
answer if the hash is present (and perhaps this is what people will  
want to do) but that is no better than explicitly separating them with  
respect to your critique.

> That's right. We no longer trust CA's. That's a feature, not a bug.

Agreed, but it is a bug if somehow we end up allowing controllers of  
zones to make and have validated assertions for things that they  
shouldn't be trusted for, or if we create ambiguity about who is  
asserting what.  As such, if we end up cherry-picking fields from X. 
509 we need to specify clearly what it means in this regard.

In any case, my point was obviously that in either scenario we are  
presuming a changed security assumption, which was Phillip's objection.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 23 Aug 2010 15:39:58 -0400

On Mon, Aug 23, 2010 at 3:00 PM, Richard L. Barnes <[email-masked]> wrote:
> Definitely agree with not using CERT for that sort of policy information,
> but I would go further to say that policy isn't the domain of this group.
>  The definition of "SSL required" will vary quite a bit between
> applications, so policy work is more appropriately done in more
> application-specific groups, such as the proposed HASMAT group for HTTP:

Group? What Group?

You seem to be assuming that the outcome of this process is a group
that works out how to use DNSSEC to secure abstract applications. If
that type of work is practical, I would say it should be done in
DNSEXT.

I think the rather more likely outcome of this group is a WG that has
a scope limited to one specific application but is told to go and do
it in a general way. For example, work out how to make HTTP over SSL
work in this framework.

Unless we make some very precise statements about applications, I
can't see us getting the application writers involved. And without the
involvement of people who write code people use a WG means nothing.

---

From: "Carl Wallace" <[email-masked]>
Date: Mon, 23 Aug 2010 15:43:57 -0400

> That's right. We no longer trust CA's. That's a feature, not a bug.

If the intent is to use the key association match exclusively, state
that in the I-D along with security considerations verbiage describing
what is gained/lost relative to the status quo.  The current draft calls
for conventional PKIX validation (nebulous processing rules aside).

> or usage or authorization constraints can be resolved within the X.509

This need not be either/or.

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 23 Aug 2010 12:45:11 -0700

On Aug 23, 2010, at 12:21 PM, Stephen Schultze wrote:

> By "domain authorities" you mean the administrator of the zone data?  If so, then yes you are right.
> 
> Certainly not all DNSSEC validators (that's what you seem to be implying below).  Only the TLS module needs to be changed to first pull out the key.  The rest of the DNSSEC chain works as normal.

Except the model existing for DNSSEC is that an ARBITRARY RR can be validated by any DNSSEC cache or intermediatry.  By only validating a portion of the data, you break this model for no benefit: such an RR would be very different from every other resource record in terms of validation by intermediaries:  DNS has the property that any unknown record type should be treatable as an opaque blob of bits, including for the purpose of validation.

> I don't think this is the case.  The framework supports any kind of certificate that uses public keys, and application developers are free to develop such certs/protocols (eg. OpenPGP over TLS) without forcing anyone that wants to use it to put new certs into DNS.

I'd be really worried about "validating only part" actually being done right.  That really scares me as well.

---

From: Stephen Schultze <[email-masked]>
Date: Mon, 23 Aug 2010 15:48:45 -0400

On Aug 23, 2010, at 3:00 PM, Richard L. Barnes wrote:
> quite a bit between applications, so policy work is more  
> appropriately done in more application-specific groups, such as the  
> proposed HASMAT group for HTTP:

Looking to HSTS is a good idea, and it makes sense to look at actual  
implementations too (including to understand its limitations), eg:
http://dev.chromium.org/sts

That approach would also argue for keeping any of these assertions out  
of the same X.509 certs that carry other third-party assertions.

---

From: Stephen Schultze <[email-masked]>
Date: Mon, 23 Aug 2010 15:54:49 -0400

On Aug 23, 2010, at 3:45 PM, Nicholas Weaver wrote:
>>> b)  It requires that all validators understand the semantics of  
>>> the certificates rather than just treating them as opaque binary  
>>> blobs.
>>
> Except the model existing for DNSSEC is that an ARBITRARY RR can be  
> validated by any DNSSEC cache or intermediatry.  By only validating  
> a portion of the data, you break this model for no benefit: such an  
> RR would be very different from every other resource record in terms  
> of validation by intermediaries:  DNS has the property that any  
> unknown record type should be treatable as an opaque blob of bits,  
> including for the purpose of validation.

One of us is radically misunderstanding the other.  It could be my  
fault.

The idea is that the DNSSEC validates the RR, just the same as any  
other.  This gives you a trusted key.

Then, in the course of TLS setup (for example), the client takes the  
key that it got from the RR and compares that with the key it's  
getting from the server (embedded in a cert or otherwise).  This is  
happening in client libs, which might indeed need to be updated.

None of this implicates changes to DNSSEC operations.

What am I missing?

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 23 Aug 2010 13:01:15 -0700

On Aug 23, 2010, at 12:54 PM, Stephen Schultze wrote:

> One of us is radically misunderstanding the other.  It could be my fault.
> 
> The idea is that the DNSSEC validates the RR, just the same as any other.  This gives you a trusted key.
> 
> Then, in the course of TLS setup (for example), the client takes the key that it got from the RR and compares that with the key it's getting from the server (embedded in a cert or otherwise).  This is happening in client libs, which might indeed need to be updated.
> 

I guess I got confused by the discussion that DNSSEC only validates parts of the certificate.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 23 Aug 2010 16:18:12 -0400 (EDT)

On Mon, 23 Aug 2010, Stephen Schultze wrote:

> This is going to be an issue regardless of the decision on this issue.  What 
> do you do if you have an expired or revoked certificate/key that nevertheless 
> has a valid hash in DNS?

Only when using X.509 containers. i've been advocating against those.

> Agreed, but it is a bug if somehow we end up allowing controllers of zones to 
> make and have validated assertions for things that they shouldn't be trusted 
> for, or if we create ambiguity about who is asserting what.  As such, if we 
> end up cherry-picking fields from X.509 we need to specify clearly what it 
> means in this regard.

Again, no cherry picking. key hashes in the DNS with flags/options fields. Validity
is determined by the presense in the zone with a valid DNSSEC signature.

> In any case, my point was obviously that in either scenario we are presuming 
> a changed security assumption, which was Phillip's objection.

Yes, we are talking about a changed security assumption, regardless of what this
group decides. We can avoid stepping on the PKIX toes - by not using PKIX.

I guess we really need to step back and decide the problem we're solving. People
are definitely solving totally different problems right now.

Paul

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 23 Aug 2010 16:34:11 -0400

>> issue.  What do you do if you have an expired or revoked  
>> certificate/key that nevertheless has a valid hash in DNS?
>

This question seems irrelevant to what sort of container you use.  If  
you have a key or fingerprint that's still in the zone, but the cert  
that's presented at the application layer is expired or revoked, is it  
still considered valid?

There's a little bit of an operational concern here in that you can  
keep the same key pair while changing the cert, but it doesn't seem  
like a huge deal to add "update CERT in DNS" to the TODO list when  
you're rolling over your cert.

>> Agreed, but it is a bug if somehow we end up allowing controllers  
>> of zones to make and have validated assertions for things that they  

As above, the question of validity is independent of the question of  
which container is used.  Expired or revoked certificates can still be  
used as trust anchors, so even if the cert in the DNS is expired/ 
revoked, it can still be considered "good" if it's DNSSEC-validated.

> are definitely solving totally different problems right now.

Agree on all points here.  What we're proposing is an adjunct,  
parallel validation path to PKIX.

As to deciding what problem we're solving, I've tried to express my  
idea of the problem in a charter proposal:
<http://www.ietf.org/mail-archive/web/keyassure/current/msg00090.html>

--Richard

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 23 Aug 2010 16:45:41 -0400

> Can you explain?  I'm not grokking.

At present, pretty much every SSL library consists of code to replace
open(x) with openssl(x,  callback, param)

The callback code throws the calling application a bundle of certs and
a context pointer passed in at the top. The callback has to then
decide whether it likes the taste of the cert or not and respond
accordingly.

As the term Secure Socket Library implies, this is totally wired into
the architecture of the protocol, it is what the patent was granted
for (cue ironic laughter).

So if you want to isolate the callback code from messing with ASN.1,
you want to allow them to treat the cert as simply a raw binary blob
to munch on with a digest function. The SSL library code they are
using already has the code necessary for extracting the key.

> presented with hashes to what's in DNS?  If so, the blocking is the same.
>  You have to wait until you get the RR.

In the full version of my preferred architecture, the client does the
following when it wants to create a connection for (domain, service).
e.g. ("example.com", "_http._tcp")

1) Pull the ESRV record for the service

_http._tcp.example.com ESRV "tls=optional discovery=srv"
 <SIG for above>

2) Client supports the SRV discovery option so we pull that record as well:

_https._tcp.example.com SRV  1 1 443 host1.example.com
_https._tcp.example.com SRV  1 1 443 host2.example.com
 <SIG for above>

3) Try host2:

host2.example.com A 10.1.1.1
 <SIG for above>

4) Open the SSL tunnel to 10.1.1.1 port 443

5)  Server presents certificate

Parse the certificate and find a DNS-CERT extension with prefix _36fe829C

6) Pull the DNS record to verify the certificate:

_36fe829C.host2.example.com CERT 1 9 2i3uh298yq2f23fhq2398y==
_36fe829C.host2.example.com CERT 1 8 http://ca.example.com/36fe829C
 <SIG for above>

Note that at every stage we have a completely defined search set. We
have no hunting around for the next link in the chain.

The SRV step is optional of course. And for some protocols we might
want to use NAPTR or some other SRV variant.

Yes, this approach is not all within scope of what others on this list
are looking to build. But in my approach to protocol design I look at
the total functionality I want and then go about looking to see how I
divide it up into technology platforms. I do not start with a
technology platform and try to enumerate the maximum possible number
of nails to bash with it.

HTTP should have had SRV and SSL designed in from the start.

I don't think you want to include ESRV functionality in the CERT
record because it has to be tuned to the specific protocol.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 23 Aug 2010 17:12:48 -0400

> group decides. We can avoid stepping on the PKIX toes - by not using PKIX.

No, you tread on our toes by ignoring our work and repeating our mistakes.

> are definitely solving totally different problems right now.

Since my reading of 5395 is that the criteria for issuing a new code
point to CERT are essentially the same as the criteria for issuing a
new code point for a resource record, it seems to me that we will
either have a CERT hash function for complete certs or we will have
one for complete certs and a second one for keys in certs.

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Mon, 23 Aug 2010 20:58:17 -0700

> _36fe829C.host2.example.com CERT 1 8 http://ca.example.com/36fe829C

Since we know that the site uses DNSSEC, just don't bother checking for DNS-CERT extension and instead lookup HASH-USED-FOR-SIGNING(DER-CERT).host.example.com CERT RR.

Love

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 24 Aug 2010 00:23:49 -0400

How do we know that the zone contains keys or certs at all?

That would seem rather an odd assumption when no SSL certs are
anchored in DNS at the moment.

Knowing that the site has DNSSEC does not tell apps to look there for keys.

On Mon, Aug 23, 2010 at 11:58 PM, Love Hörnquist Åstrand <[email-masked]> wrote:
> Since we know that the site uses DNSSEC, just don't bother checking for
> DNS-CERT extension and instead lookup
> HASH-USED-FOR-SIGNING(DER-CERT).host.example.com CERT RR.
> Love
>
>

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Mon, 23 Aug 2010 21:33:11 -0700

It said so in your newly proposed ESRV RR.

Love

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 24 Aug 2010 01:10:21 -0400

Hmm, I didn't put that in the ESRV I presented.

It is certainly a possible design choice, the ESRV could have a flag
to say 'DNSSEC validation', but that would tie the key discovery to my
ESRV mechanism. Which seems like tying something relatively
straightforward to something that I think has to be tailored to
specific protocols...

I did propose a version last week where I put the certhash in the ESRV
record. But that was when I was trying to make everything work with a
single record and calling it something else...

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Mon, 23 Aug 2010 22:26:20 -0700

> Hmm, I didn't put that in the ESRV I presented.

I'm putting it there.

> straightforward to something that I think has to be tailored to

I don't think it tailor more then "use_tls" (or what you now called it in ESRV).

Putting it the digest in DNS make the chain clearer in in the case of self-signed certificates.

Love

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 24 Aug 2010 11:41:38 -0400

If at all possible I would like to keep the policy record and the key
record separate for the purposes of discussion. Not everyone is going
to agree on the value of policy as it is a new capability. It is much
easier to get people to agree on re-solving an already solved problem
than a new one. Even though there is considerably less advantage to
doing so.

I agree that you can put the key hash in the policy record. But as I
show later in this post, that creates management issues at renewal
time because DNS records are cached.

How about this for a cert discovery mechanism?

Use of DNSSEC key assurance may be signaled using:

* An ESRV record
* An X.509v3 extension DNS-CERT
* A TLS extension

All three are possible design approaches. I prefer the first two as
they only affect parts of the system that we know we have to affect
anyway for the system to work (DNS, cert generation). TLS extensions
mean we have to upgrade the Web server before the system is useful.

Different CERT records may be distinguished according to a prefix specified by:

* The prefix parameter of the X.509v3 extension DNS-CERT
* A fingerprint of the certificate generated using the hash algorithm
specified in the cert

In addition we need to have a mechanism for specifying that the use of
a cert is authorized with a particular protocol. At the moment there
is a port based proposal on the table and my proposal to use SRV
prefixes.

I much prefer the SRV prefix approach as I don't consider the port
assignments to be a scalable approach. We are going to have far more
than 65,535 protocols used on the Internet. And we already have
protocols that use multiple port numbers (X.11, FTP, VOIP) and HTTP is
designed to run on any port.

In the very simplest case, one host, one service, one cert we could in
theory express all the required information in a single record:

_imap._tcp.example.com ESRV "SSL=REQUIRED
CERT=SHA256:fc5aeb5e43858858d6f636eb6cf56b5fe760cf23b203dc5851a3ed19¬
f0d2ce9d"

However, consider the logistical problems that occur when you need to
roll over the cert. The ESRV record will cache and so there is no
guarantee that a relying party is going to have the right record to
validate the cert presented.

Assuming that the cert has no 'DNS CERT" extension, the RR is going to
be something like:

_imap._tcp.example.com ESRV "SSL=REQUIRED ASSURANCE=DNS"

_fc5aeb5e43858858d6f636eb6cf56b5fe760cf23b203dc5851a3ed19¬
f0d2ce9d._imap._tcp.example.com CERT 9 15
83929394fc5aeb5e43858858d6f636eb6cf56b5fe760cf23b203dc5851a3ed19¬
f0d2ce9d

If the cert does have the extension the RR would be something like

_imap._tcp.example.com ESRV "SSL=REQUIRED"

_eru32wir3._imap._tcp.example.com CERT 9 15
83929394fc5aeb5e43858858d6f636eb6cf56b5fe760cf23b203dc5851a3ed19¬
f0d2ce9d

It would really not take any great effort to write a little tool that
would generate both the zone file specification and either the
certificate itself or CSR for submission to a CA. So the relative
opacity of these designations should not be a major concern.

---

From: Stephen Schultze <[email-masked]>
Date: Tue, 24 Aug 2010 12:00:49 -0400

I basically agree.

I would rephrase the first option ("An ESRV record") as "an RR" just  
because we haven't settled on exactly how it is represented yet.

It would be nice if that RR supported:
- DNS wildcards (does ESRV?)
- the ability to query for it before receiving and parsing the cert,  
ie simultaneously with the initial A record query you are probably  
already making

If we use a prefix, why have two standards for the prefix?  Why not  
just always do it with the fingerprint of the cert/key?  Other than  
the X.509v3 extension DNS-CERT version being prettier for a human to  
read, I'm not sure what the benefit is.

For rollover, the logical solution seems to be to allow multiple certs/ 
RR's.  This addresses other situations in which there are good reasons  
to have more than one cert per service.

On Aug 24, 2010, at 11:41 AM, Phillip Hallam-Baker wrote:
>>>>> On Mon, Aug 23, 2010 at 11:58 PM, Love Hörnquist Åstrand <[email-masked] 
>>>>> > wrote:
>>>>>>

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Tue, 24 Aug 2010 09:51:15 -0700

I wasn't proposing putting the hash in the "ESRV" RR, just a signal that the <HASH>.original-entry <ANY_RR> exists (prefix entry).

Using the prefix entry is good since it support multiple certs for one hostname (load balancing) and migration to new certificates. All this while not requiring users to pull down all RR of you would store the cert-hashes in the data part of the RR.

I prefer just using the "ESRV" + prefix entry instead of "ESRV" + prefix entry + CA putting stuff in my cert for the simple reason its on less component to change.

The only advantage for CA putting stuff in my cert is that you can skip the ESRV step for the reason additional cert validation, you still might want it for TLS=REQUIRED part.

Love

---

From: Stephen Schultze <[email-masked]>
Date: Tue, 24 Aug 2010 13:00:37 -0400

On Aug 24, 2010, at 12:51 PM, Love Hörnquist Åstrand wrote:
> I prefer just using the "ESRV" + prefix entry instead of "ESRV" +  
> prefix entry + CA putting stuff in my cert for the simple reason its  
> on less component to change.
>
> The only advantage for CA putting stuff in my cert is that you can  
> skip the ESRV step for the reason additional cert validation, you  
> still might want it for TLS=REQUIRED part.

As I understand the proposal, CA putting stuff in the cert is  
optional.  That is how I think it should be.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 24 Aug 2010 13:38:05 -0400

OK, so it sounds as if we have rough agreement on the idea of using
one record for policy and another (probably CERT) for keys and try not
to mix the two.

I was thinking that the CA flag is optional.

If we are talking about self-signed certs, adding an extension is
trivial and allows the use of DNSSEC assured certs without the use of
a policy record (ESRV)

I prefer to break down proposals so that one part can proceed
independently of the other.

There are some other considerations we might want to take into account
with the interaction of certs and wildcards. If we want to establish a
service for *.example.com, we need to be able to provide a wildcard
binding for the cert as well.

I had originally thought of using the cert extension to specify the
prefix part and the domain stem. So if I have example.com, I could
create a cert that had the extension:

DNS-CERT _tag1 example.com

So if the cert is presented when trying to create a connection to
www.example.com, the client looks for _tag1._http._tcp.example.com and
not _tag1._http._tcp.www.example.com

This mechanism would only permit upward traversal on the chain so if
the cert is for example.com it could not be used for www.fred.com

This approach may or may not be desirable. The disadvantage is that
the intermediate DNS zone is not necessarily trustworthy (we had this
discussion at length in DKIM) and so there is a risk of having rules
of the form 'only allow within scope of the SOA' which sound great
until you find out how DNS really works.

A better solution might be to simply state that if anyone wants to do
wildcarding with this scheme then they MUST use an ESRV record and the
scheme proposed earlier and use the domain specified in the redirect.

Incidentally, there is also an interaction with SRV that I spent a
couple of weeks looking at a while back. Basically my conclusion was
that if you are using SRV then you want to pull your cert records from
the domain specified in the SRV record, not the host name that you
used for the start of your discovery process.

The reason that is important is that we should be able to support
records of the form:

_pop._tcp.hallambaker.com ESRV "ptr=gmail.com"

or

_pop._tcp.hallambaker.com SRV 1 1 143 pop.google.com

I use google for my mail service. If I have DNSSEC and Google has
DNSSEC, then I should be able to create a pointer in my DNS that means
that my client securely discovers the Google POP service.

And to go one stage further. We could create a new IANA registry for
abstract services which would specify management of a class of
protocol. So rather than put yet another 'identity' protocol on the
table, we might specify an abstract protocol that would group together
Kerberos, SAML, IIM, etc. and a relying party could find out what is
supported in a single record.

In this case it would mean that instead of

_pop._tcp.hallambaker.com ESRV "ptr=gmail.com"
_imap._tcp.hallambaker.com ESRV "ptr=gmail.com"
_submit._tcp.hallambaker.com ESRV "ptr=gmail.com"

The same might be specified as

_mail._as.hallambaker.com ESRV "ptr=gmail.com"

And at gmail we might have:

_mail._as.gmail.com ESRV "protocol=pop,imap,submit ssl=required
auth=secure ssl=required discover=SRV"
_pop._tcp.gmail.com SRV ....
_pop._tcp.gmail.com SRV ....
...

Making this all work smoothly is the key to making Web Services
practical in my view. Which in turn is the reason why I am looking at
this whole problem a bit differently.

On Tue, Aug 24, 2010 at 1:00 PM, Stephen Schultze <[email-masked]> wrote:
>> I prefer just using the "ESRV" + prefix entry instead of "ESRV" + prefix
>> entry + CA putting stuff in my cert for the simple reason its on less
>> component to change.
>>
>> The only advantage for CA putting stuff in my cert is that you can skip
>> the ESRV step for the reason additional cert validation, you still might
>> want it for TLS=REQUIRED part.
>
> As I understand the proposal, CA putting stuff in the cert is optional.
>  That is how I think it should be.
>

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 25 Aug 2010 22:20:43 +0200

Nicholas Weaver <[email-masked]> writes:

> In many ways, I somewhat agree, but for a different reason: CERT RRs
> are just a perfectly fine container class.  We probably don't need new
> RR types.
>
> What we need is ways of using such container classes with DNSSEC: this
> doesn't add any new to-the-wire representatiton, but does require new
> ways (APIs, naming conventions) of using the DNSSEC data, both at a
> low level (APIs) and high level ("cookbook recipies").

+1

I think it is important to shift the focus from how the wire syntax
should look like to how we really want this to be used and what
properties we think are important.  The wire syntax is the simple part.

/Simon

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 25 Aug 2010 16:47:54 -0400

I agree with the principle but would like to change the emphasis:

First we need to decide what information we need to carry in DNS.

AFTER we have done that we can decide if CERT matches those needs.

What I do not want to do is look at the CERT record and work out how
we can apply it to our problem. It is quite likely it does not fit.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 25 Aug 2010 13:56:10 -0700

> we can apply it to our problem. It is quite likely it does not fit.

For carrying data as an authenticated unit ("this BLOB OF BITS is authenticated by DNSSEC"), CERT is just fine: it accomplishes everything thats needed: its extensible, the application's job is to treat it as appropriate, and DNS sees just a binary blob.

Whats needed would be APIs and conventions to allow applications to use that result.

For carrying data only as a partially-authenticated blob ("this BLOB OF BITS is authenticated by DNSSEC, but you should only rely on X, Y, Z components"), yeah, that would probably be best with a new RR, or an ancillary RR to a CERT record.  BUT, and this is a big BUT, shouldn't the application know that it should only rely on X, Y, and Z?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 25 Aug 2010 17:47:20 -0400

> For carrying data only as a partially-authenticated blob ("this BLOB OF BITS is authenticated by DNSSEC, but you should only rely on X, Y, Z components"), yeah, that would probably be best with a n…

I agree! That is not the type of additional information I was considering.

I want to digest the cert, the whole cert and nothing but the cert.

I was considering information of the type 'only use this with specific
protocols'.

Now one way out of this might well be to consider that the exact same
issue already exists in X.509v3 certs and a CA has to consider the
fact when they sign the certificate.

So one approach would be to require the party inserting the cert into
the zone to consider whether all the asserted purposes are acceptable
to them.

I am not trying to be a PITA on this. This is cutting through a lot of
PKIX and TLS work and in addition to the specifications we have to
consider there is also a body of 'lore' - i.e. deployed legacy stuff.

It may actually be safer to use keyassure to assure CA certs that are
then used to authenticate the end entity certs. We know how to do
that.

Then you want to put the whole CA cert in the CERT record.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 25 Aug 2010 14:56:42 -0700

> I was considering information of the type 'only use this with specific

I don't think that really needs a new RR, but perhaps a naming convention?  EG

_ssh.myhost.mydomain.com -> SSH public key
_ssl.myhost.mydomain.com -> x509 certificate for SSL
_auth_smtp.myhost...     -> x509 certificate for authenticated SMTP
_port_2121.myhost        -> the SSH public key for connecting on port 2121

???

You need something like that anyway just to prevent spmaming too big a results chain back?

---

From: Stephen Kent <[email-masked]>
Date: Wed, 25 Aug 2010 19:18:30 -0400

>properties we think are important.  The wire syntax is the simple part.

I agree. It's critical to have a very clear characterization of what functions
one wants to provide via DNS-supplied keys or certs, and why the use 
of DNS to effect this function is better than extant mechanisms. If 
we can't clearly articulate this, then it is not clear that a Wg 
should be created.

Steve

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 26 Aug 2010 11:48:10 -0400

On Wed, Aug 25, 2010 at 07:18:30PM -0400, Stephen Kent wrote:
> one wants to provide via DNS-supplied keys or certs, and why the use of 
> DNS to effect this function is better than extant mechanisms. If we can't 
> clearly articulate this, then it is not clear that a Wg should be 
> created.

I don't see why it has to be "better" than.  Surely "better for some
uses" or "useful alternative in some cases" are enough?

I'm particularly uncomfortable with that "better" because it strikes
me as a way of sneaking in some premises that maybe not everyone will
grant.  For instance, a DNSSEC-based approach is clearly not better
for showing cryptographically some relationship between a given name
and some particular legal entity.  But one can simply set that issue
aside as not relevant for this use, and be agnostic on whether it
makes things "better".

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 26 Aug 2010 23:09:08 -0400

>uses" or "useful alternative in some cases" are enough?

Better for enough use cases to make it worthwhile to add to our 
plethora of standards :-).

>aside as not relevant for this use, and be agnostic on whether it

Relax. If the proposed work is better for some reasonable class of
application contexts, then it makes sense.  The fact that it is not likely
to be a panacea ought not be part of the criteria.

I like the latest charter statement form Warren, with the minor tweaks
several folks have suggested.

Steve