Subject: [dane] Second WGLC draft-ietf-dane-smime

From: "Olafur Gudmundsson" <[email-masked]>
Date: Mon, 14 Nov 2016 00:47:44 -0500 (EST)

Dear colleagues, 
 
We did the first WGLC in July 9 
[ https://mailarchive.ietf.org/arch/msg/dane/AjUjw-EXbSt3nlEqt-bvvIacDZM ]( https://mailarchive.ietf.org/arch/msg/dane/AjUjw-EXbSt3nlEqt-bvvIacDZM )
There was some discussion but the chairs did not receive enough feedback to judge consensus. 
Editors have updated the document to reflect feedback received during the first WGLC 
[ https://mailarchive.ietf.org/arch/msg/dane/lu5PGEBkgpvJA0kHG0u-Q_o7BDk ]( https://mailarchive.ietf.org/arch/msg/dane/lu5PGEBkgpvJA0kHG0u-Q_o7BDk )

[ https://tools.ietf.org/html/draft-ietf-dane-smime-12 ]( https://tools.ietf.org/html/draft-ietf-dane-smime-12 )
We have published a document that relates to the experimental use of PGP keys with DANE  RFC7929

[ https://www.rfc-editor.org/info/rfc7929 ]( https://www.rfc-editor.org/info/rfc7929 )
[ https://mailarchive.ietf.org/arch/msg/dane/7hRc1QDlP-i__415-VylSXiwsLE ]( https://mailarchive.ietf.org/arch/msg/dane/7hRc1QDlP-i__415-VylSXiwsLE )
Many portions of this document are similar to RFC7929 - we realize that many people do not like the consensus in that document, but please do not re-open that discussion here. 
Just like RFC7929, this is an EXPERIMENTAL RFC.
This is a second WGLC where the chairs ask the following question 
Do you support the publication of this document as an EXPERIMENTAL RFC? 
This WGLC will end on 28-11-2016 at 23:59 UTC 
The document is “equivalent” to RFC7929.
Thus In the Chairs judgement:  Only serious objections that do not apply to 7929. need to be raised to prevent advancement of  this ID.  
Please state on the mailing list that you have reviewed the document and RFC7929 and given the criteria above the document is ready to be published. 
If you have concerns related to the descriptions in the ID please flag those as such. 
Olafur & Warren

---

From: Doug Montgomery <[email-masked]>
Date: Tue, 15 Nov 2016 11:28:35 -0500

I support publication as an experimental RFC.

We continue to pursue and support R&D efforts to develop SMIMEA based
approaches to enterprise email security.   Having a stable reference will
benefit those efforts.

dougm

On Mon, Nov 14, 2016 at 12:47 AM, Olafur Gudmundsson <[email-masked]> wrote:

> https://mailarchive.ietf.org/arch/msg/dane/AjUjw-EXbSt3nlEqt-bvvIacDZM
> https://mailarchive.ietf.org/arch/msg/dane/lu5PGEBkgpvJA0kHG0u-Q_o7BDk
>
> https://tools.ietf.org/html/draft-ietf-dane-smime-12
> https://www.rfc-editor.org/info/rfc7929
> https://mailarchive.ietf.org/arch/msg/dane/7hRc1QDlP-i__415-VylSXiwsLE
> Many portions of this document are similar to RFC7929 - we realize that
> many people do not like the consensus in that document, but please do not
> re-open that discussion here.
> Thus In the Chairs judgement:  Only serious objections that do not apply
> to 7929. need to be raised to prevent advancement of  this ID.
> Please state on the mailing list that you have reviewed the document and
> RFC7929 and given the criteria above the document is ready to be published.
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>
>

-- 
DougM at Work

---

From: Edward Lewis <[email-masked]>
Date: Tue, 15 Nov 2016 22:16:15 +0000

On 11/14/16, 14:47, "Olafur Gudmundsson" wrote:

>https://tools.ietf.org/html/draft-ietf-dane-smime-12[tools.ietf.org]

I've read the document and think it adequately covers the experiment.

I have one request, which is not a show stopper.  The term "rainbow table" ought to have a reference to a definition of the term.  (Or as is done for zone walking, a brief definition in-line.)  This is to stem the introduction of new terms without clear origins, which historically nags IETF documents.

(Even Wikipedia's entry for "rainbow table" has a note including a need for more precise citations. ;) )

---

From: "John Levine" <[email-masked]>
Date: 9 Nov 2016 11:32:01 -0000

This draft is still a bad idea for all the reasons I described the
last time it came around.  Nothing has changed.

If you do publish it, I'd suggest much stronger language in the first
sentence of section 9 on security considerations.  The security model
for S/MIME certs has always been that the trust flows from the CA to
the user without involving the user's mail operator.  Now the domain
is the trust source for all of its users.  Sometimes that's
reasonable, sometimes not, and there's no way you can tell without
knowing information about the domain that's not in the DNS.

The fifth paragraph, on mail operator MITM attacks on user mail, is
also much too weak.  If the domain is a bank that is required by law
to archive its employee communications, MITM is reasonable.  If it's a
public mail operator that uses MITM to compile dossiers of user info
to sell to marketers, and to edit ads and web bugs into the messages
into mail before re-encrypting them, all without user permission, it's
not.  If the mail is from another user on the same system, it'll
re-sign the mail, too.  Of course, the mail operator will assure you
it's "required to be able to read everyone's encrypted email" by its
business plan.

R's,
John

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 17 Nov 2016 17:28:46 +0900

John, 

Thank you for your input 
we will take your textual suggestion under advisement, 

Thanks 
Olafur 

> On Nov 9, 2016, at 8:32 PM, John Levine <[email-masked]> wrote:
>

---

From: Paul Wouters <[email-masked]>
Date: Thu, 17 Nov 2016 04:10:08 -0500 (EST)

> knowing information about the domain that's not in the DNS.

The document states:

    Given that the DNS administrator for a domain name is
    authorized to give identifying information about the zone, it makes
    sense to allow that administrator to also make an authoritative
    binding between email messages purporting to come from the domain
    name and a certificate that might be used by someone authorized to
    send mail from those servers.

If you use gmail.com, you are at the mercy of google - whether encrypted
or not. those users have already given control away to google. This
document is not the right place to warn them about that.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Thu, 17 Nov 2016 04:19:24 -0500 (EST)

> Do you support the publication of this document as an EXPERIMENTAL RFC? 

A few minor changes:

Section 3 uses an unnumbered list but the content of one bullet point
refers to "step 2". I recommend changing this to a numbered list as in
RFC7929.

Additionally, this "step 2" should be "step 5", as filed with the
RFC7929 errata: https://www.rfc-editor.org/errata_search.php?rfc=7929

(the second errata is already applied to this document)

Section 10 needs to be updated to refer to RFC7929 :)

I am in favour of publishing this document as an Experimental RFC.

Paul

---

From: "John Levine" <[email-masked]>
Date: 9 Nov 2016 16:07:54 -0000

>document is not the right place to warn them about that.

As it stands now, your first sentence is just wrong.  Currently, if I
publish a S/MIME certificate for my gmail address, and people encrypt
mail using it, Google can't read my mail.  They can throw it away of
course, but if it shows up in my mailbox, only I can read it.  In the
other direction, only I can sign mail with my cert, and Google can't
pretend to be me in an S/MIME context.  This assumes that CAs that
sign S/MIME certs are competent enough to check that it's me asking
them to sign, which I realize is kind of optimistic, but what I've
laid out is the way that S/MIME is supposed to work.

This document flips that situation around so now gmail can publish
MITM certs for all its users whether they like it or not.  That is a
big change.

R's,
John

---

From: "Garfinkel, Simson L. (Fed)" <[email-masked]>
Date: Thu, 17 Nov 2016 14:11:48 +0000

John,

Thanks for your comment.  It’s an important concern that you have raised.

In your scenario below, you write “if I publish a S/MIME certificate…”

Can you tell me how you would publish that S/MIME certificate, how people would find it, and why it would be believed?

The document essentially delegates the creation of S/MIME certs to the domain holders. If your domain holder is the kind of domain holder that would engage in an easy-detectable MITM attack such as you describe below, then why are you using them as your email provider?

I’m sure I’m missing something here…  It’s clear that distributing public key certificates is a fundamental problem with the PKI concept. How would solve it such that individuals could obtain certificates for people with whom they have had no previous contact?

Regards,

Simson 

> On Nov 9, 2016, at 11:07 AM, John Levine <[email-masked]> wrote:
>

---

From: "John R Levine" <[email-masked]>
Date: 18 Nov 2016 09:07:01 +0900

> Can you tell me how you would publish that S/MIME certificate, how people would find it, and why it would be believed?

The reason they'd belive it is that it's signed by a credible CA.  That's 
just PKI.

As far as how people would find it, there's a bunch of possibilities. 
The federal government has a public federated LDAP system that apparently 
works pretty well for people to find certs of government employees. 
Brian Haberman and I have a draft at draft-bhjl-x509-srv-02, and even this 
hack could do it (give or take the naming and scaling problems) if it 
published regular signed certificates rather than asserting that DNSSEC 
makes them trustworthy.

> If your domain holder is the kind of domain holder that 
> would engage in an easy-detectable MITM attack such as you describe 
> below, then why are you using them as your email provider?

Maybe you've had the same address for 20 years and don't want to change 
it.  Maybe your provider is someone like gmail who is mostly trustworthy 
but you don't know what secret subpoenas they've gotten so you're not 
going to use a cert they provide.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Jim Reid <[email-masked]>
Date: Fri, 18 Nov 2016 00:33:01 +0000

> On 17 Nov 2016, at 09:19, Paul Wouters <[email-masked]> wrote:
> 

I support publication of this document too: don't care which flavour of RFC is chosen for it.

---

From: tjw ietf <[email-masked]>
Date: Mon, 21 Nov 2016 02:08:24 -0500

I've read this document and I support publication.

I'm more inclined to publish as Experimental, but I'm not beholden to the
correct flavor.

tim

---

From: "Garfinkel, Simson L. (Fed)" <[email-masked]>
Date: Mon, 21 Nov 2016 14:33:45 +0000

Previously on this list I wrote this to a poster:

On Nov 17, 2016, at 9:11 AM, Garfinkel, Simson L. (Fed) <[email-masked]<mailto:[email-masked]>> wrote:

  It’s clear that distributing public key certificates is a fundamental problem with the PKI concept. How would solve it such that individuals could obtain certificates for people with whom they have had no previous contact?

To summarize the answer I received, there was concern that some email users might be using a legacy email account, not trust their mail provider, and want the assurance of a end-to-end encryption that is asserted by a trustworthy CA.

I’ve thought about this response over the weekend and do not find it credible. This answer presupposes a CA system that is not the one that we have. Most CA S/MIME providers authenticate users based on their ability to receive email at a given address.  So a hostile email provider intent on intercepting encrypted email could easily spoof even a trusted CA provider into issuing a bogus certificate.

I am also concerned about the broad number of CAs that are trusted under the current model. DANE allows the scoping of CA trust. It allows an email provider to say “we only trust this specific CA to issue a certificate, because that’s the CA that we use in our organization.”  With a CA-based system that does not use DANE, there is no mechanism for individuals to signal to people with whom they have had no previous contact that a specific CA is in use and another CA is not to be trusted.

Given this, I support publication as an experimental RFC.

We continue to pursue and support R&D efforts to develop SMIME-based approaches to enterprise email security.   Having a stable reference will benefit those efforts.

Simson Garfinkel

===================
Simson Garfinkel
Information Access Division
National Institute of Standards and Technology
[email-masked]<mailto:[email-masked]>
202-649-0029

On Nov 21, 2016, at 2:08 AM, tjw ietf <[email-masked]<mailto:[email-masked]>> wrote:

I'm more inclined to publish as Experimental, but I'm not beholden to the correct flavor.

tim

On Thu, Nov 17, 2016 at 7:33 PM, Jim Reid <[email-masked]<mailto:[email-masked]>> wrote:

> On 17 Nov 2016, at 09:19, Paul Wouters <[email-masked]<mailto:[email-masked]>> wrote:
>

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

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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 21 Nov 2016 14:49:08 +0000

Hiya,

I'm just curious...

On 21/11/16 14:33, Garfinkel, Simson L. (Fed) wrote:
> We continue to pursue and support R&D efforts to develop SMIME-based
> approaches to enterprise email security.   Having a stable reference
> will benefit those efforts.

Is there a particular reason to try focus on enterprises
here? I know that's where we started out with smime but
I'm not sure it's a useful target these days. Wouldn't it
be more likely more effective if we (for some "we") tried
to get the largest mail providers to provide some form(s)
of interoperable e2e email security? If that happened, (*)
then I suspect many more enterprises would just re-use that
than would ever deploy something by/for themselves. And if
we don't end up with e2e email security at the major mail
providers, then it'll probably not happen within many
enterprises either. (IOW, maybe the focus on enterprises
as a target for e2e mail security is a bit 20-th century? :-)

(*) Yes, there are a bunch of reasons why this is not
at all likely to happen. However, if we direct our efforts
elsewhere that is one more nail in that coffin.

Cheers,
S.

PS: I've nothing against the planned experiment here.

---

From: "John Levine" <[email-masked]>
Date: 21 Nov 2016 14:58:03 -0000

Hi, Simson.

>To summarize the answer I received, there was concern that some email users might be using a legacy email account, not trust
>their mail provider, and want the assurance of a end-to-end encryption that is asserted by a trustworthy CA.

That's not really what I said.  If you're going to quote me, please quote me.

>I’ve thought about this response over the weekend and do not find it credible. This answer presupposes a CA system that is
>not the one that we have. Most CA S/MIME providers authenticate users based on their ability to receive email at a given
>address.  So a hostile email provider intent on intercepting encrypted email could easily spoof even a trusted CA provider
>into issuing a bogus certificate.

I certainly wouldn't disagree that the current public CA system is
screwed up.  On the other hand, there are non-public or semi-public
CAs that seem to work OK, like the DOD's.  This is throwing out the
baby with the bathwater.

But in any event, to return to my original objection, it seems quite
clear that the assumption in this document is that domains are
authorities for the identities of their users.  It should say that in
so many words rather than dancing around it.  

R's,
John

---

From: "Garfinkel, Simson L. (Fed)" <[email-masked]>
Date: Mon, 21 Nov 2016 15:07:11 +0000

Hi John.

I didn’t mean to misrepresent what you said. I was simply trying to simplify the argument.  I’m sorry if I got it wrong. How would you rephrase it?

Both the DOD and the USG Civilian CA hierarchies work pretty well. Apple’s works exceptionally well, but for reasons that aren’t clear to me, they don’t make it easy for non-Apple users to obtain Apple end-user certificates. I think that DANE, and in particular SMIMEA, promises to be a much better mechanism for distributing these certificates than LDAP has proven to be.

I am in agreement with you that the document assumes that domains are the authorities of the identities of their users. I concur that the document should explicitly state this. Email addresses have become an identifier that is in many ways superior to other identifiers, such as SSNs and Driver License #s, because they can be proved by an individual’s ability to receive email at a specific address. For the same reason, mobile telephone numbers are also quickly becoming persistent identifiers.  Email addresses have an advantage over mobile telephone numbers in that there are more of them and they are easily changed as necessary.

Would you support advancing the draft it is explicitly stated this assumption?

Simson

> On Nov 21, 2016, at 9:58 AM, John Levine <[email-masked]> wrote:
> 
> Hi, Simson.
>

---

From: "John R Levine" <[email-masked]>
Date: 21 Nov 2016 11:17:16 -0500

> I didn’t mean to misrepresent what you said. I was simply trying to 
> simplify the argument.  I’m sorry if I got it wrong. How would you 
> rephrase it?

There's all sorts of reasons you wouldn't want your mail provider to read 
your mail.  As I said in an example, Gmail is mostly reliable but we don't 
know what secret subpoenas they might get.

> Would you support advancing the draft it is explicitly stated this assumption?

No.  It has other fatal flaws, discussed at length in the past. Better key 
distribution is a fine idea, but this isn't the way to do it.

Regards,

---

From: "Garfinkel, Simson L. (Fed)" <[email-masked]>
Date: Mon, 21 Nov 2016 16:31:49 +0000

John,

Thanks for the clarification.

So are you opposed to DANE in general, or just the use of DANE for email?

Given this opposition, are you opposed to the experimental RFC 7929?  Or is your opposition limited to SMIMEA?

Simson

> On Nov 21, 2016, at 11:17 AM, John R Levine <[email-masked]> wrote:
> 
> There's all sorts of reasons you wouldn't want your mail provider to read your mail.  As I said in an example, Gmail is mostly reliable but we don't know what secret subpoenas they might get.
> 
> No.  It has other fatal flaws, discussed at length in the past. Better key distribution is a fine idea, but this isn't the way to do it.
> 
> Regards,

---

From: "John R Levine" <[email-masked]>
Date: 21 Nov 2016 11:35:48 -0500

> So are you opposed to DANE in general, or just the use of DANE for email?

I expect that the rest of the DANE group is not eager to have these issues 
hashed over again, so please read the extensive discussions in the 
archives.

DANE for host certs is fine.  DANE for e-mail addresses has multiple 
problems.

> Given this opposition, are you opposed to the experimental RFC 7929?  Or is your opposition limited to SMIMEA?

Again, please read the archives.

R's,
John

---

From: Matt Miller <[email-masked]>
Date: Mon, 21 Nov 2016 09:55:08 -0700

As an experiment, I think this document is fine to move forward with.

One minor point, though.  In Section 9. "Security Considerations", third
paragraph, it states in part:

"""
   The MTA must deliver the message as-is, or encrypt the message before
   delivering.
"""

That reads as contradictory, and given the nature of this document, I
suspect that the "must" is supposed to be a "might" or "should".

- m&m

Matt Miller
Cisco Systems, Inc.

On Mon, Nov 14, 2016 at 12:47 AM, Olafur Gudmundsson <[email-masked]
<mailto:[email-masked]>> wrote:
>     <https://mailarchive.ietf.org/arch/msg/dane/AjUjw-EXbSt3nlEqt-bvvIacDZM>
>     <https://mailarchive.ietf.org/arch/msg/dane/lu5PGEBkgpvJA0kHG0u-Q_o7BDk>
> 
>     <https://tools.ietf.org/html/draft-ietf-dane-smime-12>
> 
>     <https://www.rfc-editor.org/info/rfc7929>
> 
>     <https://mailarchive.ietf.org/arch/msg/dane/7hRc1QDlP-i__415-VylSXiwsLE>
>     Many portions of this document are similar to RFC7929 - we realize
>     that many people do not like the consensus in that document, but
>     please do not re-open that discussion here.
>     Thus In the Chairs judgement:  Only serious objections that do not
>     apply to 7929. need to be raised to prevent advancement of  this ID.  
>     Please state on the mailing list that you have reviewed the document
>     and RFC7929 and given the criteria above the document is ready to be
>     published. 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/dane>
> 
> 
> 
> 
> -- 
> DougM at Work
> 
>

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 22 Nov 2016 07:49:01 +0000

Stephen Farrell <[email-masked]> writes:

>Is there a particular reason to try focus on enterprises here?

That's about the only environment where it's feasible to deploy S/MIME.

That's not intended as a snarky reply, it's serious.  You set up an S/MIME
gateway to deal with it, and all of the tech issues are handled by the
sysadmins without the users having to get involved.

The protocol for user-level email encryption is called STARTTLS.

Peter.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 22 Nov 2016 10:04:28 +0000

> That's about the only environment where it's feasible to deploy S/MIME.

Sure. And yet smime is only deployed in a tiny fraction
of enterprises and probably only used in a smallish
fraction of the mail sent in those.

> The protocol for user-level email encryption is called STARTTLS.

Today, yes. One might argue to just give up on e2e email
security, but as long as we're still willing to tilt at
that windmill (and I am;-) then it's not at all clear to
me that a focus on enterprise deployments is a sensible
target. It was a sensible target (that we missed) 20 years
ago, but not today.

Cheers,
S.

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 22 Nov 2016 07:52:32 -0800

> fraction of the mail sent in those.

How do you measure that? And, more importantly, why is it relevant to 
the DANE WG? If some other effort creates a usable e2e mail encryption 
system, they keying might be able to be DANEized at that point.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 22 Nov 2016 16:23:22 +0000

On 22/11/16 15:52, Paul Hoffman wrote:
> How do you measure that? 

I've not. But I suspect it's roughly accurate. Data
would be good if someone has any.

> And, more importantly, why is it relevant to
> the DANE WG? 

It's not directly relevant for this document nor for
any current dane document, hence my changing the subject
line when asking Simson about his statement that that was
their main interest in this experiment.

> If some other effort creates a usable e2e mail encryption

Sure. But I'm only asking about why they (NIST I guess)
think a focus on enterprise uses of smime is a good
target, I wasn't suggesting any particular action.

S.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 24 Nov 2016 06:17:28 -0500

Reminder the WGLC ends on the 28’th.
We have had civil discussion on this potentially explosive topic and I want to thank all for that. 

thanks
Olafur

> Begin forwarded message:
> 
> From: "Olafur Gudmundsson" <[email-masked]>
> Subject: [dane] Second WGLC draft-ietf-dane-smime
> Date: November 14, 2016 at 12:47:44 AM EST
> To: "Dane WG" <[email-masked]>
> 
> Dear colleagues, 
>  
> https://mailarchive.ietf.org/arch/msg/dane/AjUjw-EXbSt3nlEqt-bvvIacDZM <https://mailarchive.ietf.org/arch/msg/dane/AjUjw-EXbSt3nlEqt-bvvIacDZM>
> https://mailarchive.ietf.org/arch/msg/dane/lu5PGEBkgpvJA0kHG0u-Q_o7BDk <https://mailarchive.ietf.org/arch/msg/dane/lu5PGEBkgpvJA0kHG0u-Q_o7BDk>
> https://tools.ietf.org/html/draft-ietf-dane-smime-12 <https://tools.ietf.org/html/draft-ietf-dane-smime-12>
> 
> https://www.rfc-editor.org/info/rfc7929 <https://www.rfc-editor.org/info/rfc7929>
> 
> https://mailarchive.ietf.org/arch/msg/dane/7hRc1QDlP-i__415-VylSXiwsLE <https://mailarchive.ietf.org/arch/msg/dane/7hRc1QDlP-i__415-VylSXiwsLE>

---

From: Shumon Huque <[email-masked]>
Date: Thu, 24 Nov 2016 10:31:48 -0500

I have read this document and support its publication as an experimental
RFC.

Shumon Huque

On Thu, Nov 24, 2016 at 6:17 AM, Olafur Gudmundsson <[email-masked]> wrote:

> *From: *"Olafur Gudmundsson" <[email-masked]>
> *Subject: **[dane] Second WGLC draft-ietf-dane-smime*
> *Date: *November 14, 2016 at 12:47:44 AM EST
> *To: *"Dane WG" <[email-masked]>
>
> Dear colleagues,
>
>

---

From: "Garfinkel, Simson L. (Fed)" <[email-masked]>
Date: Sun, 27 Nov 2016 15:57:06 +0000

I would like to express my full support for the DRAFT-IETF-DANE-SMIME document to advance and become an experimental RFC.

There are several organizations using S/MIME, and it would be useful for them to explore the use of this technology as a certification distribution tool. Having this document as an experimental RFC, rather than as a draft, would help this process.

NIST recently published a Special Publication on trustworthy email (SP 800-177), and it would have been useful to quote an official IETF document regarding the use of DANE for S/MIME.  Publishing DRAFT-IETF-DANE-SMIME as an experimental RFC will enable discussion of the technology by having a firm document that we are all quoting from.

As an experimental RFC, there will be no obligation for others to implement this technology.

Also, given that the RFC 7929, “ DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP,” has been published, not publishing this RFC would seem to imply that the DANE WG is preferring OpenPGP over S/MIME.  I think that it would be misleading and not useful to give that impression.

Simson Garfinkel

---

From: [email-masked] (Martin Rex)
Date: Mon, 28 Nov 2016 13:48:23 +0100 (CET)

Stephen Farrell wrote:
> Peter Gutmann wrote:

I don't think that there exists an implementation of S/MIME that
can be reasonably deployed _anywhere_.

S/MIME defines PDUs and PDU semantics.  Those specs are OK for basic
interop.  The problem isn't with S/MIME itself, but with how S/MIME
typically involves PKIX for certificates and certificate chains and
the private key associated with your own cert.

What I'm seeing in S/MIME implementations is that S/MIME signatures
in archived EMails typically start failing within a year after archival.
I have a number of archived EMails from failed attempts to use S/MIME
in the enterprise, and they all fail signature validation today, although
there was no data corruption, and none of the signer certs have been revoked.

In addition, there are a small number of messages that I can no longer open,
because renewal/replacement of my user's private key & cert was
"managed" in the enterprise setting, and the old/expired PKI credentials
weren't kept around by that foolish "enterprise solution".

Personally, I'm not aware of an S/MIME solution that works reasonably
with archived S/MIME-protected EMails.

-Martin

---

From: "Garfinkel, Simson L. (Fed)" <[email-masked]>
Date: Mon, 28 Nov 2016 13:54:55 +0000

Hi Martin,

Thanks for your email.

I’ve been using S/MIME within the US Government since 2006. We have an integrated PKI that’s based on hardware tokens. The experience is generally good. However, I do agree with you that there are persistent problems with verifying old signatures and decrypting old messages.  For these reasons, NIST SP800-177 recommends that email clients re-encrypt messages, rather than leaving them encrypted for the original recipient. It’s also advisable for email clients to indicate if the signature was valid when received and retain this information somewhere, in addition to knowing if it is still valid.

As an aside, this is not a problem specific to S/MIME — it’s a problem with any document-based encryption system. It impacts PGP, for example: I have old PGP-encrypted messages that I cannot decrypt because the keys were not properly migrated.

Apple’s S/MIME implementation does a good job resolving some of these issues. For example, the S/MIME client (Mail.app) allows the user specify if the full-text of encrypted messages should be indexed. This presents a security vulnerability, since the message context and subject matter can be reconstructed from the index.  However, if the index is stored on an encrypted media (and it should be), the risk is decreased. That’s why SP800-177 recommends that the mail store reside in a file system that is cryptographically protected.

I should add that I also have 10+ year’s experience with soft certificates. Here the experience with the Apple implementation is better. Apple retains all old certificates and private keys in the user’s keychain, and that is replicated to all devices. So I am able to access old encrypted messages that were encrypted to my soft certificate.

Simson

> On Nov 28, 2016, at 7:48 AM, Martin Rex <[email-masked]> wrote:
> 
> Stephen Farrell wrote:
>> 
>> Peter Gutmann wrote:
>>>

---

From: "Garfinkel, Simson L. (Fed)" <[email-masked]>
Date: Tue, 29 Nov 2016 14:14:43 +0000

Hi Stephen,

Thanks for your email.  Much of the DANE-related work that I’ve been doing at NIST is focused on the enterprise of the US Government. However you are correct, the DANE protocols could also be used for enable interoperable e2e email security for consumers. Thanks for the reminder.

> On Nov 21, 2016, at 9:49 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 
> I'm just curious...
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 29 Nov 2016 23:35:01 +0000

On Tue, Nov 29, 2016 at 02:14:43PM +0000, Garfinkel, Simson L. (Fed) wrote:

> Thanks for your email.  Much of the DANE-related work that I�ve been doing
> at NIST is focused on the enterprise of the US Government. However you
> are correct, the DANE protocols could also be used for enable interoperable
> e2e email security for consumers. Thanks for the reminder.

It would be nice to see a few "real" .gov domains with TLSA records
for SMTP.  At present only dnsops.gov seems to have TLSA records,
and ironically with a WoSign/StartCom certificate...

-- 
	Viktor.

    dnsops.gov. IN MX 10 monitor.dnsops.gov.
    dnsops.gov. IN MX 10 snip1v6.dnsops.gov.
    _25._tcp.monitor.dnsops.gov. IN TLSA 3 0 1 1d97435ab70152d4de428f9a24f36e80dc1d455dee183505a61be02553ff4f1c ; passed
    _25._tcp.snip1v6.dnsops.gov. IN TLSA 3 0 1 1d97435ab70152d4de428f9a24f36e80dc1d455dee183505a61be02553ff4f1c ; ?
    snip1v6.dnsops.gov. IN AAAA 2610:20:6005:100:0:0:0:203 ; Connection refused

    Subject = CN=monitor.dnsops.gov,C=US
    Issuer = CN=StartCom Class 1 DV Server CA,OU=StartCom Certification Authority,O=StartCom Ltd.,C=IL
    Inception = 2016-10-12T17:02:00Z
    Expiration = 2019-10-12T17:02:00Z
    DNS = monitor.dnsops.gov
    
    _25._tcp.monitor.dnsops.gov. IN TLSA 3 1 1 d46a41adc0402b80e5706f32bc4ad4cbe30f25a73b54c54b427378a6375e5ad5