Subject: [keyassure] FYI: New Version Notification for draft-hoffman-keys-linkage-from-dns-02

From: Jakob Schlyter <[email-masked]>
Date: Wed, 15 Sep 2010 23:15:57 +0200

Hi,

We just posted an updated version of our draft. Major change since -01 is that we've added the CERT TLSRQ certificate type signaling that a TLS client should ReQuery for a hash-prefixed version of the CERT TLSFP RR (to handle a large amount of certificate fingerprints for a single hostname).

	jakob

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: 15 september 2010 21.16.02 CEST
> Subject: New Version Notification for draft-hoffman-keys-linkage-from-dns-02 
> 
> 
> A new version of I-D, draft-hoffman-keys-linkage-from-dns-02.txt has been successfully submitted by Paul Hoffman and posted to the IETF repository.
> 
> Filename:	 draft-hoffman-keys-linkage-from-dns
> Revision:	 02
> Title:		 Using Secure DNS to Associate Certificates with Domain Names For TLS
> Creation_date:	 2010-09-15
> WG ID:		 Independent Submission
> Number_of_pages: 10
> 
> Abstract:
> 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.
> 
> 
> 
> The IETF Secretariat.
> 
> 

-- 
Jakob Schlyter
Kirei AB - http://www.kirei.se/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 15 Sep 2010 17:42:03 -0400

I took a look, it is an improvement and we seem to be achieving
convergence.

I have been concentrating on the security considerations, which I think are
going to work out similar. So if you are open to merging the drafts you
don't need to repeat my work.

My main point of disagreement is the following paragraph in 2.1 which I
would simply delete. A relying party should not take this type of direction
from any TTP and certainly not the certificate subject. The DNS
administrator has no real idea how the relying application is going to use
the data.

   o  A one-octet value, called "validation preference", specifying the
      preferences for further validation of the certificate in TLS.  A
      certificate association that contains a validation preference..

I don't think this adds any value in any case. A relying application is
going to either determine that the cert is sufficiently secure for its
immediate needs or its going to be answering a user enquiry for more details
on the cert internals in which case it is going to look for as much
information as possible.

I am open to using the KeyID slot for other purposes however. We could for
example use that slot to indicate that a cert is intended for a specific
purpose.

I am pretty skeptical about doing that at the application layer - that is
what cert extensions are for. But I have been playing around with using
certs for dynamic update and other DNS layer uses and there might be some
value in that approach there.

Another point of disagreement is that the records presented are not TLS
records, they are PKIX records that relate to PKIX certs. Hence I prefer my
labels DPKIX and DPTR.

The only real constraint here is that we are talking about assuring
end-entity certificates that are bound to a specific domain and not about
assurances for generalized end-user certificates.

A minor difference is that I use base64 encoding rather than hex, the reason
I did this was to keep the label value as short and possible and also to
make life easier for the admin.

Consider

     e77b719d4e9c63c0b0a0333be0a4188e490b618e.www.example.com. IN CERT
          TLSFP 0 0 AQDne3GdTpxjwLCgMzvgpBiOSQthjg==

Since we will in most cases use the same has function for both, isn't it
easier to write:

     AQDne3GdTpxjwLCgMzvgpBiOSQthjg.www.example.com. IN CERT
          TLSFP 0 0 AQDne3GdTpxjwLCgMzvgpBiOSQthjg

Ok, you still need to go through and change the non-valid base64 characters
with my scheme.

On Wed, Sep 15, 2010 at 5:15 PM, Jakob Schlyter <[email-masked]> wrote:

> Hi,
>
> We just posted an updated version of our draft. Major change since -01 is
> that we've added the CERT TLSRQ certificate type signaling that a TLS client
> should ReQuery for a hash-prefixed version of the CERT TLSFP RR (to handle a
> large amount of certificate fingerprints for a single hostname).
>
>        jakob
>
>
> Begin forwarded message:
>
> > A new version of I-D, draft-hoffman-keys-linkage-from-dns-02.txt has been
> successfully submitted by Paul Hoffman and posted to the IETF repository.
> >
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 15 Sep 2010 17:42:03 -0400

Consider

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 15 Sep 2010 17:42:03 -0400

Consider

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 15 Sep 2010 17:42:03 -0400

Consider

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 15 Sep 2010 17:51:53 -0400

One point that struck me about the TLSRQ/DPTR approach is that it also opens
up the possibility of extending this approach to support RFC822 account
based credentials.

I am not sure this is a good idea, in fact I am sure that it is a pretty bad
one. But it does completely fit the approach.

Consider the following

