Subject: [keyassure] draft-hoffman-keys-linkage-from-dns-01

From: Paul Hoffman <[email-masked]>
Date: Tue, 24 Aug 2010 15:32:20 -0700

We made some significant updates based on some of the traffic here, the biggest being we now do hash-of-cert instead of hash-of-key and we got rid of ports.

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Using Secure DNS to Associate Certificates with Domain Names For TLS
	Author(s)       : P. Hoffman, et al.
	Filename        : draft-hoffman-keys-linkage-from-dns-01.txt
	Pages           : 8
	Date            : 2010-08-24

TLS and DTLS uses certificates for authenticating the server.  Users
want their applications to verify that the certificate provided by
the TLS server is in fact associated with the domain name they
expect.  Instead of trusting a certificate authority to have made
this association correctly, the user might instead trust the
authoritative DNS server for the domain name to make that
association.  This document describes how to use secure DNS to
associate the TLS server's certificate with the the intended domain
name.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hoffman-keys-linkage-from-dns-01.txt

The summary of changes is:

Appendix B.  Changes between -00 and -01

   Change the association from being a hash of the key of a PKIX
   certificate to being a hash of a certificate (PKIX or other).  This,
   of course, makes large changes throughout the document.

   Expanded the document to cover DTLS as well.

   Added a pointer to the keyassure mailing list.

   Removed the proposals for two alternate formats (the TLSFP Resource
   Record and the TXT record encoding).  Added a bit to Appendix A about
   this.

   Got rid of the specification for ports within a single domain name.

   Made the hash type one octet and used the DS registry instead of
   defining our own.

   Added "Necessarily" chosen in the title of Appendix A to show that we
   might (continue to) change our minds after discussion.

   Added Simon Josefsson to the acknowledgements.

We hope this helps form the discussion here.

--Paul Hoffman, Director
--VPN Consortium

---

From: Vladimir Jirasek <[email-masked]>
Date: Wed, 25 Aug 2010 00:26:25 +0100

Paul,

I have joined the list today, on kind advice from Jeff Hodges. I have read the new proposal and I like it with one comment:

