Subject: [dane] Proposed DMARC component to signal SMIME policy

From: Scott Rose <[email-masked]>
Date: Tue, 22 Oct 2013 13:56:25 -0400

A few of us here at NIST have a proposal to float by the group:

We submitted an Internet-Draft on using a new DNS RRType to signal that all email coming from the domain will be signed (proposed type is called SMIMELOCK).  So that when a client receives an email that lacks a SMIME signature from a domain with the SMIMELOCK RR, it could be marked as suspect.  The draft is at:
https://datatracker.ietf.org/doc/draft-srose-smimelock/

However, we got to thinking that it might be better to include this as part of the DMARC RDATA instead of a new RRType.  Basically, the new component could be:

dmarc-smime = "smime" *WSP "=" *WSP
	("all" / "partial" / "none")

Where:
"all" means all email originating from this domain contains a SMIME signature
"partial" means some email originating from this domain contain a SMIME signature (used for incremental deployment as an example).
"none" means this domain does not issue SMIME certs.

Though the draft only has "all", we consider having other options for the SMIMELOCK value might be useful.  It's something that the community should decide.  As we see it, the pro of having it in the DMARC RR is that it reduces the number of queries a client needs to make, and gets it deployed quicker (no need to wait for DNS implementations to be able to understand the new RRType).  The downside of this is (we admit) that is it "mission creep" of DMARC to now look at the contents of the message (at least for a SMIME sig) instead of just the header.  

So a question to the group:  Is there enough interest to continue this idea and start a more formal write-up?   Or, as stated above, the DMARC RR is not the quite right place for a domain to make this sort of statement on SMIME use?

Scott

===================================
Scott Rose
NIST
[email-masked]
+1 301-975-8439
Google Voice: +1 571-249-3671
http://www.dnsops.gov/
===================================

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 22 Oct 2013 18:21:33 +0000

On Tue, Oct 22, 2013 at 01:56:25PM -0400, Scott Rose wrote:

> We submitted an Internet-Draft on using a new DNS RRType to signal
> that all email coming from the domain will be signed (proposed type
> is called SMIMELOCK).  So that when a client receives an email that
> lacks a SMIME signature from a domain with the SMIMELOCK RR, it
> could be marked as suspect.  The draft is at:

Since the intended target of this record is the MUA,  how do you
propose to deal with "saved" email (that is email that did not
"just arrive")?  What happens when a message is first retrieved by
the MUA from an IMAP server long after it is delivered to the
mailbox?

Does the policy apply to the:

    - Envelope sender domain?

    - RFC2822.From domain?

    - RFC2822.Sender domain?

    - DKIM signer domain?

What is the interaction with "Resent-From" and/or "Resent-Sender"?

What is the treatment of mail sent to a public list (and modified
by the list adding a footer, ...)?

I think the value of this effort will be marginal at best. There
are I think too many corner cases to make the "all" value practically
reliable.  There's not much point in "partial" or "none".

Problem areas:

  Outsourced email marketing,
  Outsourced Benefits providers,
  Public mailing lists,
  Resent mail,
  Stored mail,
  ...

-- 
	Viktor.

---

From: Lutz Donnerhacke <[email-masked]>
Date: Wed, 23 Oct 2013 10:23:43 +0200

> reliable.  There's not much point in "partial" or "none".

Yep. Let me add different cryptographic systems to this list. How about
OpenPGP messages? How about Mixmaster or any other system which might become
relevant in the future?

---

From: Scott Rose <[email-masked]>
Date: Wed, 23 Oct 2013 14:31:47 -0400

> by the list adding a footer, ...)?

Admittedly we're still working on it.  I envision it mostly being used for domains that do transactional email, where one person sends it.  It would only be used on receipt of mail, so no check should be done on saved mail.  

The policy would apply (most likely) to the RFC2822 From domain, since that is the entity likely to be the one vouching for the message by the signature.  

> reliable.  There's not much point in "partial" or "none".

"Partial" is only useful in advertising a interim state before going to "all".  "none" doesn't mean much, but could be interpreted as the domain does not issue mail certs, so any signatures seen are from certs issued someone else (not the domain holder).  How the MUA interprets that is local policy.

> Outsourced Benefits providers,

Admittedly, outsourced marketing is a problem.  The main driver is entities (mostly governments, but others as well) are looking for a way to signal that all outgoing mail from a given domain will be signed.  G2G and G2C are our main targets. 

Scott

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

---

From: Scott Rose <[email-masked]>
Date: Wed, 23 Oct 2013 15:20:40 -0400

> OpenPGP messages? How about Mixmaster or any other system which might become

Definitely not objectionable.  Perhaps instead of "smime="  changed to "signed=" ?  That makes it technology neutral.  

Scott