Key-ID value is 0 for a domain name, 1 for an RFC822 address.

The RFC822 address would have to be canonicalized according to the Unicode
processing rules (or whatever Paul H. suggests we do)

Now to make this work at an administrative level I would have to separate
out my DNS zone acting as a key server and my DNS zone acting as a DNS.

In my DPTR proposal I propose using the data field to provide an indirection
to a different DNS node. That is there because I need to support certain
outsourcing models.

---

From: Zack Weinberg <[email-masked]>
Date: Wed, 15 Sep 2010 15:11:44 -0700

Without commenting on anything else ...

On 2010-09-15 2:42 PM, Phillip Hallam-Baker wrote:
> A minor difference is that I use base64 encoding rather than hex, the
> reason I did this was to keep the label value as short and possible and
> also to make life easier for the admin.

base64 is case sensitive, I think it's a very bad idea to introduce case 
sensitive labels into a presently 100% case insensitive system (the DNS) 
-- especially as I understand the case bits are already being
reused for extra query-ID bits (0x20-coding).

base32 might do, though.

zw

---

From: Adam Langley <[email-masked]>
Date: Wed, 15 Sep 2010 18:31:01 -0400

>       certificate association that contains a validation preference..

The intent of this is to better support EV certificates. There
currently exist security concerns when someone can get ahold of a DV
cert for, say, www.bankofamerica.com. Since the DV and EV cert are in
the same browser origin, the DV cert can poison the browser cache and
subvert the true, EV site.

Because of this, it would be good for EV sites to publish DNSSEC
secured records so that DV certs can be rejected. However, a client
which is willing to accept DNSSEC authorised certs will do so and stop
at that point. However, with the indication byte, the client can know
to perform PKIX validation and find out that it's an EV cert and
therefore gets a different UI.

Not to mention that some folks that I talk to are keen on keeping the
PKIX expiry/revocation infrastructure in place for their sites and
this indication allows them to do so.

Given the, very minor cost, it's something that I'm in favour of.

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 15 Sep 2010 15:40:10 -0700

At 5:42 PM -0400 9/15/10, Phillip Hallam-Baker wrote:

My main point of disagreement is the
following paragraph in 2.1 which I would simply delete. A relying
party should not take this type of direction from any TTP and
certainly not the certificate subject. The DNS administrator has no
real idea how the relying application is going to use the
data.

In some cases, the DNS administrator does. For example, if the
cert is self-signed, the DNS administrator knows that this cert will
not chain to a trust anchor. A similar example would be if the cert
used chains to a trust anchor that the TLS client is not likely to
have; for example, the client is coming from the outside but the trust
anchor is only expected to be loaded on internal browsers. This option
allows the DNS admin to signal to the TLS client that they do not need
to waste any time on what will most likely be a fruitless PKIX
validation.

Another point of disagreement is that the
records presented are not TLS records, they are PKIX records that
relate to PKIX certs. Hence I prefer my labels DPKIX and
DPTR.

I don't understand your first sentence. Your definition of the
RRDATA for DPKIX is:

Certificate data  contains the digest value of
the certificate for

which a binding between the subject key
and the domain name is

asserted

For DPTR, it is:

Certificate data  contains the DNS name to be
used as the root node

to which the calculated selectorn
prefix is prepended.

The only real constraint here is that we
are talking about assuring end-entity certificates that are bound to a
specific domain and not about assurances for generalized end-user
certificates.

We disagree here: we explicitly allow the user to do further PKIX
validation which might entail more than just assurance of the host
name.

A minor difference is that I use base64
encoding rather than hex, the reason I did this was to keep the label
value as short and possible and also to make life easier for the
admin.

Consider

TLSFP 0 0
AQDne3GdTpxjwLCgMzvgpBiOSQthjg==

Since we will in most cases use the same
has function for both, isn't it easier to write:

AQDne3GdTpxjwLCgMzvgpBiOSQthjg.www.example.com. IN
CERT

TLSFP 0 0
AQDne3GdTpxjwLCgMzvgpBiOSQthjg

Ok, you still need to go through and
change the non-valid base64 characters with my scheme.

Host names on the Internet are not case-sensitive, yet Base64
very clearly is. Thus, your proposal won't work consistently for the
host name part. Our proposal, like yours, uses Base64 for the
RRDATA.

--Paul Hoffman, Director

--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 15 Sep 2010 18:53:17 -0400

OK, that makes more sense to me as an objective. The description did not
give me any indication that this is what was intended.

I think we need a lot more discussion on whether that is what is achieved.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 15 Sep 2010 19:10:31 -0400