The removal of port numbers means the protocol cannot be used to validate multiple certificates running on one hostname but different ports (i.e. https://www.website.org:443 for the first business application and https://www.website.org:4443 for the second business application). In this case the DNS admin must list all certificates (hashes of them) in multiple DNS RR. It is not specified in the draft what happens if multiple records are returned in the DNS responses, and potentially in random order as DNS servers may use round robin method.

There is not security threat in not having these port numbers there. However, I think it should be specified what the TLS client should do in such circumstances; such as receiving all DNS responses and going through them one by one until a returned hash matches TLS certificate hash.

I hope this helps.

Vladimir Jirasek
mobile: +447538 790302, Fax: +441727375073
Email and Gtalk: [email-masked]
website: www.jirasek.eu
blog: blog.jirasek.eu

On 24 Aug 2010, at 23:32, Paul Hoffman wrote:

> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 24 Aug 2010 17:10:04 -0700

At 12:26 AM +0100 8/25/10, Vladimir Jirasek wrote:

Paul,

I have joined the list today, on kind
advice from Jeff Hodges. I have read the new proposal and I like it
with one comment:

The removal of port numbers means the
protocol cannot be used to validate multiple certificates running on
one hostname but different ports (i.e. https://www.website.org:443 for
the first business application and https://www.website.org:4443
for the second business application).

Yes, it can. The DNS request can get back multiple CERT RRs.

In this case the DNS admin must list all
certificates (hashes of them) in multiple DNS RR.

Exactly right.

It is not specified in the draft
what happens if multiple records are returned in the DNS responses,
and potentially in random order as DNS servers may use round robin
method.

A summary of the paragraphs in Section 3 is:

1 - Use DNSSEC, otherwise don't bother

2 - If you get zero TLSFP CERT RRs, do normal TLS
processing

3 - If you get one or more TLSFP CERT RRs that have hash
functions that you do not understand, ignore those RRs

4 - Try each TLSFP CERT RRs (the order doesn't matter); if none
match the hash of the cert, die with "access_denied"

I see now that we never actually said "Try each usable TLSFP
CERT RR against the hash of the end-entity cert from the server. If
you find a match, stop with success; if you don't, die with
"access_denied". We can add that to the -02.

There is not security threat in not
having these port numbers there. However, I think it should be
specified what the TLS client should do in such circumstances; such as
receiving all DNS responses and going through them one by one until a
returned hash matches TLS certificate hash.

Yep, we should have had that. Thanks for noticing this (somewhat
glaring) error!

--Paul Hoffman, Director

--VPN Consortium

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 24 Aug 2010 21:23:56 -0400

Couple of comments:

1. It's not clear to me from your document what name I should query  
for the CERT RRs.  If I'm trying to authenticate www.example.com, do I  
look under www.example.com, or something else?  If it's the former,  
that could be helpful for generalizing to the SRV case, and would help  
with the concern about multiple services (to some extent).

2. With respect to Vladimir's concern about multiple services under  
the same name, the risk with the approach in the document is that one  
service on a host can masquerade as another, since the client doesn't  
know which CERT goes with which service.  So if you have different  
services at different security levels, you're kind of screwed.  You  
can kind of work around the problem by assigning different host names  
for the two services (pointing to the same host):
https://www1.website.org:443
https://www2.website.org:4443

On the one hand, I'm tempted to say it's not a big deal; it's all in  
the same host, so just manage your host properly. (If there are  
multiple hosts behind the name, )  On the other hand, if you weren't  
concerned about service separation, why did you give them different  
certs in the first place.  On balance, though, I think the above work- 
around is probably good enough.

3. I realize that it's slightly more efficient for the DNS to transmit  
fingerprints, but I still prefer to have the whole cert there because  
it allows for a really trivial implementation:
<http://www.ietf.org/mail-archive/web/keyassure/current/msg00209.html>

On Aug 24, 2010, at 6:32 PM, Paul Hoffman wrote:

> We made some significant updates based on some of the traffic here,  
> the biggest being we now do hash-of-cert instead of hash-of-key and  
> we got rid of ports.
>

---

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

On Tue, Aug 24, 2010 at 9:23 PM, Richard L. Barnes <[email-masked]> wrote:
> Couple of comments:
>
> 1. It's not clear to me from your document what name I should query for the
> CERT RRs.  If I'm trying to authenticate www.example.com, do I look under
> www.example.com, or something else?  If it's the former, that could be
> helpful for generalizing to the SRV case, and would help with the concern
> about multiple services (to some extent).

I don't think it works as written.

The SSL connection is going to present a certificate. If the objective
here is to work
with TLS then write a spec that allows the certificate presented in TLS to be
validated.

> 2. With respect to Vladimir's concern about multiple services under the same
> name, the risk with the approach in the document is that one service on a
> host can masquerade as another, since the client doesn't know which CERT
> goes with which service.  So if you have different services at different
> security levels, you're kind of screwed.  You can kind of work around the
> problem by assigning different host names for the two services (pointing to
> the same host):
> On the one hand, I'm tempted to say it's not a big deal; it's all in the
> same host, so just manage your host properly. (If there are multiple hosts
> behind the name, )  On the other hand, if you weren't concerned about
> service separation, why did you give them different certs in the first
> place.  On balance, though, I think the above work-around is probably good
> enough.

It looks to me like this is punting on the real problem in the design.

You have the cert in hand when you want to get the assurance. So it is not
impossible to do this right.

> fingerprints, but I still prefer to have the whole cert there because it
> allows for a really trivial implementation:

It does not help for SSL.

But the point of using the CERT record is precisely to allow this flexibility.

Incidentally, if this project is going to be limited in scope to SSL
then it should probably
be discussed by the existing TLS working group.

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

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 25 Aug 2010 08:01:35 +0200

On 25 aug 2010, at 03.23, Richard L. Barnes wrote:

> 1. It's not clear to me from your document what name I should query for the CERT RRs.  If I'm trying to authenticate www.example.com, do I look under www.example.com, or something else?  If it's the former, that could be helpful for generalizing to the SRV case, and would help with the concern about multiple services (to some extent).

For now I think have to assume that you lookup the name that you are trying to connect to, the owner of the A/AAAA record.

In case of SRV; would you look up the name of the SRV record or the destination? I'm not sure. For SMTP, I would look up the certificate of the MX destination, not the MX domain.

> 3. I realize that it's slightly more efficient for the DNS to transmit fingerprints, but I still prefer to have the whole cert there because it allows for a really trivial implementation:

If you want to do whole certs, you can just use CERT PKIX certificate type - it's already defined and ready to implement. However, CERTs tend to be on the larger side - 1k+ - resulting in pretty large response sizes.

	jakob

---

From: Vladimir Jirasek <[email-masked]>
Date: Wed, 25 Aug 2010 07:33:43 +0100

Hello,

I realised that the lack of information about the ports is more important
that previously thought. I envisage this RFC to cover other TLS services
than just HTTPs. These include POPs, SMTPS (including STARTTLS potentially),
IMAPs, FTPs, etc.
If that is the intention, and I think it should be, then we need to couple
two DNS queries to get desired effect. To illustrate I show the example.

Users want to access google IMAP server on imap.google.com over IMAPs:

1. the email client queries _imaps._tcp.imap.google.com SRV record and
receives response that IMAPs service is on port 993 on server
imap.google.com
2. it opens the TLS connection to imap.google.com on port 993 and receives
the certificate(s) and extracts the certificate fingerprint
3. client queries CERT RR: imap.google.com CERT - same query as currently
proposed
the record in the DNS is stored as:

imap.google.com. IN CERT TLSFP 0 0 (
AQGa+FZd8sAeS03ca8xDigDQePgJnQvgMe/kKyf8rzluiQ==:993 ) - note that I
added port number after double colon to indicate that the cert is
located on port 993

4. the response sent back to client is as per record above and the client
extracts the certificate hash and port number and verifies it against the
certificate it already has from step 2.

This simple, in my view, change will allow for any service to be verified. I
also think the existing proposal can be modified easily to modify the
storage of the certificate has with the port number. Please note that it
does not specify the protocol (tcp or udp).

Finally, if this is coupled with SRV records to indicate ports and servers
where _imap._tcp service is running (_imap._tcp.imap.google.com. IN SRV 0 5
993 imap.google.com.) the email client does not even need to be configured
what port the service should be on, something users get wrong occasionally.

Obviously the example above applies to HTTPs as well :)

I hope this makes sense.
-----------------
Vladimir Jirasek
www.jirasek.eu   +447538790302
GoogleTalk: [email-masked]
Read my blog: blog.jirasek.eu

On 25 August 2010 07:01, Jakob Schlyter <[email-masked]> wrote:

> > 1. It's not clear to me from your document what name I should query for
> the CERT RRs.  If I'm trying to authenticate www.example.com, do I look
> under www.example.com, or something else?  If it's the former, that could
> be helpful for generalizing to the SRV case, and would help with the concern
> For now I think have to assume that you lookup the name that you are trying
> to connect to, the owner of the A/AAAA record.
>
> In case of SRV; would you look up the name of the SRV record or the
> destination? I'm not sure. For SMTP, I would look up the certificate of the
> MX destination, not the MX domain.
>
> If you want to do whole certs, you can just use CERT PKIX certificate type
> - it's already defined and ready to implement. However, CERTs tend to be on
> the larger side - 1k+ - resulting in pretty large response sizes.
>
>
>        jakob
>

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 25 Aug 2010 08:53:16 +0200

There are two different issues here;

a) The use of SRV to locate server X for name Y. This is not widely deployed (yet), and I'm not sure it is within the scope of this non-WG to address this lack of support.

