Subject: Re: [keyassure] Am I missing something?

From: Paul Hoffman <[email-masked]>
Date: Tue, 14 Sep 2010 18:30:13 -0700

At 9:57 AM +1000 9/15/10, Chris Wright wrote:
>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?

See Appendix A of <http://tools.ietf.org/html/draft-hoffman-keys-linkage-from-dns-01>. Basically: there may be other information in the server's cert that the TLS client cares about.

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

No. The RR allows use of a key or a hash-of-key.

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

True, that's all we *need*. A reasonable question is whether we can do more. Our draft currently is in the "do more" stage, but could be dialed down to "do less" if the (eventual) WG wants it to be.

>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.

"Modify the protocol" is one model; another is "only change the certificate validation, not the protocol" is another. Phill's draft (I think) is in the first category, Simon's and ours are in the second.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 14 Sep 2010 23:08:39 -0400

No, my draft proposes the same approach as far as key assurance goes.

I do however consider the fact that changing the validation mechanism
changes the security considerations in major ways however.

One difference is that I do not limit the scope to TLS. I believe that if we
specify a mechanism for assuring certs through the DNS then we have to
convince at least ourselves that we understand the process well enough to
use it with any security mechanism that uses certs.

The other difference is that Paul's draft does not consider the issue of
scale and multiple keys per service and Simon's adopts prefixes while I am
proposing the scheme proposed by Ben and some other Google people.

Now answering Chris' actual question about limiting the use of a key to a
specific protocol. Simon's use of prefixes would accomplish that but runs
into issues to do with the fact that prefixes don't work very well with
CNAMES as was discussed on the list.

I originally believed this to be a very important question. I have since
reconsidered. My argument is as follows: The only way that such a
restriction can be enforced in certificate driven TLS is by putting a
extension in the certificate and marking it critical. We are using
certificates and so we can re-use the same code paths and get precisely the
same expressiveness.

If there is a way to achieve the same result without creating new code paths
I greatly prefer it for both ease of coding and ease of maintenance. That is
why I now reject the prefixing approach for specifying use restrictions (but
make use of it for assisting discovery of the appropriate CERT RR with large
numbers of certs)

On Tue, Sep 14, 2010 at 9:30 PM, Paul Hoffman <[email-masked]> wrote:

> >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?
>
> See Appendix A of <
> http://tools.ietf.org/html/draft-hoffman-keys-linkage-from-dns-01>.
> Basically: there may be other information in the server's cert that the TLS
> client cares about.
>
> >Surely all we need is a mechanism to distinguish which Public Key is bound
> to which domain name, and for which services.
>
> True, that's all we *need*. A reasonable question is whether we can do
> more. Our draft currently is in the "do more" stage, but could be dialed
> down to "do less" if the (eventual) WG wants it to be.
>
> >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.
>
> "Modify the protocol" is one model; another is "only change the certificate
> validation, not the protocol" is another. Phill's draft (I think) is in the
> first category, Simon's and ours are in the second.
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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