Aww fishsticks.

If we can't cut and paste, could we perhaps limit the size of the hash given
that we are only using it as a selector and thus we can probably tolerate a
probability of collision a little higher than 1/2^80

On Wed, Sep 15, 2010 at 6:11 PM, Zack Weinberg <[email-masked]> wrote:

> sensitive labels into a presently 100% case insensitive system (the DNS) --
> especially as I understand the case bits are already being

---

From: Tony Finch <[email-masked]>
Date: Thu, 16 Sep 2010 00:51:55 +0100

> one. But it does completely fit the approach.

Some sites already have per-user information in the DNS, for sharding
their mail service. So it's not completely unreasonable.

> processing rules (or whatever Paul H. suggests we do)

Email addresses are not (yet) unicode. The only thing you might want to
canonicalize is the case of the domain. See also RFC 5750 section 3 for
how email addresses are represented in certificates.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Thu, 16 Sep 2010 10:08:03 +0200

Hi,

On 09/15/2010 11:15 PM, Jakob Schlyter wrote:
> We just posted an updated version of our draft. Major change since
> -01 is that we've added the CERT TLSRQ certificate type signaling
> that a TLS client should ReQuery for a hash-prefixed version of the
> CERT TLSFP RR (to handle a large amount of certificate fingerprints
> for a single hostname).

I do not like a hash published in the DNS.  And in this case there is an
alternative.  I would prefer if the certificates are looked up based on
the name of the (virtual hosted) website (prefixed).  Those are shorter
and more meaningful.

Also they could potentially be done in advance (although to avoid
spurious queries the querier could 'remember' that the site used TLSRQ).

Best regards,
   Wouter

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 16 Sep 2010 10:35:41 +0200

On 15 sep 2010, at 23.42, Phillip Hallam-Baker wrote:

> I am open to using the KeyID slot for other purposes however. We could for example use that slot to indicate that a cert is intended for a specific purpose. 

I'm not sure I understand what the "KeyID slot" is - it is not mentioned in neither RFC 4398 nor our draft. please elaborate.

> Another point of disagreement is that the records presented are not TLS records, they are PKIX records that relate to PKIX certs. Hence I prefer my labels DPKIX and DPTR.

It is our intention that the language of the draft does not disqualify other TLS certificate types, e.g. OpenPGP.
Simon; could you please verify that the latest draft still works with OpenPGP?

	jakob

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 16 Sep 2010 10:56:54 +0200

(subject updated to keep the issues apart)

On 15 sep 2010, at 23.51, Phillip Hallam-Baker wrote:

> In my DPTR proposal I propose using the data field to provide an indirection to a different DNS node. That is there because I need to support certain outsourcing models.

We did consider adding this but in the end choose not to, as it opens a whole can of worms that are trying to follow chains of trust between different DNS domains. While inter domain delegation of trust might seem nifty, I'm not sure that we should try to solve this within this context.

I believe the outsourcing model you are proposing would be the DNSSEC version of a certificate authority, which could be seen as the opposite of the domain self-assurance that we are describing here. If you believe there is another use case, I'd be happy to hear more about it.

	jakob

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 16 Sep 2010 11:10:08 +0200

On 16 sep 2010, at 10.08, W.C.A. Wijngaards wrote:

> I do not like a hash published in the DNS.

Why?

> And in this case there is an

If one has several webservers, each with a different cert, behind a load balancer - how can I find out the name of the virtual host?

> spurious queries the querier could 'remember' that the site used TLSRQ).

Please describe how this can be done in advance.

	jakob

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Thu, 16 Sep 2010 11:26:45 +0200

Hi Jakob,

>> I do not like a hash published in the DNS.

I like readability, if possible.  It is also smaller and faster (can be
done earlier in the setup process).

> If one has several webservers, each with a different cert, behind a
> load balancer - how can I find out the name of the virtual host?

Then you have to publish multiple records.  If that is the real-world
problem (I thought multiple virtual hosts in apache), then you are correct.

> Please describe how this can be done in advance.

Since the webclient knows the name it is querying, it knows how to
prefix it.  And can do the query when it knows TLSRQ is in use.

Best regards,
   Wouter

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 16 Sep 2010 12:44:47 +0200

On 16 sep 2010, at 11.26, W.C.A. Wijngaards wrote:

> Then you have to publish multiple records.

correct, and when doing so you can choose between publishing all records using the TLSFP RR at the hostname itself, or publish a TLSRQ RR at the hostname and a number of TLSFP RR using the hash-prefixed hostnames.