b) Support for per protocol certificates for name Y. In our draft we suggest that we limit ourselves to one (equal) set of certificates for a given name.  If this limitation is critical, I suggest we look into SRV naming for the CERT records instead of encoding protocol/port in the record itself. This also has the benefit that existing CERT records can use the same convention.

	jakob

---

From: Vladimir Jirasek <[email-masked]>
Date: Wed, 25 Aug 2010 08:01:59 +0100

Hello,

re point a) you are right, the SRV records are likely outside of the scope
of this WG, I included it as an example of connecting it together. It is not
widely deployed, pretty much as CERT RR records are not deployed. So this is
an opportunity to push it more to wide implementation.

re point b) I think limiting the DNS records to just a given name without
the port is limiting in my view. One given name can be running diferent
services using different certificates.
I do not understand what you mean with using SRV records and ports? yes you
can store port number in SRV records (that is why there are here in the
first place) but I do not see how this alone helps CERT records. Can you
elaborate by example please?

Regards

-----------------
Vladimir Jirasek

On 25 August 2010 07:53, Jakob Schlyter <[email-masked]> wrote:

> a) The use of SRV to locate server X for name Y. This is not widely
> deployed (yet), and I'm not sure it is within the scope of this non-WG to
> address this lack of support.
>
> b) Support for per protocol certificates for name Y. In our draft we
> suggest that we limit ourselves to one (equal) set of certificates for a
> given name.  If this limitation is critical, I suggest we look into SRV
> naming for the CERT records instead of encoding protocol/port in the record
> itself. This also has the benefit that existing CERT records can use the
> same convention.
>
>
>        jakob
>
>

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 25 Aug 2010 09:36:41 +0200

On 25 aug 2010, at 09.01, Vladimir Jirasek wrote:

> I do not understand what you mean with using SRV records and ports? yes you can store port number in SRV records (that is why there are here in the first place) but I do not see how this alone helps CERT records. Can you elaborate by example please?

e.g.,

_http._tcp.example.com. IN CERT TLSFP 0 0 AQGa+FZd8sAeS03ca8xDigDQePgJnQvgMe/kKyf8rzluiQ==

	jakob

