Subject: Re: [dane] To DANE or to WebFinger?

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 3 May 2013 07:47:15 -0400

+1 to the original post and Paul's.

Putting per user data in the DNS is a lousy approach, it has never been a
succes because the DNS administrators are typically network admins and they
are a separate class to DNS admins.

A better approach would be to use WebFinger/XKMS/LDAP/TBS to serve up an EE
cert for the end user and to use DANE to establish a trust anchor under
which the EE cert is issued.

The amount of email that is protected by message layer security is a
negligible fraction of that protected by STARTTLS. One of the main reasons
for that is that the per client user model is fundamentally broken.

On Fri, Apr 19, 2013 at 5:03 PM, Paul Hoffman <[email-masked]> wrote:

> On Apr 19, 2013, at 1:29 PM, Richard Barnes <[email-masked]> wrote:
>
> > Just a thought: It might be simpler to do S/MIME certificate discovery
> using WebFinger than using DANE.  You would just have to do an HTTPS query
> to a URI of the  form...
> >
> > <
> https://example.com/.well-known/webfinger?resource=mailto:[email-masked]&rel=certificate
> >
> >
> > ... then parse a JSON object to find the certificate.  As opposed to
> having an appropriately upgraded DNS library, being able to do DNSSEC, and
> parsing the binary record format.
>
> That might be a good way to do certificate discovery, but not really a
> good way to have a second trust anchor if one wanted to get away from the
> distributed PKIX hierarchies.
>
> There are plenty of ways to do certificate discovery. The question is how
> to be sure that the certificate you get is one you want to use.
>
> > This process could still benefit from DANE, via TLSA validation on the
> HTTPS connection.  And basically the only documentation you would need
> would be to define the "certificate" relation type.
>
> Um, doesn't that wipe out the supposed advantages you list above?
>
> --Paul Hoffman
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

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

---

From: Leif Johansson <[email-masked]>
Date: Fri, 03 May 2013 14:15:39 +0200

On 05/03/2013 01:47 PM, Phillip Hallam-Baker wrote:
> Putting per user data in the DNS is a lousy approach, it has never
> been a succes because the DNS administrators are typically network
> admins and they are a separate class to DNS admins.
Hey, DNS is just a protocol. I don't think anybody is suggesting
running end-user data off of bind9 :-)

The critical question is one of trust management: using webfinger
ties you to the "web pki" for all practical purposes. Using dane ties
you to the dnssec root.  Personally I'd prefer more options.

>
> A better approach would be to use WebFinger/XKMS/LDAP/TBS to serve up
> an EE cert for the end user and to use DANE to establish a trust
> anchor under which the EE cert is issued.
>
>
> negligible fraction of that protected by STARTTLS. One of the main
> reasons for that is that the per client user model is fundamentally
> broken.
>
>
>
> On Fri, Apr 19, 2013 at 5:03 PM, Paul Hoffman <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     > Just a thought: It might be simpler to do S/MIME certificate
>     discovery using WebFinger than using DANE.  You would just have to
>     do an HTTPS query to a URI of the  form...
>     >
>     >
>     <https://example.com/.well-known/webfinger?resource=mailto:[email-masked]&rel=certificate>
>     >
>     > ... then parse a JSON object to find the certificate.  As
>     opposed to having an appropriately upgraded DNS library, being
>     able to do DNSSEC, and parsing the binary record format.
>
>     That might be a good way to do certificate discovery, but not
>     really a good way to have a second trust anchor if one wanted to
>     get away from the distributed PKIX hierarchies.
>
>     There are plenty of ways to do certificate discovery. The question
>     is how to be sure that the certificate you get is one you want to use.
>
>     > This process could still benefit from DANE, via TLSA validation
>     on the HTTPS connection.  And basically the only documentation you
>     would need would be to define the "certificate" relation type.
>
>     [email-masked] <mailto:[email-masked]>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 3 May 2013 11:14:05 -0400

What I was proposing was the following:

example.com wants to issue S/MIME certs for all its account holders, to do
this they:

1) Establish a PKIX CA

2) Create a self signed root cert or a request a cert chained to a public
root [in which case it MUST be constrained to only issue S/MIME certs and
only for the specified domain]