> If that is the real-world problem (I thought multiple virtual hosts in apache), then you are correct.

People tell us this is a real-world problem. I might not agree it is, but who am I to judge what craziness people deploy.

	jakob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 16 Sep 2010 08:12:09 -0400

I think the important thing here is for the administration of zones with
keys to look as close as possible to the use of zones without keys.

There is a whole can of worms here that needs to be considered with respect
to CNAME aliases and SRV chains.

What I see as most important is to get people using crypto. Using a weakly
assured cert is not a problem, relying on a weakly assured cert is the
problem. What I am trying to do in the ESRV proposal is to enable what the
better-than-nothing security people were trying to do - promiscuous crypto.
(I am also trying to enable very strong assurances such as EV).

Using strong crypto with weak keys is still better than plaintext. You can't
do that and then tell the user that they are safe of course. You probably
don't want to tell them anything at all in fact.

I am currently debugging someone's DNS config for a major blog. They don't
do anything in house, everything just points off to other domains. They
outsource mail and web hosting. They are not the ones that are going to be
configuring the crypto here, the web hosting service is going to do that.

At some time we hope and expect the registrar to start signing that DNS
zone. Quite possibly that will happen without any input from the customer at
all. The registrar may just flip a switch and start signing the zone. That
is why I do not believe that we can draw any intention from the act of
signing CERT records.

Wether or not we have pointers in the DPTR record, the DNS protocol is full
of 'em and we have to understand the semantics and the operational
consequence.

On Thu, Sep 16, 2010 at 4:56 AM, Jakob Schlyter <[email-masked]> wrote:

> > In my DPTR proposal I propose using the data field to provide an
> indirection to a different DNS node. That is there because I need to support
> certain outsourcing models.
>
> We did consider adding this but in the end choose not to, as it opens a
> whole can of worms that are trying to follow chains of trust between
> different DNS domains. While inter domain delegation of trust might seem
> nifty, I'm not sure that we should try to solve this within this context.
>
> I believe the outsourcing model you are proposing would be the DNSSEC
> version of a certificate authority, which could be seen as the opposite of
> the domain self-assurance that we are describing here. If you believe there
> is another use case, I'd be happy to hear more about it.
>
>
>        jakob
>
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 16 Sep 2010 08:55:06 -0400

On Thu, Sep 16, 2010 at 4:35 AM, Jakob Schlyter <[email-masked]> wrote:

> > I am open to using the KeyID slot for other purposes however. We could
> for example use that slot to indicate that a cert is intended for a specific
> purpose.
>
> I'm not sure I understand what the "KeyID slot" is - it is not mentioned in
> neither RFC 4398 nor our draft. please elaborate

Sorry, key tag.

"The key tag field is the 16-bit value computed for the key embedded

   in the certificate, using the RRSIG Key Tag algorithm described in
   Appendix B <http://tools.ietf.org/html/rfc4398#appendix-B> of [12
<http://tools.ietf.org/html/rfc4398#ref-12>].  This field is used as
an efficiency measure to

We certainly don't need to use this in our approach. And I don't think it is
particularly well thought out for the intended use in any case.

> It is our intention that the language of the draft does not disqualify
> other TLS certificate types, e.g. OpenPGP.
Given the choice between supporting multiple security protocols (TLS, IPSEC,
S/MIME, WS-*) and supporting multiple certificate formats (PKIX, OpenPGP,
SPKI, etc.) I would choose the one that gave functionality.

PKIX is necessary and sufficient. Every crypto application of any
consequence can consume PKIX certs and has been used extensively in that
mode.

But do we really make a choice on either count?

The only reason I was limiting my scope to PKIX is that I wanted to make the
spec as short and concise as possible and the way to do that in my view was
to limit the number of cert formats to the one format we have to support.

It now occurs to me that making the spec more general may actually allow it
to be shorter.

Let us say that the certificate type is DCERT and it may be applied to any
certificate format of any type in which one key is signed with another.

By placing a DCERT record in the DNS zone, the domain name holder is
asserting a binding between the specified domain service label and the
certificate contents.

By signing a DNS service zone, the signer is asserting that the signed RR
sets were specified by or on behalf of the domain name holder.

It follows that when a DCERT record exists, is signed and the specified
digest matches the digest calculated over the corresponding certificate,
that these are equivalent to a certificate with the signer identity in the
place of the issuer and the domain service label in the place of the subject
and all other fields from the original certificate carried over.

While this is expressed in PKIX terms, the same components are present in an
OpenPGP key signing, SPKI certificate or SAML assertion.