---

From: Vladimir Jirasek <[email-masked]>
Date: Wed, 25 Aug 2010 08:38:32 +0100

I see. Should not that be more like:

_*https*._tcp.example.com. IN CERT TLSFP 0 0
AQGa+FZd8sAeS03ca8xDigDQePgJnQvgMe/kKyf8rzluiQ==

I see what you mean and it make sense.

-----------------
Vladimir Jirasek

On 25 August 2010 08:36, Jakob Schlyter <[email-masked]> wrote:

> > I do not understand what you mean with using SRV records and ports? yes
> you can store port number in SRV records (that is why there are here in the
> _http._tcp.example.com. IN CERT TLSFP 0 0
> AQGa+FZd8sAeS03ca8xDigDQePgJnQvgMe/kKyf8rzluiQ==
>
>
>        jakob
>
>

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 25 Aug 2010 09:41:54 +0200

On 25 aug 2010, at 09.38, Vladimir Jirasek wrote:

I also like to note that if we would do SRV records, the existance of a SRV(_https._tcp.example.com) and a non-existance of a SRV(_http.tcp.example.com) is a pretty good indicator that HTTPS is required (aka strict transport security) by the service. 

	jakob

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 25 Aug 2010 09:10:34 -0700

First off, one of the more common criticisms we got on the -00 was the complication of the ports, so this is not clear-cut. Having said that, I believe the *only* situation where specifying the ports in the TSLFP CERT request is valuable is when all the following are true:

a) There are more than five or so servers on different ports on server.example.com

b) Each server uses a different certificate

c) The users always go to the tuple { dns=server.example.com && port=nnn }

If (a) and (b) are true but (c) is not, for example if there are addional names such as www.example.com and imap.example.com for the various servers, there is no problem because the user will look up the individual name.

If (a) and (c) are true but (b) is not, there is no problem because the user will get a useful response regardless of the port they go to.

If (b) and (c) are true but (a) is not, then the client software needs compare the hash of the cert gotten in TLS against a small number of hashes. The only problem here is that the request for the TLSFP CERT RR is somewhat large.

In what real-world use cases is this a problem?

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 25 Aug 2010 09:01:32 -0700

><http://www.ietf.org/mail-archive/web/keyassure/current/msg00209.html>

Depending on the certificate, it is *much* more efficient to transmit fingerprints. I don't think adding a single hash function call to the comparison reduces the triviality by much.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 25 Aug 2010 12:50:10 -0400

Volume I: Certs vs. hash-of-certs

It's actually kind of a big reduction in triviality.  The SSL  
libraries right now are set up so that users provide trust anchors in  
the form of certs instead of fingerprints.  (At least, I'm not aware  
of any that do the latter.)  If you require fingerprint matching in  
the validation, you have to start mucking around with TLS libraries,  
instead of just being able to make use of existing libraries.

The one thing you could do to hack around this is do post-hoc  
checking: Accept the cert to establish the TLS connection, then  
validate it and terminate the connection if the validation fails.  But  
in order to make that secure, you basically have to put the connection  
on hold while you do the validation, which is a little weird.  And  
that in addition to the sort of philosophical point that it seems like  
the TLS negotiation should fail if you're not ultimately going to  
accept it.

Volume II: Certs vs. keys

A related discussion we should be having is whether we want to be  
talking about certs or keys in the DNS. (Whether directly, e.g., as a  
subjectPublicKeyInfo structure, or hashed.)  It seems to me that  
working with keys would be more flexible, since you wouldn't be bound  
to a single cert.  That is, you could present multiple certs without  
having to have multiple RRs, and you could change your cert without  
updating the DNS (e.g., to renew it).

Using keys, though, causes the same implementation issues as above,  
whether they're represented as keys or fingerprints.  So there's a  
trade-off here between implementation complexity and operational  
complexity.

--Richard

On Aug 25, 2010, at 12:01 PM, Paul Hoffman wrote:

>> 3. I realize that it's slightly more efficient for the DNS to  
>> transmit fingerprints, but I still prefer to have the whole cert  
>> there because it allows for a really trivial implementation:
> Depending on the certificate, it is *much* more efficient to  
> transmit fingerprints. I don't think adding a single hash function  
> call to the comparison reduces the triviality by much.
>
> --Paul Hoffman, Director
> --VPN Consortium

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 25 Aug 2010 09:59:19 -0700

On Aug 25, 2010, at 9:50 AM, Richard L. Barnes wrote:
> A related discussion we should be having is whether we want to be talking about certs or keys in the DNS. (Whether directly, e.g., as a subjectPublicKeyInfo structure, or hashed.)  It seems to me that working with keys would be more flexible, since you wouldn't be bound to a single cert.  That is, you could present multiple certs without having to have multiple RRs, and you could change your cert without updating the DNS (e.g., to renew it).

