Subject: [keyassure] Fwd: I-D Action:draft-hoffman-keys-linkage-from-dns-03.txt

From: Paul Hoffman <[email-masked]>
Date: Mon, 4 Oct 2010 16:42:04 -0700

>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-03.txt
>	Pages           : 13
>	Date            : 2010-10-04
>
>TLS and DTLS use 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-03.txt

The new draft has a slew of changes (listed near the end) that were suggested by many people on this list.

Comments are appreciated, but we would prefer that discussion of this group becoming an IETF WG be considered much higher priority, given that we don't know what the first draft of the WG document will be.

--Paul Hoffman, Director
--VPN Consortium

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 5 Oct 2010 04:43:13 +0300

> "The TLSRQ certificate type has a certificate body with a single octet
> of 0.  The TLSFP certificate type is TBD2."

Do you mean "The TLSRQ certificate type is TBD2."?

-Ilari

---

From: Geoff Beier <[email-masked]>
Date: Tue, 5 Oct 2010 13:18:33 -0400

On Mon, Oct 4, 2010 at 19:42, Paul Hoffman <[email-masked]> wrote:
>    If a certificate association contains a hash type that is not
>   understood by the TLS client, that certificate association MUST be
>   completely ignored.

This situation could be avoided entirely by requiring that the hash
type be the same as the hash used to produce the signature over the
CERT RR in question. Since the signature must be verified before the
association is processed, no client could get this far without
supporting the hash type.

Regards,

Geoff

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Oct 2010 08:53:11 -0700

>Do you mean "The TLSRQ certificate type is TBD2."?

Yes, thanks!

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Oct 2010 10:42:30 -0700

>supporting the hash type.

Good point. We will suggest this in the next draft.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Wouters <[email-masked]>
Date: Sun, 24 Oct 2010 17:01:54 -0400 (EDT)

>> 	Filename        : draft-hoffman-keys-linkage-from-dns-03.txt

I like this draft. I have only one concern. This method does not allow
one to query the DNS in an opportunistic matter, and based upon CERT/TLSFP
records received back, decide on a different course of action.

For instance, example.com might have a TLS cert for SMTP, but not for
HTTPS. Querying the DNS for a cert record will not tell me I can connect
on HTTPS to that server.