If we adopt this approach the normative sections of the specification are
very small and compact and the rest of the specification is limited to
explaining the consequences of that design choice.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 16 Sep 2010 10:27:58 -0400

On 16/09/2010 8:12 AM, Phillip Hallam-Baker wrote:
> There is a whole can of worms here that needs to be considered with
> respect to CNAME aliases and SRV chains.

One of the question I want answered is what does the following mean:
	_xmpp._tcp.ogud.com   CNAME  _xmpp._tcp.jabber.org

Assuming ogud.com and jabber.org are signed
is this a certification by ogud.com to use the keying information
from jabber.org.

Or how else does someone express outsourcing of a service in a
secure manner?
and without the outsource entity to have to produce a different 
certificate for all domains that the it is serving.

So I would like to see the draft charter have two goals:
Document how a (set of) protocol(s) can extract keying/certificates from 
DNS that are protected by DNSSEC.

Document how one domain can "certify" interdomain trust via the
different DNS mechanisms, CNAME, SRV target ....

I would suggest the milestones for these activity all be in 2011/2
and the working group not start serious work on this until after the
initial work has been agreed upon.

	Olafur

	Olafur

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 16 Sep 2010 08:13:38 -0700

>done earlier in the setup process).

Errr, the hash of a certificate will inherently be smaller than the certificate itself. Neither will have human readability.

>problem (I thought multiple virtual hosts in apache), then you are correct.

There is a small number of sites that do this today. The one I looked at had at least five certificates (I tried it from five different locations on the net, got five different certs, and then stopped).

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 16 Sep 2010 11:47:41 -0400

I am broadly in agreement here, except that I would state it as:

Document how DNS+DNSSEC can be used to assert a certificate assurance.

Document how applications can interpret DNS data including CERT/DCERT,
CERT/DPTR, SRV, CNAME

I think we can come up with agreement on the first one quite quickly.
Certainly we can come to a much better understanding and specification of
the RR format and data and the intent of the parties putting that data in
than currently exists for the other CERT certificate types.

I think 2011 is a very aggressive date for the second and 2012 may be
optimistic. It is a hard problem and I think we are only going to know the
answer with a degree of certainty after we have some actual experience of
deployment and use.

"Assuming ogud.com and jabber.org are signed is this a certification by
ogud.com to use the keying information from jabber.org."

I think we need to consider all of the following cases:

1) Nothing is signed
2) Only ogud.com is signed
3) Only jabber.org is signed
4) Both are signed under different keys
5) Both are signed under the same key

In each case the questions are:

1) Should the key be used for encryption?
2) Is the key sufficient to establish confidentiality?
3) Is the key sufficient to establish integrity?
4) What should we tell the user?

The answer to (1) is almost always going to be 'yes'.

If we try to answer these questions in the context of DNSSEC alone we are
likely to come up with some very limited and limiting conclusions since we
don't know how either ogud.com or jabber.org are being managed and we end up
having to make worst case assumptions.

We could however imagine a situation in which either or both domains are
managed in secure, audited facilities. And this information may be available
to the parties, either through out of band means or through extensions in a
cert assuring the DNSSEC signing key.

On Thu, Sep 16, 2010 at 10:27 AM, Olafur Gudmundsson <[email-masked]> wrote:

> and without the outsource entity to have to produce a different certificate
> for all domains that the it is serving.
>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 16 Sep 2010 12:07:53 -0400

Actually, this question is already being discussed in the XMPP WG:
<http://tools.ietf.org/html/draft-ietf-xmpp-dna>
<http://tools.ietf.org/html/draft-barnes-xmpp-dna>

The general idea there is that if you have a DNSSEC-protected  
delegation record, then the client should accept credentials that  
authenticate the delegate's name (the target domain instead of the  
source domain).  So if a client gets the following delegation...

_xmpp-server._tcp.ogud.com SRV xmpp-server.l.google.com.

... it would accept a certificate for xmpp-server.l.google.com  
(instead of requiring a cert for ogud.com).  The focus in XMPP has  
been on SRV, because that's what is used for delegation in that  
context, but the same logic presumably applies to other types of  
delegation records (CNAME, NAPTR, etc.)

IMO, however, this is a completely separate question from keyassure/ 
KIDNS.  KIDNS is about discovering keys associated with a given name.   
The delegation issues are related to what name you're looking for keys  
for in the first place.

--Richard

On Sep 16, 2010, at 10:27 AM, Olafur Gudmundsson wrote:

> Document how a (set of) protocol(s) can extract keying/certificates  
> from DNS that are protected by DNSSEC.
>