Subject: [keyassure] user keys

From: Tony Finch <[email-masked]>
Date: Thu, 19 Aug 2010 18:08:58 +0100

Paul Wouters <[email-masked]> wrote:
>On Wed, 18 Aug 2010, Phillip Hallam-Baker wrote:
>>
>> In my view user keys do not belong in the DNS because the DNS is an
>> infrastructure for locating network services, not network users.
>
> I disagree. You are locating an identity. Currently, that is mostly done
> based on an IP address and port. I'd hope tomorrow that would mostly be
> done based on a public key or hash. Especially with mobile devices, IP's
> are very volatile. To locate a service or user, we need the DNS.

Yes. At the moment the PKIs for identifying people are rather cumbersome.
It would be nice to be able to use DNSSEC for verifying S/MIME or PGP
messages.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SOUTH BISCAY: VARIABLE 3 OR 4. SLIGHT OR MODERATE. FAIR. MODERATE OR GOOD.

---

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

This seems like a bad path to be headed down.  There are lots of  
identifiers that can be tied to public keys: email addresses, SIP  
URIs, telephone numbers, childhood nicknames.  It would be a mistake  
to try to smash them all into the DNS.

Authenticating identifiers from other protocols should be the job of  
those protocols.  It seems like it would be a big enough win for this  
group to come up with a better way of binding keys to domain names.

--Richard

On Aug 19, 2010, at 1:08 PM, Tony Finch wrote:

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Aug 2010 13:25:37 -0400

I agree it would be nice to use DNSSEC in the validation path.

But the problem is that the DNS management is typically under control
of people responsible for managing machines and not people.

We have a spec for putting certs onto a Web server and pulling them via HTTP.