I don't see how this would be the case: you have N keys or N certs means N records for the host.  

And is there really a difference?  A "CERT" is simply the key-format desired by the application: SSL's CERTs are x509, but the "CERT" for SSH is just the bare host key: this seems like a distinction without a difference to me.

---

From: Stephen Schultze <[email-masked]>
Date: Wed, 25 Aug 2010 13:02:15 -0400

On Aug 25, 2010, at 12:59 PM, Nicholas Weaver wrote:
>> talking about certs or keys in the DNS. (Whether directly, e.g., as  
>> a subjectPublicKeyInfo structure, or hashed.)  It seems to me that  
>> working with keys would be more flexible, since you wouldn't be  
>> bound to a single cert.  That is, you could present multiple certs  
>> without having to have multiple RRs, and you could change your cert  
>> without updating the DNS (e.g., to renew it).
>
> And is there really a difference?  A "CERT" is simply the key-format  
> desired by the application: SSL's CERTs are x509, but the "CERT" for  
> SSH is just the bare host key: this seems like a distinction without  
> a difference to me.

Many certs may share the same public/private key pair.

It matters if what people are proposing is hashing one particular key- 
format, especially if that format includes things that are not  
assertable by the person who controls the zone (unless the spec  
explicitly outlines which elements are assertable and which are not).

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 25 Aug 2010 19:03:44 +0200

On 25 aug 2010, at 18.50, Richard L. Barnes wrote:

> It's actually kind of a big reduction in triviality.  The SSL libraries right now are set up so that users provide trust anchors in the form of certs instead of fingerprints.  (At least, I'm not aware of any that do the latter.)  If you require fingerprint matching in the validation, you have to start mucking around with TLS libraries, instead of just being able to make use of existing libraries.

It is not trust anchors that are published in the DNS, it is the very same cert. If we would publish trust anchors, only self-signed certificates could be validated, no?

> The one thing you could do to hack around this is do post-hoc checking: Accept the cert to establish the TLS connection, then validate it and terminate the connection if the validation fails.  But in order to make that secure, you basically have to put the connection on hold while you do the validation, which is a little weird.  And that in addition to the sort of philosophical point that it seems like the TLS negotiation should fail if you're not ultimately going to accept it.

In the latest version of our draft we propose that the key association is performed first, optionally followed by traditional PKIX validation.

> A related discussion we should be having is whether we want to be talking about certs or keys in the DNS. (Whether directly, e.g., as a subjectPublicKeyInfo structure, or hashed.)  It seems to me t…

With keys (or hash of key), any CA could pull that key and sign in (with the key association still valid). With a hash-of-cert, that is not possible (which I think is a feature for people depending on things like EV).

	jakob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 25 Aug 2010 13:10:53 -0400

Well there was various criticism. In particular I don't think you have
appreciated the difference between the use of port numbers to
differentiate between certs in discovery and their use to restrict use
of a cert to a specific service and/or protocol.

Let us take as a use case the need to support google.com ten years
from now when it is supporting 1000 applications. It is not going to
be possible for people to remember the names of all those applications
so the simplest approach will be to have them all use google.com as
the domain name. This approach is certainly implicit in the SRV
approach.

It is clearly not going to be practical for all those services to use
the same cert. It is certainly not desirable to do so. So I consider
any attempt to use the domain alone as the discover mechanism to be
impractical. Even if you could transport 1000 certs in one DNS record,
you would not want to try.

We already have a solution for differentiating discovery in DKIM - key tags.

In the case of SSL you always know the cert before you need to validate it.

So I would differentiate the task of cert discovery and the task of
determining if a cert is acceptable for a specific purpose.

Cert discovery is relatively easy. We just need a means of uniquely
identifying the cert. That can be provided

* [By a hash of the cert itself]
* By a digest function on the cert itself
* By new data provided in the cert
* [By data provided in the TLS transaction]
* (Might be possible to use the cert serial number which should be unique)

I have used square brackets for the ones I consider unacceptable. Why
use a hash rather than a digest? I can't think of a good reason. I
don't want to have to touch the Web server code to enable this, IIS
has a several year development cycle and many people can't upgrade
their Apache without upgrading lots of other stuff thats likely to
break.

Most people seem to think that a digest function on the cert using the
digest function used to sign it works for them.

_b5Y6eWCdCwrrODTG+lJ3iob7Ks3+ybatOSlpWGMU8k0.example.com CERT ....

We can truncate to fit into a 64 octet label without issue.

