Subject: [keyassure] Am I missing something?

From: Chris Wright <[email-masked]>
Date: Wed, 15 Sep 2010 09:57:47 +1000

All,

There is a lot of discussion about 'how' to put 'certificates' in the DNS, but I don't understand why we are considering certificates at all? Why isn't just the public key, or some sort of fingerprint of it sufficient? I thought we were trying to bind Public Keys to domain names? What value does the 'certificate' add?

Is it because we are just trying to use RRs that already exist?

Surely all we need is a mechanism to distinguish which Public Key is bound to which domain name, and for which services.

Eg. If I have a domain name host.example.com and this host has an SSH and a HTTPS service running on it, potentially I need a way to put the public key of both the ssh and https service in the DNS and be able to distinguish between the two.

We would then need to modify both the SSH and HTTPS (or the underlying TLS/SSL etc.) protocols to  actually look these things up in the DNS.

Thanks

Chris Wright
Chief Technology Officer
AusRegistry Pty Ltd

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 14 Sep 2010 20:52:07 -0400

The answer is in the last line of your question: we would have to modify
TLS/SSL.

SSL was designed to use X.509 from the start. It is a large protocol and has
a lot of options. It is widely deployed and there are many varieties of
implementation.

If we attempt to change such a fundamental question as the decision to use
certificates to wrap keys then we have to go through the whole protocol and
make sure we are not breaking an assumption. And then we have to convince
people that we did the job right.

Unlike typical application protocols which people are generally trying to
make work, in the security area you have to deal with people who are trying
to break and sabotage you. And that makes the job a lot harder. Persuading
people to change a protocol after deployment and use is hard.

Besides the subject key, a certificate contains a validity interval and
certificate extensions. The certificate extensions may be used to control
the behavior of TLS.

The other reason for using certs is that DNS and DNSSEC permit certain
features that are not possible in the traditional PKIX model. So even if
there was a way to use DNSSEC on raw keys to establish TLS sessions there
would still be a demand to use DNSSEC on certs to establish TLS sessions.

Producing self-signed certs is easy, there are hundreds of tools floating
about to create them and pretty much every crypto library in use today can
produce a self signed cert with a half page program.

On Tue, Sep 14, 2010 at 7:57 PM, Chris Wright <[email-masked]>wrote:

> All,
>
> There is a lot of discussion about 'how' to put 'certificates' in the DNS,
> but I don't understand why we are considering certificates at all? Why isn't
> just the public key, or some sort of fingerprint of it sufficient? I thought
> we were trying to bind Public Keys to domain names? What value does the
> 'certificate' add?
>
> Surely all we need is a mechanism to distinguish which Public Key is bound
> to which domain name, and for which services.
>
> Eg. If I have a domain name host.example.com and this host has an SSH and
> a HTTPS service running on it, potentially I need a way to put the public
> key of both the ssh and https service in the DNS and be able to distinguish
> between the two.
>
> We would then need to modify both the SSH and HTTPS (or the underlying
> TLS/SSL etc.) protocols to  actually look these things up in the DNS.
>
> Thanks
>
> Chris Wright
> Chief Technology Officer
> AusRegistry Pty Ltd
>
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

---

From: Douglas Otis <[email-masked]>
Date: Tue, 14 Sep 2010 17:57:57 -0700

On 9/14/10 4:57 PM, Chris Wright wrote:
>  All,
>
>  There is a lot of discussion about 'how' to put 'certificates' in the
>  DNS, but I don't understand why we are considering certificates at
>  all? Why isn't just the public key, or some sort of fingerprint of it
>  sufficient? I thought we were trying to bind Public Keys to domain
>  names? What value does the 'certificate' add?

Certs are able to bind a verifiable name with an authority through a 
trusted third-party CA service and can be carried within a channel able 
to leverage confirmation of the CA signature.  Whether the resource 
record or the target of that resource should offer a public key to 
verify the domain being trusted might be an issue.  Conventions should 
allow both domains a means to offer public keys.  DNS offers discovery 
information for the service, and it can offer public keys where name 
verification can be confirmed by private keys held by the service.  This 
should then confirm the identity of  the service without needing a Cert 
or CA when DNSsec can be trusted.

>  Is it because we are just trying to use RRs that already exist?