It would be nice if we could do this, so we have some method of migrating
the masses of the web servers to use HTTPS without having to go through
an HTTP redirect (which way too often, will leak cookies, Etags or other
information that could be used to later take over the HTTPS connection.

A next logical step would be to try and phase out HTTP for HTTPS. If possible,
this standard should take that signalling into consideration. The less
redirects and DNS queries we need to do, the better.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 24 Oct 2010 14:45:03 -0700

>records received back, decide on a different course of action.

Actually, it does, if you ask for the specific host. However...

>HTTPS. Querying the DNS for a cert record will not tell me I can connect

That is correct. It is not correct, however, if you query for www.example.com and mail.example.com: then you do know that the services at each of those two hosts (which might reside on the same box) use TLS.

The "tell me all the TLS-enhanced services at example.com" issue is still interesting, but it devolves very quickly. You are assuming that "example.com" is the right cutoff without knowing how that zone names the hosts that provide services. You do *not* want .com giving a single answer for all of its subdomains, do you? If not, why do you want example.com?

Our design explicitly chose "give the exact host name, and we'll tell you about it". If folks want something that is along the line of "give a zone name and we'll tell you about the layers one or more levels down", I hope they can also say how to prevent the "VeriSign gets to give this data for all of .com" and "PIR gets to give this data for all of .org" problem.

>information that could be used to later take over the HTTPS connection.

Fully agree. The folks in the websec WG are working on this problem.

>redirects and DNS queries we need to do, the better.

Yep.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 24 Oct 2010 18:03:28 -0400

That is an example of security policy. That is exactly what I propose in
ESRV and what CAA is a form of.

I discussed this issue with Tim Polk last Friday and as I expected, he
thinks that there is a significant risk that a group that tries to do
security policy will never terminate. So he would like to see experimental
proposals being made before the WG looks at them.

Specification of trust anchors is the hardest aspect of security policy to
get right.

If we have a statement in the DNS/DNSSEC that says 'always use SSL' for a
given protocol, we can then ensure that every communication uses the highest
degree of security supported by both the client and server.

In that world we do not require the padlock icon at all. The only
communication to the user that is worth communicating to the user is 'we
think you are safe'. A DV cert only allows encryption to be established and
that is a fairly low level of risk control. The probability that an end
point is malicious is far greater than the probability that the
infrastructure has been compromised for most Internet use cases. So securing
the network connection alone is only giving a very weak form of protection.

I would like to see the padlock icon retired and to only use user
notification when an EV certificate is in use and we have a demonstration of
accountability for the end point.

On Sun, Oct 24, 2010 at 5:01 PM, Paul Wouters <[email-masked]> wrote:

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

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

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 25 Oct 2010 15:09:43 +0200

Paul Hoffman <[email-masked]> writes:

> That is correct. It is not correct, however, if you query for
> www.example.com and mail.example.com: then you do know that the
> services at each of those two hosts (which might reside on the same
> box) use TLS.

One part that I disliked was that you don't separate on port.  So it is
not possible to query for a TLS fingerprint for certificate used on port
X and do the same for port Y without having to match them all.  I
believe this primarily makes it difficult to deploy, because it is
difficult to separate DNS privileges between the people responsible for
the different services.

/Simon

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 25 Oct 2010 10:02:25 -0400

Whether this is an issue or not depends on whether the semantics are "here is a key you can use" or "here are the only keys you can use"

I have also had discussions with the AD. My expectation was that the group will be required to produce a means of establishing keys as being valid before it would be allowed to address any aspect of security policy. I also anticipated being required to produce experimental drafts for any security policy mechanism. This is what I believe will be required of the group.

It has to be possible to use dnssec to establish a key for a mail server that lives on the same dns node as a Web server without affecting operation of the Web server in any way.

Those requirements cannot and should not be ignored for the sake of saving a few DNS round trips.

Reuse of the CERT record to establish a key as being valid goes beyond the original semantics of the record but is something i think we can justify. But using it to communicate security policy goes too far in my view.

Sent from my iPad

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 25 Oct 2010 07:51:45 -0700

>difficult to separate DNS privileges between the people responsible for

The common practice is to give each server application its own domain name. This is not the only practice, but it is common. You want to not require that practice, at a cost of the DNS administrator needing to add some extra information in the DNS, and the client app needed to request that information. The question is whether the cost to everyone of those additions to the protocol are worth the benefit for the few who do not have unique domain names for each server application. I claim the cost to everyone is not worth the benefit to the few, but others may disagree.

>Whether this is an issue or not depends on whether the semantics are "here is a key you can use" or "here are the only keys you can use"

Correct.

>It has to be possible to use dnssec to establish a key for a mail server that lives on the same dns node as a Web server without affecting operation of the Web server in any way.

Can you say more about why you have this requirement? When the DNS protocol prevents you from doing something at one level but completely allows you do do something by creating another name within a subordinate namespace, what makes it so required that you only do things at the top-level name? There are lots of other examples of such requirements in the DNS protocol; why is this one so important?

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Wouters <[email-masked]>
Date: Mon, 25 Oct 2010 12:26:27 -0400 (EDT)

> The common practice is to give each server application its own domain name. This is not the only practice, but it is common. You want to not require that practice, at a cost of the DNS administrato…

I would say the world is moving in the other direction. You use "cnn.com" and "twitter.com", not www.cnn.com or www.twitter.com.
I am [email-masked], not [email-masked].

If anything, we are trying to reduce the combinations of http/https/www/ methods of reaching a website into one.

Using a port specifier would in my opinion be very useful. It will also reduce the number of records returned that have
to be checked by the client that is only interested in one particular service/port. But we have to be careful not to
increase the amount of queries by missing the right port.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 25 Oct 2010 13:12:03 -0400

On Mon, Oct 25, 2010 at 10:51 AM, Paul Hoffman <[email-masked]>wrote:
>
> The common practice is to give each server application its own domain name.
> This is not the only practice, but it is common. You want to not require
> that practice, at a cost of the DNS administrator needing to add some extra
> information in the DNS, and the client app needed to request that
> information. The question is whether the cost to everyone of those additions
> to the protocol are worth the benefit for the few who do not have unique
> domain names for each server application. I claim the cost to everyone is
> not worth the benefit to the few, but others may disagree.

I don't think that this group is going to be allowed to make that decision.
The reason that we have an IESG and an IAB is to prevent WGs introducing
additional assumptions into the architecture that hobble other groups in the
future.

That said, I think it is the wrong approach because it will stop
applications being written to automatically produce the appropriate DNS
records. [see later]

> >Whether this is an issue or not depends on whether the semantics are "here
> is a key you can use" or "here are the only keys you can use"
>
> Correct.

And the very strong impression I was left with after my discussion with Tim
was that we would have to solve #1 before being allowed to go to #2.

> >It has to be possible to use dnssec to establish a key for a mail server
> that lives on the same dns node as a Web server without affecting operation
> of the Web server in any way.
>
> Can you say more about why you have this requirement? When the DNS protocol
> prevents you from doing something at one level but completely allows you do
> do something by creating another name within a subordinate namespace, what
> makes it so required that you only do things at the top-level name? There
> are lots of other examples of such requirements in the DNS protocol; why is
> this one so important?

For example, Alice installs sendmail on example.com. There is no way for a
script to determine that there is a HTTP server on example.com. It might be
a completely fresh install of the OS and the admin installed sendmail before
apache.

It would be really nice if sendmail could just spin up a self signed keypair
and propose a DNS CERT record. But it isn't going to be able to do that if
there is any risk of affecting the Web service. Using CERT records that
establish keys and restrict at the same time means that the sendmail script
would likely disable more than a few Web servers.

Now we could address SMTP by insisting on a different name for the hosts
declared in the MX record. But we can't do that for IMAP or any other
protocol which does not have SRV discovery as a requirement.

[We do in any case have to consider and describe what is done to handle
CNAMEs, DNAMEs, SRV records and any other record that causes name
substitution to take place.]

I think that we can square this circle, but we will need another RR to do
so. or rather, we could try to cram the information into the CERT record but
I think that would get a lot of pushback.

Since one of the base assumptions here is that we are going to be using
DNSSEC, we should expect that the infrastructure that will allow that data
through will have support for using unknown RRs.

So lets imagine we introduce one new RR 'Server Security Policy'.

The SSP record may be used in either a prefixed form or an unprefixed form.
The rules for using SSP is that a client attempting to connect to a service
at x.example.com will always query for the SSP record for x.example.com.

If the SSP record exists, it MAY apply to every service at example.com or it
MAY have a flag that says 'lookup protocol prefixed SSP' or it may have a
flag that says 'lookup SRV and then lookup SSP' (etc.)

In either case the SSP record MAY specify security policies such as 'always
use SSL' or 'valid certs MUST conform to specification Y'.

This approach allows for root restriction to be by requiring there to be a
companion CERT record or by inclusion of a specific policy OID or existence
of a trust chain to a specific certificate signing certificate.

That is what I would anticipate as a requirement since using the DNS to
distribute certificate assurance data is going to be considered 'research'
and there is a longstanding resistance to building research on research.

Looking through the decision tree, the overhead is one additional DNS lookup
that is made in parallel with the A and AAAA lookup for the case that no SSP
record exists.

In the case that there is an SSP record, the overhead depends on how the DNS
resolver is tuned. If the resolver is tuned to optimize SSP lookup (e.g.
using DPLS) the entire lookup can be performed in one round trip in every
single case.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 25 Oct 2010 13:44:08 -0400

On Mon, Oct 25, 2010 at 12:26 PM, Paul Wouters <[email-masked]> wrote:

>  The common practice is to give each server application its own domain
>> name. This is not the only practice, but it is common. You want to not
>> require that practice, at a cost of the DNS administrator needing to add
>> some extra information in the DNS, and the client app needed to request that
> I would say the world is moving in the other direction. You use "cnn.com"
> and "twitter.com", not www.cnn.com or www.twitter.com.
> Using a port specifier would in my opinion be very useful. It will also
> reduce the number of records returned that have
> to be checked by the client that is only interested in one particular
> service/port. But we have to be careful not to

At one point I had the following scheme:

_80._http._tcp.example.com

That runs into corner cases with CNAME. In particular:

_80._http._tcp.www.example.com XXX "blah...."
www.example.com CNAME example.com

Trying to write discovery rules that are consistent and efficient and work
with both CNAME and wildcards tend to fail round prefixes unless you can
write the rules in such a way that the first lookup you do is always for an
unprefixed record. Once past your first lookup you can use prefixes without
issue.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 27 Oct 2010 09:45:31 +0200

On Mon, Oct 25, 2010 at 12:26:27PM -0400,
 Paul Wouters <[email-masked]> wrote 
 a message of 18 lines which said:

> I would say the world is moving in the other direction. You use
> "cnn.com" and "twitter.com", not www.cnn.com or www.twitter.com.  I
> am [email-masked], not [email-masked].

HTTP is very specific in that respect. It is the only major protocol
(I do not consider RFC 1288 as "major") which do not use SRV (or a
similar solution, such as MX). Hence the trick of an address record on
the delegated domain.

For your second example, the name to lookup in the DNS is
hermes.jabber.org, target of the SRV, not jabber.org.