The second issue is how to restrict the use of the cert to a specific
purpose. Here we have the following possibilities:

* data in the certificate
* data in the label field of the DNS record
* data in the data field of the DNS record
* data in a companion record to CERT
* use a new record rather than reuse CERT
* pretending this is not a security problem
* require use of SRV and a separate host name per certificate

If you want to reuse CERT, the data field is not available and if you
are going to use a companion record then you might as well abandon the
attempt to extend CERT.

Try to pretend it is not a problem and people will rightly scream that it is.

So taking out those we have:

* data in the certificate
* data in the label field of the DNS record
* require use of SRV and a separate host name per certificate
* use a new record rather than reuse CERT

I don't like the first since we are now talking about putting a fairly
complicated statement that can change over the cert validity period
into the cert. I have no problem generating a random identifier and
slamming it in, but I am nervous about anything requiring thought.

The label field might have been practical if we didn't also need the
digest in the tag. If we were to fully secure both the protocol and
the port we would have:

_8000,_http._tcp._b5Y6eWCdCwrrODTG_lJ3iob7Ks3_ybatOSlpWGMU8k0.example.com
CERT ....

We could trim this a little if we can use the serial #:

_8000,_http._tcp._-F8gAyPA_mLT-mb75FGgnQ.example.com CERT ....

If we insist on using SRV we have fundamentally changed HTTP in order
to make the key assurance work. Even though I am proposing to do just
that as an option, doing that right is research and key assurance
should not be research fifteen years after we started doing SSL.

I am quite happy to do research to make a protocol work better, but
building research on research is a Error 33 from Parc. We should not
do research for the sake of saving a DNS resource record.

Reuse of CERT is looking much less attractive to me. I had been
convinced to use it since it really does solve some problems,
particularly in the general case where we are not using SSL. But it
has parameters I do not want and lacks parameters I think we need.

This would give us:

_F8gAyPA_mLT-mb75FGgnQ.example.com APPKEY
       "port=80 protocol=_http._tcp
digest=b5Y6eWCdCwrrODTG+lJ3iob7Ks3+ybatOSlpWGMU8k0="

We could add in specifications to allow a link to a CERT record and/or a uri.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 25 Aug 2010 13:15:19 -0400

I think there's something missing here.  You also run into problems if  
(!a && b && c) and:

d) The client is making decisions based on certificate attributes  
other than domain names

e) One service can access another's private key

If (!a && b && c && d && e), then one service can present another  
service's certificate, influencing client behavior.  You could  
envision problems arising from differences in issuer (EV vs. DV).  In  
some sense, this isn't a huge issue, since a lot of attributes are  
effectively the same for different processes on the same machine, but  
there are still some trouble cases.  For example, there are two  
entities with EV certs on the same server, with the same domain-name,  
one service would be able to present the other's EV cert, and the  
client would not be able to distinguish.  [1]

I'll leave it as an exercise to the reader to determine how practical  
this scenario is.  In all candor, I'm mainly including it for  
completeness; it doesn't seem like a huge risk to me.

--Richard

[1] Digression: THe CA/Browser Forum document describing EV certs says  
that the domain name field in an EV cert "MUST contain one or more  
host domain name(s) owned or controlled by the Subject and to be  
associated with Subject’s server.  Such server MAY be owned and  
operated by the Subject or another entity (e.g., a hosting service)."   
This situation would arise in the latter case, where another entity  
owns and operates the zone in question.

On Aug 25, 2010, at 12:10 PM, Paul Hoffman wrote:

> First off, one of the more common criticisms we got on the -00 was  
> the complication of the ports, so this is not clear-cut. Having said  
> that, I believe the *only* situation where specifying the ports in  
> the TSLFP CERT request is valuable is when all the following are true:
>
> If (a) and (b) are true but (c) is not, for example if there are  
> addional names such as www.example.com and imap.example.com for the  
> various servers, there is no problem because the user will look up  
> the individual name.
>
> If (a) and (c) are true but (b) is not, there is no problem because  
> the user will get a useful response regardless of the port they go to.
>
> If (b) and (c) are true but (a) is not, then the client software  
> needs compare the hash of the cert gotten in TLS against a small  
> number of hashes. The only problem here is that the request for the  
> TLSFP CERT RR is somewhat large.
>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 25 Aug 2010 13:22:13 -0400

Responses inline.

>> libraries right now are set up so that users provide trust anchors  
>> in the form of certs instead of fingerprints.  (At least, I'm not  
>> aware of any that do the latter.)  If you require fingerprint  
>> matching in the validation, you have to start mucking around with  
>> TLS libraries, instead of just being able to make use of existing  
>> libraries.
>
> It is not trust anchors that are published in the DNS, it is the  
> very same cert. If we would publish trust anchors, only self-signed  
> certificates could be validated, no?