oops, just saw a can of worms here. If we are not careful with our
validation scheme, we will end up in a situation where people can use
the S/MIME cert they were issued (e.g. [email-masked]) to set up a
Web Server (https://bigbank.com/)

That would be bad. The DNS key validation mechanism is going to have
to specify the protocol it is validated for.

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

---

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

> to specify the protocol it is validated for.

That would certainly be bad, but it doesn't necessarily follow that  
you need to specify a protocol.   "[email-masked]" and "bigbank.com"  
are different identifiers, so if you simply make sure that keys are  
properly bound to identifiers, then you don't need to say anything  
about protocols.

--Richard

---

From: Tony Finch <[email-masked]>
Date: Thu, 19 Aug 2010 18:34:31 +0100

On Thu, 19 Aug 2010, Richard L. Barnes wrote:

> This seems like a bad path to be headed down.  There are lots of identifiers
> that can be tied to public keys: email addresses, SIP URIs, telephone numbers,
> childhood nicknames.  It would be a mistake to try to smash them all into the
> DNS.

In many cases user keys have a username@domain structure so it would make
sense for user keys to be signed by a domain key which can in turn be
validated using the DNS.

> Authenticating identifiers from other protocols should be the job of those
> protocols.

That sounds like an argument for leaving TLS as it currently is.

> It seems like it would be a big enough win for this group to come
> up with a better way of binding keys to domain names.

That sounds like an argument for putting user keys in the DNS.

Sorry for being argumentative but you need to be clear about where and why
you are drawing a line :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HEBRIDES: EASTERLY 3 OR 4, INCREASING 5 TO 7, BECOMING CYCLONIC 6 TO GALE 8
LATER. ROUGH. SHOWERS, RAIN LATER. MODERATE OR GOOD.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 19 Aug 2010 10:35:38 -0700

At 1:22 PM -0400 8/19/10, Richard L. Barnes wrote:
>This seems like a bad path to be headed down.  There are lots of identifiers that can be tied to public keys: email addresses, SIP URIs, telephone numbers, childhood nicknames.  It would be a mistake to try to smash them all into the DNS.

+1. The DNS is good for giving information that is related to domain names, not all the users of the things at the domain names.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 19 Aug 2010 14:07:06 -0400

>> identifiers

Although many user identifiers have that form superficially, there are  
more worms here than you expect.  If you're going to be precise and  
thorough, you'll need to address the full syntax of the URI scheme  
you're considering, which is significantly more complex.  And this is  
not mentioning things like internationalization...

Even if you went to the trouble of defining a mapping, it would just  
be an specific way of constructing the names you would use to find  
keys for a given type of identifier.  Nothing would be different about  
how the information is encoded in the DNS.

> That sounds like an argument for leaving TLS as it currently is.

Like Paul said, the DNS is about domain names.  A zone is  
authoritative for the names it contains.  If you start talking about  
things like email addresses, you have a whole different way that  
identifiers are assigned, and the trust model should map along with  
that.

> That sounds like an argument for putting user keys in the DNS.

Not sure how that follows?

--Richard

---

From: Tony Finch <[email-masked]>
Date: Thu, 19 Aug 2010 19:58:44 +0100

> Not sure how that follows?

See below. I was facetiously pointing out that two adjacent sentences
seemed to contradict each other. I don't think "domain name" rules out
"user identifier represented as a domain name". For example several ISPs
create a domain per user, and some sites shard their mail services with
per-user service host names.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
ROCKALL MALIN: EASTERLY 3 OR 4, INCREASING 5 TO 7, BECOMING CYCLONIC 7 TO
SEVERE GALE 9, OCCASIONALLY STORM 10 LATER IN ROCKALL. ROUGH BECOMING VERY
ROUGH. RAIN THEN SQUALLY SHOWERS. MODERATE OR POOR.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 19 Aug 2010 14:59:52 -0400

Ok, but if you're representing users as domain names, then you're just  
doing the same thing as you're doing for any other domain name, and  
it's not interesting any more.

---

From: David Conrad <[email-masked]>
Date: Thu, 19 Aug 2010 12:19:48 -0700

On Aug 19, 2010, at 11:07 AM, Richard L. Barnes wrote:
> Although many user identifiers have that form superficially, there are more worms here than you expect.  If you're going to be precise and thorough, you'll need to address the full syntax of the URI scheme you're considering, which is significantly more complex.  

Why would you need to deal with the full syntax of a URI?  What scenarios are you imagining that would suggest we can't solve the username@domain structure?  My understanding of the suggestion (which may be wrong) is signing something like

$ORIGIN virtualized.org.
drc	IN PGPKEY <mumble>
drc	IN SMIMEKEY <mumble>
...

> And this is not mentioning things like internationalization...

Which isn't a problem since the DNS is 8-bit clean and since you don't have to worry about backwards compatibility, you could put anything into the label.  The only constraint is the label has to be less than 64 bytes.

> Even if you went to the trouble of defining a mapping, it would just be an specific way of constructing the names you would use to find keys for a given type of identifier.  Nothing would be different about how the information is encoded in the DNS.

Right.  It would just be using the DNS as a distributed tag lookup system that now returns validatable values.  Which is OK since that is what the DNS is.

> Like Paul said, the DNS is about domain names.  

I honestly don't understand what this means.

> A zone is authoritative for the names it contains.  If you start talking about things like email addresses, you have a whole different way that identifiers are assigned, and the trust model should map along with that.

A whole different way than what?  I'd think that if you care about the trust model mapping to the way the identifiers were assigned, you'd do zone delegations to make that happen.

I'm clearly missing something.

Regards,
-drc

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 19 Aug 2010 16:02:58 -0400

I'm willing to admit that there are ways to massage different  
identifiers into the DNS if you want to.  It just seems to me like  
that work is more the domain of the working groups that are focused on  
the applications that use those identifiers, rather than a group  
focused on DNS and security.  If the application can map an identifier  
to a domain name, we can handle it, but I don't think we should be  
focused on defining mappings for all the different identifiers that  
are around.

Let me try to clarify what I meant when I said "the DNS is about  
domain names".  As an example, consider the difference between domain  
names and SIP URIs and how they're managed. Information about a domain  
name is stored in a name server, in the form of RRs.  Information  
about a SIP URI is stored in a SIP registrar.  When a DNS application  
wants information about a domain name, it asks the name server; when a  
SIP application wants information about a URI, it asks the registrar.

If information about a SIP URI is going to be published in the DNS,  
then it has to be transferred from the registrar to a name server.  In  
addition to the brittleness this introduces (in terms of keeping data  
in sync, making sure the name translation is done properly, etc.),  
there's also something of a security concern here.  Now a relying  
party has to trust two entities instead of one for the information  
it's using at the application layer -- the registrar and the name  
server.  Even if the registrar is completely honest, the operator of  
the name server might be able to bid down security by saying that  
there's no public key available for the URI in question.

The up-shot is that it seems like the client/RP should be able to ask  
the registrar directly.  In SIP, you might use a presence request; in  
SMTP, you might add a header that UAs can cache.  There doesn't seem  
to me to be any especial benefit in doing it in the DNS, especially  
since the needs of different applications can be very different.

--Richard

On Aug 19, 2010, at 3:19 PM, David Conrad wrote:

>> Although many user identifiers have that form superficially, there  
>> are more worms here than you expect.  If you're going to be precise  
>> and thorough, you'll need to address the full syntax of the URI  
>> scheme you're considering, which is significantly more complex.
>
> Why would you need to deal with the full syntax of a URI?  What  
> scenarios are you imagining that would suggest we can't solve the  
> username@domain structure?  My understanding of the suggestion  
> (which may be wrong) is signing something like
>
> $ORIGIN virtualized.org.
> drc	IN PGPKEY <mumble>
> drc	IN SMIMEKEY <mumble>
> ...
>
> Which isn't a problem since the DNS is 8-bit clean and since you  
> don't have to worry about backwards compatibility, you could put  
> anything into the label.  The only constraint is the label has to be  
> less than 64 bytes.
>
>> Even if you went to the trouble of defining a mapping, it would  
>> just be an specific way of constructing the names you would use to  
>> find keys for a given type of identifier.  Nothing would be  
>> different about how the information is encoded in the DNS.
>
> Right.  It would just be using the DNS as a distributed tag lookup  
> system that now returns validatable values.  Which is OK since that  
> is what the DNS is.
>
>> A zone is authoritative for the names it contains.  If you start  
>> talking about things like email addresses, you have a whole  
>> different way that identifiers are assigned, and the trust model  
>> should map along with that.
>
> A whole different way than what?  I'd think that if you care about  
> the trust model mapping to the way the identifiers were assigned,  
> you'd do zone delegations to make that happen.
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Aug 2010 16:18:46 -0400

I think it is very clear that we are all agreed that we want this functionality.

But there is a distinct difference of opinion as to whether this
should be done using the DNS alone or by using the DNS to provide a
secured like to a service where the data is managed.

We already have protocols for the second approach. What we do not have
is a mechanism for finding out that the data is on offer.

Extending my previous proposal

_smtp._tcp.example.com OPTIONS "ssl=offered SMIME=XKMS,PKIXREP"

(see RFC 4386 for more info)

On Thu, Aug 19, 2010 at 4:02 PM, Richard L. Barnes <[email-masked]> wrote:
> I'm willing to admit that there are ways to massage different identifiers
> into the DNS if you want to.  It just seems to me like that work is more the
> domain of the working groups that are focused on the applications that use
> those identifiers, rather than a group focused on DNS and security.  If the
> application can map an identifier to a domain name, we can handle it, but I
> don't think we should be focused on defining mappings for all the different
> identifiers that are around.
>
> Let me try to clarify what I meant when I said "the DNS is about domain
> names".  As an example, consider the difference between domain names and SIP
> URIs and how they're managed. Information about a domain name is stored in a
> name server, in the form of RRs.  Information about a SIP URI is stored in a
> SIP registrar.  When a DNS application wants information about a domain
> name, it asks the name server; when a SIP application wants information
> about a URI, it asks the registrar.
>
> If information about a SIP URI is going to be published in the DNS, then it
> has to be transferred from the registrar to a name server.  In addition to
> the brittleness this introduces (in terms of keeping data in sync, making
> sure the name translation is done properly, etc.), there's also something of
> a security concern here.  Now a relying party has to trust two entities
> instead of one for the information it's using at the application layer --
> the registrar and the name server.  Even if the registrar is completely
> honest, the operator of the name server might be able to bid down security
> by saying that there's no public key available for the URI in question.
>
> The up-shot is that it seems like the client/RP should be able to ask the
> registrar directly.  In SIP, you might use a presence request; in SMTP, you
> might add a header that UAs can cache.  There doesn't seem to me to be any
> especial benefit in doing it in the DNS, especially since the needs of
> different applications can be very different.
>
> --Richard
>
>
>
>>> thorough, you'll need to address the full syntax of the URI scheme you're
>>> considering, which is significantly more complex.
>>
>> Why would you need to deal with the full syntax of a URI?  What scenarios
>> are you imagining that would suggest we can't solve the username@domain
>> structure?  My understanding of the suggestion (which may be wrong) is
>> signing something like
>>
>> $ORIGIN virtualized.org.
>> drc     IN PGPKEY <mumble>
>> drc     IN SMIMEKEY <mumble>
>> ...
>>
>> Which isn't a problem since the DNS is 8-bit clean and since you don't
>> have to worry about backwards compatibility, you could put anything into the
>> label.  The only constraint is the label has to be less than 64 bytes.
>>
>>> Even if you went to the trouble of defining a mapping, it would just be
>>> an specific way of constructing the names you would use to find keys for a
>>> given type of identifier.  Nothing would be different about how the
>>> information is encoded in the DNS.
>>
>> Right.  It would just be using the DNS as a distributed tag lookup system
>> that now returns validatable values.  Which is OK since that is what the DNS
>> is.
>>
>>> A zone is authoritative for the names it contains.  If you start talking
>>> about things like email addresses, you have a whole different way that
>>> identifiers are assigned, and the trust model should map along with that.
>>
>> A whole different way than what?  I'd think that if you care about the
>> trust model mapping to the way the identifiers were assigned, you'd do zone
>> delegations to make that happen.
>>

---

From: Jakob Schlyter <[email-masked]>
Date: Fri, 20 Aug 2010 00:02:25 +0200

> It would be nice to be able to use DNSSEC for verifying S/MIME or PGP

We should keep in mind that RFC 4398 specifies a method to do this for PGP, e.g. look up CERT(jakob.kirei.se).

	jakob

---

From: Tony Finch <[email-masked]>
Date: Fri, 20 Aug 2010 00:26:24 +0100

> PGP, e.g. look up CERT(jakob.kirei.se).

Aren't we aiming to supersede that?

Tony.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 19 Aug 2010 19:43:59 -0400

Why?  Is it broken?

I've actually been thinking that CERT records will be one of the main  
mechanisms we'll be using here.

On Aug 19, 2010, at 7:26 PM, Tony Finch wrote:

>> We should keep in mind that RFC 4398 specifies a method to do this  
>> for
>> PGP, e.g. look up CERT(jakob.kirei.se).
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Aug 2010 19:52:37 -0400

Main problem I have heard is that certs tend to be quite large in dns terms 

Some are larger than the Ethernet mtu. Most are bigger than the 512 bytes that idiot firewalls tend to filter.

For ssl it is not necessary to have the cert as it is passed in band. Same for ssh (I think). corner case is smime but that is per user keying anyway.

I was thinking of using a URL to retrieve the cert if that was necessary. Then you can get the trust path as well - if your app needs that. 

Sent from my iPad

On Aug 19, 2010, at 7:43 PM, "Richard L. Barnes" <[email-masked]> wrote:

> Why?  Is it broken?
> 
> I've actually been thinking that CERT records will be one of the main mechanisms we'll be using here.
> 
> 
> 
>

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 19 Aug 2010 16:56:40 -0700

> Some are larger than the Ethernet mtu. Most are bigger than the 512 bytes that idiot firewalls tend to filter.

Actually, the idiot firewall isn't the problem for the most part, but the Ethernet MTU is, but even then its still only a ~12% problem or so.  But you can always fall back to TCP for DNS with not too bad a latency hit, especially if you design your DNS resolver to KNOW there are dumb firewalls that can't handle fragments.

However, keeping certs is arguably unnecessary: just a hash of a cert accomplishes the same thing in pretty much any existing cryptographic protocol, and for those that the DNS conveys the cert itself rather than the presence of the cert, then yeah, you have the size of the cert but you can manage: DNSSEC is already blowing out the crap that can't handle fragments and/or 512B.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 19 Aug 2010 19:57:57 -0400

Also, CERT records can carry certificates by reference, i.e., with a  
URI to a cert instead of the cert itself.  So MTU / packet sizes  
shouldn't be an issue unless your URIs are crazy long.
--Richar

On Aug 19, 2010, at 7:56 PM, Nicholas Weaver wrote:

>> Some are larger than the Ethernet mtu. Most are bigger than the 512  
>> bytes that idiot firewalls tend to filter.
>
> Actually, the idiot firewall isn't the problem for the most part,  
> but the Ethernet MTU is, but even then its still only a ~12% problem  
> or so.  But you can always fall back to TCP for DNS with not too bad  
> a latency hit, especially if you design your DNS resolver to KNOW  
> there are dumb firewalls that can't handle fragments.
>
> However, keeping certs is arguably unnecessary: just a hash of a  
> cert accomplishes the same thing in pretty much any existing  
> cryptographic protocol, and for those that the DNS conveys the cert  
> itself rather than the presence of the cert, then yeah, you have the  
> size of the cert but you can manage: DNSSEC is already blowing out  
> the crap that can't handle fragments and/or 512B.
>
>>
>> For ssl it is not necessary to have the cert as it is passed in  
>> band. Same for ssh (I think). corner case is smime but that is per  
>> user keying anyway.
>>
>> I was thinking of using a URL to retrieve the cert if that was  
>> necessary. Then you can get the trust path as well - if your app  
>> needs that.
>>
>>
>> Sent from my iPad
>>
>>>>> We should keep in mind that RFC 4398 specifies a method to do  
>>>>> this for

---

From: Warren Kumari <[email-masked]>
Date: Thu, 19 Aug 2010 20:57:48 -0400

> I've actually been thinking that CERT records will be one of the main mechanisms we'll be using here.

Me too -- I (still) believe that the CERT RR representation is the most elegant -- there are a large number of type values that be be used to represent whatever, and the "certificate or CRL" field is flexible enough that we can extend it by having structured data in it if we need to plomp in more than just a hash / key / blob.

W

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 19 Aug 2010 18:03:02 -0700

>Main problem I have heard is that certs tend to be quite large in dns terms

First off, there have been many earlier threads on DNSEXT about this. If you are saying "I agree with the few people who think this is a problem", that's fine, but it is not widely-agreed to. I do not believe that this mailing list is a good place to recreate that debate without all the DNS mafia here to chime in.

Secondly, you don't have to use certs in the CERT RR. For example, see our proposal in our draft.

>I was thinking of using a URL to retrieve the cert if that was necessary. Then you can get the trust path as well - if your app needs that.

This is re-inventing what we did in IKEv2bis, and you have the chicken-and-egg problem of needing to have secure transport of certificate after getting the URL securely.

Really, this has all been discussed and written down before.

At 4:56 PM -0700 8/19/10, Nicholas Weaver wrote:
>However, keeping certs is arguably unnecessary: just a hash of a cert accomplishes the same thing in pretty much any existing cryptographic protocol.

Exactly.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Aug 2010 21:24:03 -0400

People asked me to justify the design proposal I made, so I did.

In the case of SSL the answer is twofold

1) The full cert is passed in the protocol in any case.
2) Having a separate record bound to a specific protocol means we can
have statements of the form 'SSL is always offered'.