3) Create a DANE record to attest to the certificate signing certificate.

4) Issue S/MIME certs under the CA.

This approach uses DANE for certificate attestation but does not attempt to
turn DANE into a certificate discovery protocol for end user certificates.

On Fri, May 3, 2013 at 8:15 AM, Leif Johansson <[email-masked]> wrote:

>  Putting per user data in the DNS is a lousy approach, it has never been
> a succes because the DNS administrators are typically network admins and
> they are a separate class to DNS admins.
>
>  A better approach would be to use WebFinger/XKMS/LDAP/TBS to serve up an
> EE cert for the end user and to use DANE to establish a trust anchor under
> On Fri, Apr 19, 2013 at 5:03 PM, Paul Hoffman <[email-masked]>wrote:
>
>> On Apr 19, 2013, at 1:29 PM, Richard Barnes <[email-masked]> <[email-masked]>wrote:
>>
> dane mailing [email-masked]://www.ietf.org/mailman/listinfo/dane
>
>
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 3 May 2013 11:49:16 -0400

> you to the dnssec root.  Personally I'd prefer more options.

Then use DANE to authenticate the HTTPS server in the WebFinger
transaction....

--Richard

---

From: Warren Kumari <[email-masked]>
Date: Fri, 3 May 2013 12:39:24 -0400

On May 3, 2013, at 8:15 AM, Leif Johansson <[email-masked]> wrote:

>> Putting per user data in the DNS is a lousy approach, it has never been a succes because the DNS administrators are typically network admins and they are a separate class to DNS admins.

Using webfinger, but requiring that you get there with DANE ties you to *both* -- if that good or not is left as an exercise to the reader :-)

W

> 
>> 
>> A better approach would be to use WebFinger/XKMS/LDAP/TBS to serve up an EE cert for the end user and to use DANE to establish a trust anchor under which the EE cert is issued.
>> 
>> 
>> The amount of email that is protected by message layer security is a negligible fraction of that protected by STARTTLS. One of the main reasons for that is that the per client user model is fundamentally broken.
>> 
>> 
>> 
>> > Just a thought: It might be simpler to do S/MIME certificate discovery using WebFinger than using DANE.  You would just have to do an HTTPS query to a URI of the  form...
>> >
>> > ... then parse a JSON object to find the certificate.  As opposed to having an appropriately upgraded DNS library, being able to do DNSSEC, and parsing the binary record format.
>> 
>> That might be a good way to do certificate discovery, but not really a good way to have a second trust anchor if one wanted to get away from the distributed PKIX hierarchies.
>> 
>> There are plenty of ways to do certificate discovery. The question is how to be sure that the certificate you get is one you want to use.
>> 
>> > This process could still benefit from DANE, via TLSA validation on the HTTPS connection.  And basically the only documentation you would need would be to define the "certificate" relation type.
>> 

-- 
A. No
Q. Is it sensible to top-post?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 3 May 2013 20:24:03 -0400

> Then use DANE to authenticate the HTTPS server in the WebFinger

If you are going to do that you might as well just use TLS for the SMTP
transaction, it would be much stronger.

It is bad enough overloading the DNS to be a key centric PKI. The DNS is at
least a trusted infrastructure. But people who run Web servers do not make
security promises to the people who run the email server and your proposal
would make the security of their email hostage to the security of the Web
server.

Web servers have active code crawling on them. They are connected up to
network file systems. They are 50 shades of yuk from a security point of
view.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 3 May 2013 22:01:22 -0400

On Friday, May 3, 2013, Phillip Hallam-Baker wrote:

>
>
>
> On Fri, May 3, 2013 at 11:49 AM, Richard Barnes <[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>
> > wrote:
>
>> On Fri, May 3, 2013 at 8:15 AM, Leif Johansson <[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>
>> > wrote:
>>
>>> been a succes because the DNS administrators are typically network admins
>>> and they are a separate class to DNS admins.
>>>
> It is bad enough overloading the DNS to be a key centric PKI. The DNS is
> at least a trusted infrastructure. But people who run Web servers do not
> make security promises to the people who run the email server and your
> proposal would make the security of their email hostage to the security of
> the Web server.
>

I know, good thing there's nothing security-critical on the web!

</irony>