There's some misunderstanding of terms here: A trust anchor is any  
point where the client doesn't feel that it needs to continue  
validation.  (In particular, it doesn't have to be self-signed.)  So  
in the context of the domain being validated, the cert presented is a  
trust anchor -- if the server presents it and it matches, there's no  
further validation necesary.

>> validate it and terminate the connection if the validation fails.   
>> But in order to make that secure, you basically have to put the  
>> connection on hold while you do the validation, which is a little  
>> weird.  And that in addition to the sort of philosophical point  
>> that it seems like the TLS negotiation should fail if you're not  
>> ultimately going to accept it.
>
> In the latest version of our draft we propose that the key  
> association is performed first, optionally followed by traditional  
> PKIX validation.

I'll have to go read that :)

> With keys (or hash of key), any CA could pull that key and sign in  
> (with the key association still valid). With a hash-of-cert, that is  
> not possible (which I think is a feature for people depending on  
> things like EV).

I'm not sure what the risk is here.  If a CA takes my public key and  
issues a cert to some attacker, the attacker can't use it to  
masquerade as me, since he doesn't have my private key.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 25 Aug 2010 13:45:50 -0400

The issue of delegation is a difficult one and might well be something
that ESRV or SRV is used to address.

The discovery of the delegation relationship is going to be discovered
during service discovery, i.e. before we start the TCP connection or
SSL tunnel.

If I can sign a DNSSEC zone record to say 'for email service for
hallambaker.com see gmail.com', then the service can and should expect
to see an SSL cert presented for gmail.com as opposed to
hallambaker.com.

One of the issues I am trying to deal with here is the fact that the
existing mechanism for SSL domain name binding does not work as it
should.

In order to claim that there is a system here it is going to be
necessary to provide a pretty exhaustive explanation of how this all
works with Web and with Mail.

On Wed, Aug 25, 2010 at 1:15 PM, Richard L. Barnes <[email-masked]> wrote:
> I think there's something missing here.  You also run into problems if (!a
> && b && c) and:
>
> d) The client is making decisions based on certificate attributes other than
> domain names
>
> If (!a && b && c && d && e), then one service can present another service's
> certificate, influencing client behavior.  You could envision problems
> arising from differences in issuer (EV vs. DV).  In some sense, this isn't a
> huge issue, since a lot of attributes are effectively the same for different
> processes on the same machine, but there are still some trouble cases.  For
> example, there are two entities with EV certs on the same server, with the
> same domain-name, one service would be able to present the other's EV cert,
> and the client would not be able to distinguish.  [1]
>
> I'll leave it as an exercise to the reader to determine how practical this
> scenario is.  In all candor, I'm mainly including it for completeness; it
> doesn't seem like a huge risk to me.
>
> --Richard
>
>
> [1] Digression: THe CA/Browser Forum document describing EV certs says that
> the domain name field in an EV cert "MUST contain one or more host domain
> name(s) owned or controlled by the Subject and to be associated with
> Subject’s server.  Such server MAY be owned and operated by the Subject or
> another entity (e.g., a hosting service)."  This situation would arise in
> the latter case, where another entity owns and operates the zone in
> question.
>
>
>
>> First off, one of the more common criticisms we got on the -00 was the
>> complication of the ports, so this is not clear-cut. Having said that, I
>> believe the *only* situation where specifying the ports in the TSLFP CERT
>> request is valuable is when all the following are true:
>>
>> If (a) and (b) are true but (c) is not, for example if there are addional
>> names such as www.example.com and imap.example.com for the various servers,
>> there is no problem because the user will look up the individual name.
>>
>> If (a) and (c) are true but (b) is not, there is no problem because the
>> user will get a useful response regardless of the port they go to.
>>
>> If (b) and (c) are true but (a) is not, then the client software needs
>> compare the hash of the cert gotten in TLS against a small number of hashes.
>> The only problem here is that the request for the TLSFP CERT RR is somewhat
>> large.
>>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 25 Aug 2010 14:04:14 -0400

Not talking about delegation here -- the starting assumption is that  
all the services are using the same domain name.  For delegation  
considerations, see [1].

The scenario here is where example.com hosts:
EntityA on http://example.com:44300/
EntityB on http://example.com:44301/

If the server is poorly configured (so that you get (e) as below),  
then unless you can distinguish which cert goes with which port,  
EntityA can provide an EV cert for EntityB without the client noticing.

