Subject: [dane] FYI: New Version Notification for draft-hoffman-dane-smime-04.txt

From: Jakob Schlyter <[email-masked]>
Date: Mon, 10 Sep 2012 22:15:16 +0200

FYI, we've made a last-minute update to the DANE S/MIME draft based on the input from the list.
If the WG would like to adopt this draft (which we hope it will), we'd be happy to continue as editors.

Chairs: Will the WG meet in Atlanta?

	Jakob & Paul

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-hoffman-dane-smime-04.txt
> Date: 8 september 2012 18:13:45 CEST
> To: [email-masked]
> Cc: [email-masked]
> 
> 
> A new version of I-D, draft-hoffman-dane-smime-04.txt
> has been successfully submitted by Paul Hoffman and posted to the
> IETF repository.
> 
> Filename:	 draft-hoffman-dane-smime
> Revision:	 04
> Title:		 Using Secure DNS to Associate Certificates with Domain Names For S/MIME
> Creation date:	 2012-09-06
> WG ID:		 Individual Submission
> Number of pages: 6
> URL:             http://www.ietf.org/internet-drafts/draft-hoffman-dane-smime-04.txt
> Status:          http://datatracker.ietf.org/doc/draft-hoffman-dane-smime
> Htmlized:        http://tools.ietf.org/html/draft-hoffman-dane-smime-04
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-hoffman-dane-smime-04
> 
> Abstract:
>   This document describes how to use secure DNS to associate an S/MIME
>   user's certificate with the intended domain name, similar to the way
>   that DANE (RFC 6698) does for TLS.
> 
> 
> 
> 
> The IETF Secretariat
> 

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

---

From: James Cloos <[email-masked]>
Date: Mon, 10 Sep 2012 18:22:30 -0400

+1 on adopting.

As for the draft, do we really need a new RR?

If the content is the same as TLSA, just with a different naming scheme,
why not just use TLSA?

TLSA ought to be specified as suitable for anchoring any x.509-style
cert or cert chain in the dns.

Perhaps TLSA should have been called X509A?

A requirement to update dns software for every new use case might be an
excessive burden on the community.

Re-using TLSA for smime means that the only type of software (with
existing TLSA support) which would need updates would be DANE-specific
software like swede which would need an update anyway to generate and
verify associations on the new name.  (Smime consumers, of course, will
need an update no matter what the RR is called.)

(It certainly never occured to me that more RRs would be proposed for
associations to 509-style certs.  I envisioned a risk of another RR
for, eg, associations to OpenPGP certs, but not for other applications
of the 509-style ones.)

(That said, If the consensus here and at dnsext is for a new RR, then
I'll join that consensus.)

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 10 Sep 2012 16:09:34 -0700

> If the content is the same as TLSA, just with a different naming scheme,

Because the semantics of the record are different. The TLSA record was specifically defined for TLS.

> excessive burden on the community.

Could be, but overloading the TLSA record could have bad side-effects as well. I would rather err on the side of safety here.

--Paul Hoffman

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 10 Sep 2012 22:03:21 -0700

Before I do a detailed review of the document, I have a question about the
problem that this document is trying to solve.  I can see three different
problems that one could try and solve with this document.

1.  I have been given a certificate. That certificate contains an email
address.  I want establish that I should trust the certificate.

2.  I have been given a certificate.  I have gotten an email address from
the email message, but there is no email address in the certificate.  I want
to establish that I should trust the certificate.  Additionally, I may want
to establish that the certificate has a binding with the email address.

3.  I have an email address.  I need to a) find a certificate for the email
address (either for encryption or because the signed message did not have a
certificate in it) and b) establish that I should trust the certificate.

Given the current document, I believe that I can do problem #1.  The
population code will be able to map the email address in the certificate to
the correct DNS name and the client will be able to do the lookup using the
same process.  The DNS could have different names for different
capitalizations based on what is in the certificate.  No problems.

Problem #2 is harder.  If the email address is capitalized correctly, then I
can find the certificate, but depending on what is in the DNS record, I may
or may not be able to establish that the certificate and the email address
should be bound together.   The capitalization issue could be addressed by
the DNS populator, depending on what the local mail server does, by creating
a record for every possible capitalization if the local mail server will do
case folding.  This is not needed if the local mail server does not do case
folding of mailbox names.  For messages coming from a user, it might be
sufficient to assume that they are going to put the correct capitalization
in the email message itself if folding is not done by the mail server.  This
may not be the case if folding is done by the mail server.

Problem #3 is almost impossible.  It would require that only end-entity
certificate be listed, and this would mean that either it would be directly
trusted or one would need to have both an EE certificate and a trust anchor
listed in the DNS entry.  The capitalization issue would need to be
addressed as in the previous paragraph, but is harder given that the sender
may have never seen the mailbox name for the recipient and may be guessing
at what the string should be if the DNS namespace is not over-populated.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jakob Schlyter
> Sent: Monday, September 10, 2012 1:15 PM
> To: IETF DANE WG list
> Subject: [dane] FYI: New Version Notification for draft-hoffman-dane-
> smime-04.txt
> 
> > A new version of I-D, draft-hoffman-dane-smime-04.txt has been
> > successfully submitted by Paul Hoffman and posted to the IETF
> > repository.
> >
> > Title:		 Using Secure DNS to Associate Certificates with
Domain
> Names For S/MIME
> > Status:
http://datatracker.ietf.org/doc/draft-hoffman-dane-smime
> > Diff:
http://www.ietf.org/rfcdiff?url2=draft-hoffman-dane-smime-04
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Tony Finch <[email-masked]>
Date: Tue, 11 Sep 2012 11:28:13 +0100