Now the thing about the cert size is why it has not been done that way
in the past. Whether it is a valid reason or not, it is a reason. A
cert signed with RSA 2048 for a RSA 2048 key is going to have 512
bytes of just the signature data. And an RSA 4096 cert is going to be
1K which is pushing the ethernet MTU with fairly minimal X.509
gubbins.

I don't see the transport issue on following a URL, if the hash is in
the DNS we have accreditation for the bits. No further bootstrapping
is necessary.

There are some minor additional advantages to hashes over raw certs,
one is that hashes leak less information. Though why that is an
advantage I am not sure.

Of course this is all reinventing the wheel that many of us have
proposed before. I wrote a chapter in my book proposing a similar
scheme. There is also DKIM and there was the FREESWAN work. We all
seem to be in violent agreement on this specific point.

A new record with the hash algorithm and hash value with an optional
URL field seems to work for most people here.

It also has the advantage that it does not tie us to X.509 certs. The
X.509 certs are clearly optimal for SSL because that is what it is
designed to use. They may not be optimal for other
applications/protocols.

---

From: Jakob Schlyter <[email-masked]>
Date: Fri, 20 Aug 2010 07:25:12 +0200

> have statements of the form 'SSL is always offered'.

while this thread is about 'user keys', I'm not sure how SSL is ready applicable (unless you talk about client certificates). for user keys, and as already mentioned, the CERT RR has support for indirect information, including URLs of X.509 data objects and OpenPGP packets.

	jakob

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 20 Aug 2010 10:58:42 +0200

