Subject: [dane] I-D Action: draft-ietf-dane-smime-02.txt

From: [email-masked]
Date: Tue, 09 Jul 2013 13:27:20 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF.

	Title           : Using Secure DNS to Associate Certificates with Domain Names For S/MIME
	Author(s)       : Paul Hoffman
                          Jakob Schlyter
	Filename        : draft-ietf-dane-smime-02.txt
	Pages           : 7
	Date            : 2013-07-09

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 datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dane-smime

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dane-smime-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smime-02

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 9 Jul 2013 13:30:15 -0700

As y'all can see from the diffs, this is just a small editorial bump to keep the draft up-to-date. Jakob and I note that there was no substantial discussion of Scott Rose's message about the earlier draft (see <http://www.ietf.org/mail-archive/web/dane/current/msg05575.html>). We would love to hear more about that, particularly now that people are starting to pay more attention to DANE's use in email.

--Paul Hoffman

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 10 Jul 2013 15:17:44 +0000

On Tue, Jul 09, 2013 at 01:30:15PM -0700, Paul Hoffman wrote:

> As y'all can see from the diffs, this is just a small editorial
> bump to keep the draft up-to-date. Jakob and I note that there was
> no substantial discussion of Scott Rose's message about the earlier
> draft (see <http://www.ietf.org/mail-archive/web/dane/current/msg05575.html>).
> We would love to hear more about that, particularly now that people
> are starting to pay more attention to DANE's use in email.

Grammar nit:

    "In order for the S/MIME receiver to authenticate that a message
    is from the sender whom is identified in the message,"

I am pretty sure the sender is in the nominative case in this sentence,
and "whom" should be "who".

    http://grammar.quickanddirtytips.com/who-versus-whom.aspx

As to the substance of the draft, there is no discussion of wildcard
mechanisms.  With email user certificates, I'd expect most domains
to publish an associated TA certificate that is common to all users
(either usage 0 or 2).  I guess the draft implicitly supports this via:

	*._smimecert.example.com IN SMIMEA 2 1 1 ...

This is perhaps worth some explicit discussion.

And now that we see the dreaded "2 1 1", the same question arises
as with TLSA RRs, do SMIME senders generally include the (root) TA
certificate in the pkcs7 certificate chain pkcs7? Some guidance
for sending MUAs may be appropriate (start including root TA certs
in pkcs7 SMIME blobs, probably unconditionally).

Unlike TLS sessions, SMIME messages are not transient.  Thus an
SMIME message sent last year and verified by last year's certificate,
may need to be re-validated this year with the domain's TA or user's
EE certificate updated.  How is TA/EE certificate rollover to be
handled?

Because SMIME is not like TLS (data at rest vs. data in motion),
it is not clear that a simple analogy to TLSA (mere refinement of
the record type and query labels) is sufficient.

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 10 Jul 2013 09:23:10 -0700

> Grammar nit:

Fixed

> This is perhaps worth some explicit discussion.

Sounds fine.

> certificate in the pkcs7 certificate chain pkcs7?

"Generally" is a terrible word to use here. :-) We do not have any useful usage data on S/MIME to make an assertion one way or the other.

> Some guidance

Disagree. Unless we know what they do currently without DANE, any guidance we give could easily contradict that.

> EE certificate updated.  How is TA/EE certificate rollover to be

Indeterminately. At least we're sure of that, from discussions 15 years ago.

> the record type and query labels) is sufficient.

Having a specific list of differences would be useful for Jakob and I to determine where we need to put in more words.

--Paul Hoffman

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 10 Jul 2013 20:36:59 +0000

On Wed, Jul 10, 2013 at 09:23:10AM -0700, Paul Hoffman wrote:

> "Generally" is a terrible word to use here. :-) We do not have
> any useful usage data on S/MIME to make an assertion one way or
> the other.

There is some support for S/MIME in various mainsteam MUAs,
Microsoft's Outlook, Apple's Mail.app and Thunderbird come to mind.
It may be reasonable to check how these decide which certificates
to include in a signed message.  There are also commercial
gateway-to-gateway and gateway-to-user SMIME appliances, whose
behaviour may be useful to know.

Alternatively, the draft could simply encourage all signers to
include complete chains in their signatures, and to not "optimize
out" self-signed root issuers.

> Disagree. Unless we know what they do currently without DANE,
> any guidance we give could easily contradict that.

Well, it is likely necessary to contradict any advice to omit root
CAs, and otherwise we'd agree with the existing practice, so where's
the harm?

> Indeterminately. At least we're sure of that, from discussions 15 years ago.

That's much less of a problem with the public CA PKI, because root
CA lifetimes are so long.  With DANE TA or EE certificates, the
problem is liable to become far more acute.

If there is no mechanism to deal with retired, but valid at time
of message receipt, certificates, validating old messages becomes
a rather difficult problem.

So SMIMEA would then provide a mechanism for retrieving the current
public key for sending new encrypted messages to a recipient, and
for verifying messages at time of receipt, but would not be suitable
for later re-verification.

If there is deliberately no mechanism to publish old keys, valid
only for verifying old messages, there is an implicit burden on
the MUA to either cache the verification status of certificates
(and validity intervals) associated with received messages, or
to cache per-message verification status.

> Having a specific list of differences would be useful for Jakob
> and I to determine where we need to put in more words.

As with TLS, SMIME supports initiators (message senders) who need
the peer's current public key.  Unlike TLS SMIME also supports
arbitrarily delayed in time acceptors (message readers) who need
to be able to read an SMIME message and determine whether it was
valid at the time it was received.

Delayed sender signature verification is a rather different problem,
and if it is explicitly out of scope for SMIMEA, then perhaps it is
worth mentioning that mechanisms for this are to sought elsewhere,
unless SMIME standards already adequately cover this problem.

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 14 Jul 2013 08:01:17 -0700

> behaviour may be useful to know.

All of that can be found out, but from earlier viewing of the data, the results will be wildly different.

> out" self-signed root issuers.

It is probably inappropriate for a draft from this WG to try to affect the S/MIME protocol that has been deployed for over a decade.

> CAs, and otherwise we'd agree with the existing practice, so where's

The harm is in having two IETF standards on the same topic that disagree, particularly because an S/MIME implementer might not care in the least about DANE.

> a rather difficult problem.

Yes.

> for later re-verification.

The same is true for many other parts of S/MIME. For example, a trust anchor might have a long lifetime, but intermediate CAs might be short for very good reasons.

> to cache per-message verification status.

Yes.

> unless SMIME standards already adequately cover this problem.

Just the opposite: the S/MIME standards do not. There was some work from the LTANS WG in this area; see RFC 4810 and 4998. It has mostly been ignored, I believe.

--Paul Hoffman