You might arrive at these port-wise services via an SRV or NAPTR  
record, but those should be authenticated themselves, so that the end  
server can authenticate as itself.  In other words, there are two  
separate authentications going on here:
1. Authenticate delegation record
2. Authenticate remote service
The first one is done with DNSSEC or DNA [1]; the second one is what  
we're doing here.

Again, IMO, this case is deep in the corner, but included for  
completeness.

--Richard

[1] <http://tools.ietf.org/html/draft-barnes-xmpp-dna>

On Aug 25, 2010, at 1:45 PM, Phillip Hallam-Baker wrote:

>> other than
>> service's
>>> the
>>> addional
>>> needs

---

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

At 9:59 AM -0700 8/25/10, Nicholas Weaver wrote:
>...

A public key cert is a assertion of a binding between a public key and
a set of attributes, signed by an entity attesting to the accuracy of 
the assertion. This characterization applies to X.509 certs and PGP 
certs. A bare key is not a cert.  Let's not confuse terminology.

Steve

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 25 Aug 2010 16:30:30 -0700

On Aug 25, 2010, at 4:11 PM, Stephen Kent wrote:

> a set of attributes, signed by an entity attesting to the accuracy of the assertion. This characterization applies to X.509 certs and PGP certs. A bare key is not a cert.  Let's not confuse terminology.

For the purposes of storing records in DNS, is there a relevant distinction?  

I'd argue "absolutely not", especially since there is such a thing as "Self signed cert": a self signed certificate is really no different from a bare key except for some garbage around it for formatting.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 25 Aug 2010 19:53:58 -0400

Precedent is already set on that one.

CERT allows storage of raw keys.

On Wed, Aug 25, 2010 at 7:11 PM, Stephen Kent <[email-masked]> wrote:
>> desired by the application: SSL's CERTs are x509, but the "CERT" for SSH is
>> just the bare host key: this seems like a distinction without a difference
>> to me.
>
> a set of attributes, signed by an entity attesting to the accuracy of the
> assertion. This characterization applies to X.509 certs and PGP certs. A
> bare key is not a cert.  Let's not confuse terminology.
>
> Steve

---

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

At 4:30 PM -0700 8/25/10, Nicholas Weaver wrote:
>>>  And is there really a difference?  A "CERT" is simply the 
>>>key-format desired by the application: SSL's CERTs are x509, but 
>>>the "CERT" for SSH is just the bare host key: this seems like a 
>>>distinction without a difference to me.
>>
>>  a set of attributes, signed by an entity attesting to the accuracy 
>>of the assertion. This characterization applies to X.509 certs and 
>>PGP certs. A bare key is not a cert.  Let's not confuse terminology.
>
>I'd argue "absolutely not", especially since there is such a thing 
>as "Self signed cert": a self signed certificate is really no 
>different from a bare key except for some garbage around it for 
>formatting.

I'd suggest that the SEC ADs will frown upon this cavalier use of terminology,
which is inconsistent with RFC 4949 :-).

A self-signed cert allows the signer to bind attributes to a public key, in
a fashion that provides a consistency check, even though it does not 
provide a secure basis for authentication the identity of the 
Issuer/Subject.

Steve

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 26 Aug 2010 08:54:11 -0400

I don't think it is helpful to start bringing in the Security ADs
opinion unless they have stated an opinion. Their concurrence may be a
necessary condition, but certainly not a sufficient one.

You are correct that these are not self signed certificates in the
proposed mode of use. They are actually a CA issued certificate with
signature in the form of a countersignature on the self-signed
certificate prototype.

The zone KSK may be established through a number of different means.

These means are out of scope for this discussion. But one means that
you should probably consider in the context of making BGP security
practical is the case where the DNS zone KSK is signed using an X.509
certificate expressed in a CERT record.

On Wed, Aug 25, 2010 at 7:45 PM, Stephen Kent <[email-masked]> wrote:
>>> the assertion. This characterization applies to X.509 certs and PGP certs. A
>> I'd argue "absolutely not", especially since there is such a thing as
>> "Self signed cert": a self signed certificate is really no different from a
>> bare key except for some garbage around it for formatting.
>
> a fashion that provides a consistency check, even though it does not provide
> a secure basis for authentication the identity of the Issuer/Subject.
>
> Steve
>

---

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

>necessary condition, but certainly not a sufficient one.

Agreed that it is necessary, but not sufficient.

>signature in the form of a countersignature on the self-signed

OK.

>certificate expressed in a CERT record.

I'm not sure how any DNSSEC capabilities relate to the RPKI that BGP 
secruity will rely upon. All 5 RIRs have committed to IOC for the 
RPKI on 1/1/11, based on a number of I-Ds that the SIDR WG is now 
aggressively pushing towards approval.

Steve