> Web Server (https://bigbank.com/)

The would be a very bad specification.  However we already have a 
mechanism for coding a email into a domain identifier.  Remember the SOA 
record? :)

So we could specify that

[email-masked] becomes fred.bigbank.com
   and
[email-masked] becomes ondrej\.sury.nic.cz

Also the information in the DNS has to be DNSSEC validated, so how would 
[email-masked] be able to put the information into DNS?  And if we 
assume tight control over DNS, we could maybe specify something like 
"usage" flag?  Or entirely new RR type, so:

bigbank.com TLSFP ....

fred.bigbank.com SMIMEFP ...

Ondrej
-- 
  Ondřej Surý
  vedoucí výzkumu/Head of R&D department
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:[email-masked]    http://nic.cz/
  tel:+420.222745110       fax:+420.222745112
  -------------------------------------------

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 20 Aug 2010 11:09:55 +0200

On 19.8.2010 19:35, Paul Hoffman wrote:
>> URIs, telephone numbers, childhood nicknames.  It would be a
>> mistake to try to smash them all into the DNS.
>
> +1. The DNS is good for giving information that is related to domain
> names, not all the users of the things at the domain names.

As Jakob already said.  RFC 4398 Section 3.2 for X.509 (and 3.3 for 
OpenPGP) states the coding of email address into a domain name.

We don't have to solve all the identifiers.  We could do that just for 
email address.

But I certainly don't want to mangle all together in this (non-)WG.  BTW 
is there any work?  RFC 4398 is already there.  Does it miss something 
important which cannot be used for S/MIME, OpenPGP?
Or is this just an non-existent implementation issue?

Ondrej

---

From: Ben Laurie <[email-masked]>
Date: Fri, 20 Aug 2010 10:29:00 +0100

> It would be nice to be able to use DNSSEC for verifying S/MIME or PGP

Webfinger seems like a better vehicle for this kind of thing (probably
combined with some DNSSEC for key bootstrapping).