There is the KEY (25)  RR specified by RFC2535 able to hold public 
keys.  DKIM used TXT RR to hold public keys.  Because the revocation 
schemes related to Certs creates a significant amount of overhead, it 
seems bad Certs can't be removed within a reasonable time frame.  Bad 
actors are able to obtain whatever level of certification they desire.  
A scheme unable to react to criminal behavior within hours, days, and 
weeks seems unusable.  Currently, browsers are using domain reputation 
to support higher reaction rates as a method to keep the web safe.  This 
approach suggests Certs might be over rated once there are conventions 
for securing browsers using public keys within DNS and the general 
availability of a reactive domain reputation service.  (It also seems 
possible to configure resolvers to limit TTLs of KEY RR being cached, 
since thousand of domains are being taken down daily.)

>  Surely all we need is a mechanism to distinguish which Public Key is
>  bound to which domain name, and for which services.

Any name can hold a Key RR.   When there are multiple services where 
each needs a different key, it seems the SRV conventions might offer one 
solution for this issue.

>  Eg. If I have a domain name host.example.com and this host has an SSH
>  and a HTTPS service running on it, potentially I need a way to put
>  the public key of both the ssh and https service in the DNS and be
>  able to distinguish between the two.
>
>  We would then need to modify both the SSH and HTTPS (or the
>  underlying TLS/SSL etc.) protocols to actually look these things up
>  in the DNS.

Exactly,  but there is also issues related to revocation that browsers 
are expecting. :^(

-Doug

---

From: Steve Schultze <[email-masked]>
Date: Tue, 14 Sep 2010 21:15:26 -0400

> There is a lot of discussion about 'how' to put 'certificates' in the DNS, but I don't understand why we are considering certificates at all? Why isn't just the public key, or some sort of fingerpr…

Good question, read this thread:
http://www.ietf.org/mail-archive/web/keyassure/current/threads.html#00240

I think the answer is it's still an open question.

On Sep 14, 2010, at 8:52 PM, Phillip Hallam-Baker wrote:
> The answer is in the last line of your question: we would have to modify TLS/SSL.

That's not true, and I thought that based on the thread I linked to above we decided to postpone the cert-vs-key discussion (although I admit I've been behind on reading the list in the last week).

> SSL was designed to use X.509 from the start. It is a large protocol and has a lot of options. It is widely deployed and there are many varieties of implementation.

Well, SSL (TLS) now supports more than X.509 (eg OpenPGP).  More importantly, the fact that the TLS connection requires a particular wrapper does not mandate what goes into DNS.

> If we attempt to change such a fundamental question as the decision to use certificates to wrap keys then we have to go through the whole protocol and make sure we are not breaking an assumption. And then we have to convince people that we did the job right.

Again, not proposing a change in TLS.

> Unlike typical application protocols which people are generally trying to make work, in the security area you have to deal with people who are trying to break and sabotage you. And that makes the job a lot harder. Persuading people to change a protocol after deployment and use is hard. 
> 
> Besides the subject key, a certificate contains a validity interval and certificate extensions. The certificate extensions may be used to control the behavior of TLS. 

I'm not sure we've discovered any validity interval or other elements that require more than what could come out of a signed DNSSEC response.  In the worst case, we generate ambiguity about what parts of the cert the zone operator asserts or is allowed to assert:
http://www.ietf.org/mail-archive/web/keyassure/current/msg00191.html

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 14 Sep 2010 23:31:41 -0400

Note also that the name for the BoF in Beijing is KIDNS*, which looks  
to my eye as if it means "Keys In DNS".
--Richard

* For some reason, my brain parses this as "kidneys", which doesn't  
seems like a real catchy name.

On Sep 14, 2010, at 7:57 PM, Chris Wright wrote:

> All,
>
> There is a lot of discussion about 'how' to put 'certificates' in  
> the DNS, but I don't understand why we are considering certificates  
> at all? Why isn't just the public key, or some sort of fingerprint  
> of it sufficient? I thought we were trying to bind Public Keys to  
> domain names? What value does the 'certificate' add?
>
> Eg. If I have a domain name host.example.com and this host has an  
> SSH and a HTTPS service running on it, potentially I need a way to  
> put the public key of both the ssh and https service in the DNS and  
> be able to distinguish between the two.
>