Jim Schaad <[email-masked]> wrote:
>
> I have an email address.  I need to a) find a certificate for the email
> address (either for encryption or because the signed message did not
> have a certificate in it) and b) establish that I should trust the
> certificate.

I would really like to see this solved.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 11 Sep 2012 15:25:34 +0200

> at what the string should be if the DNS namespace is not over-populated.

I believe you somewhat exaggerating this problem. IMHO, the requirements you list are true but in no way a showstopper and I believe that publishing down-cased EE cert would be a very pragmatic and deployable way of doing this.

	jakob

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 11 Sep 2012 08:25:19 -0700

> I believe you somewhat exaggerating this problem. IMHO, the requirements you list are true but in no way a showstopper and I believe that publishing down-cased EE cert would be a very pragmatic and…

I think the biggest problem is the trust relationships...

DNSSEC is designed to secure communication to the owner of the domain name.  The same applies for DANE in most cases.

With SMIME, the receiving mail server (and thus the DNS infrastructure behind it) is not nearly so trusted: one point of something like SMIME is to keep Google (the mail server) from datamining the email to use against me.

Which implies that for problem #3, the solution may involve a DNSSEC signed record that includes both the SMIME certificate AND the identity of the mail account, with user's domains for the mail lookup being different from the domain (and company) handling the actual mail processing.

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 11 Sep 2012 08:30:35 -0700

> From: Jakob Schlyter [mailto:[email-masked]]
> Sent: Tuesday, September 11, 2012 6:26 AM
> To: Jim Schaad
> Cc: 'IETF DANE WG list'
> Subject: Re: [dane] FYI: New Version Notification for draft-hoffman-dane-
> smime-04.txt
> 
> > Problem #3 is almost impossible.  It would require that only
> > end-entity certificate be listed, and this would mean that either it
> > would be directly trusted or one would need to have both an EE
> > certificate and a trust anchor listed in the DNS entry.  The
> > capitalization issue would need to be addressed as in the previous
> > paragraph, but is harder given that the sender may have never seen the
> > mailbox name for the recipient and may be guessing at what the string
> should be if the DNS namespace is not over-populated.
> 
> I believe you somewhat exaggerating this problem. IMHO, the requirements
> you list are true but in no way a showstopper and I believe that
publishing
> down-cased EE cert would be a very pragmatic and deployable way of doing
> this.

This may or may not be true, however it does not address the question I
asked in the mail.  Which of the problems is this trying to solve?

Jim

---

From: Martin Pels <[email-masked]>
Date: Tue, 11 Sep 2012 19:29:26 +0200

On Tue, 11 Sep 2012 11:28:13 +0100

> I would really like to see this solved.

+1

I think this is the main problem the document should tackle.

Kind regards,
Martin

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 11 Sep 2012 21:07:45 +0200

On 11 sep 2012, at 17:30, Jim Schaad <[email-masked]> wrote:

> Which of the problems is this trying to solve?

All three.

	jakob

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 11 Sep 2012 15:02:39 -0700

>> Which of the problems is this trying to solve?

+1.

Jim knows full well the issue with case conversion (or at least he should remember it from the two times he and I have discussed it in depth over the past eight years) is not just about case conversion. All internationalization is dealt with the same way. If someone has a list of equivalences they want their LHS to be known as, it is trivial for them to populate the DNS with SMIMEA records for all of those. There is no way we would tell them what those equivalences would be, not to tell the searcher what they should be searching for.

--Paul Hoffman

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 11 Sep 2012 15:29:31 -0700

> Paul Hoffman
> Sent: Tuesday, September 11, 2012 3:03 PM
> To: IETF DANE WG list
> Jim knows full well the issue with case conversion (or at least he should
> remember it from the two times he and I have discussed it in depth over
the
> past eight years) is not just about case conversion. All
internationalization is
> dealt with the same way. If someone has a list of equivalences they want
> their LHS to be known as, it is trivial for them to populate the DNS with
> SMIMEA records for all of those. There is no way we would tell them what
> those equivalences would be, not to tell the searcher what they should be
> searching for.

I completely agree that we are not going to tell implementers what the
solution is, that is a long ways from not saying that this is a problem that
needs to be addressed by the systems that are populating the DNS.  I think
that the problem itself needs to be described and discussed.  

I am fully aware that there are systems in the United States where the case
folding does not occur when mail is delivered or when the address in an
email message is compared with the address in a certificate.  This means
that it not automatic that there is single way of solving the problem.  It
does not however mean that there is not a problem that needs to be
discussed.

Jim