Subject: [dane] S/MIME draft

From: "Osterweil, Eric" <[email-masked]>
Date: Tue, 26 Aug 2014 14:48:38 +0000

Hey all,

Some time ago we had some discussions about draft-ietf-dane-smime, which led to 
	https://www.ietf.org/mail-archive/web/dane/current/msg06338.html
A few of us felt that it might be productive to outline a set of requirements that we foresee DANE facing in enterprises environments (w.r.t. encrypted/signed email).  To that end, we put together the draft:
	``Enterprise Requirements for Secure Email Key Management''
	http://tools.ietf.org/html/draft-osterweil-dane-ent-email-reqs-00

We certainly welcome discussion and feedback, and we're hoping that this work will help inform the and evolve draft-ietf-dane-smime.

Thanks!

Eric

---

From: Paul Wouters <[email-masked]>
Date: Tue, 26 Aug 2014 11:22:12 -0400 (EDT)

> 	http://tools.ietf.org/html/draft-osterweil-dane-ent-email-reqs-00

I'm not an smime person at all and I'm a little confused about what the
document is trying to do. It talks about "key management requirements",
and then suggests specific requirements for a "protocol"?

Which protocol? I would think this would be very much in the realm of
local policies. If something is missing in the smime-dane draft for
"enterprise deployment", does that mean the smime-dane draft itself is
incomplete? Could you send PaulH and Jakob text to ensure it can support
enterprise roll-out? If it is complete, then your document should only list the
requirements on HOW to use it, instead of defining a new future protocol?

 	REQ-16  Encryption keys MUST be discoverable separately from
            signature keys.  Possible means includes (but not limited to)
            naming conventions, sub-typing or unique RR types for each
            use

                Intuition: Not all certificates for a user may be needed
                for all circumstances.  Fetching them separately can be a
                management, a scaling, or even a security concern.

This requirement for example is impossible with the current smime-dane draft? And
sub-typing these days is frowned upon.

I'm not sure how fetching the keys for encryption and signing separately
would be a security concern? That seems a little uhm, far fetched :)
If it is in public DNS, anyone can do it. If it is in private DNS, I'd
say it is already secured?

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 26 Aug 2014 08:41:08 -0700

> 	http://tools.ietf.org/html/draft-osterweil-dane-ent-email-reqs-00

Although you are using DANE for that, the general topic is email-end-to-end. You might therefore want to instead discuss the principles on the "endymail" mailing list that Stephen Farrell just announced yesterday on the SAAG list; see below.

--Paul Hoffman

Begin forwarded message:

> From: Stephen Farrell <[email-masked]>
> Subject: [saag] new list for discussion of end-to-end email security/privacy improvements
> Date: August 25, 2014 at 11:20:41 AM PDT
> To: "[email-masked]" <[email-masked]>
> 
> 
> Hi all,
> 
> Following on from discussion in Toronto in appaswg and saag,
> and a subsequent request, we've created a mailing list for
> discussing this topic. Pete Resnick and I will initially
> manage the list. If you're interested, please subscribe.
> Once Pete and I figure there's a good enough set of folks
> subscribed we'll fire off a starter email. That usually takes
> a few days, so probably Wed-Thu this week.
> 
> The list [1] description is:
> 
> There is significant interest in improving the
> privacy-related properties of Internet mail. One focus of
> current efforts is on the per-hop (connection-based)
> protections provided by TLS. However a wide range of other
> work has a focus on end-to-end protection, at the Internet
> scale of billions of end users and perhaps millions of
> operators. Such work typically involves new forms of mail
> header or body protection, new public key management
> (compared to S/MIME or PGP), and security mechanisms more
> appropriate for mobile/web user-agents. Other
> security-relevant approaches may be discussed if needed.
> Various proposals and development efforts on this topic are
> underway outside the IETF. This mailing list provides an
> IETF venue for discussion of elements that might be commonly
> needed by such efforts and to identify work that the IETF
> could do to aid in achieving better end-to-end security
> deployed for Internet email.
> 
> Cheers,
> S.
> 
> [1] https://www.ietf.org/mailman/listinfo/endymail

---

From: "Osterweil, Eric" <[email-masked]>
Date: Tue, 26 Aug 2014 17:28:09 +0000

Hey Paul,

Wow, thanks for the really quick read! :)

On Aug 26, 2014, at 11:22 AM, Paul Wouters <[email-masked]>
 wrote:

> Which protocol?

By protocol, we were talking about the process of trying to find, verify, and use keys from DNS for email encryption and signing.

> I would think this would be very much in the realm of
> enterprise roll-out?

In the referenced email thread, we had a discussion about adding specific text, but we wound up not being able to resolve things.  As a result, we were hoping that this draft would server as a step back that provides focused intuition behind the general ideas from the previously offered specific text.  The previous suggestions are in the email archive, but this draft is intended to spark any needed discussions in order to clarify (and hopefully overcome) fundamental misunderstandings/disagreements/etc.  We're definitely open the prospect that there might be more optimal ways to update the smime-dane draft than the text that was previously suggested before.

> If it is complete, then your document should only list the

I think we feel it is the former.

> sub-typing these days is frowned upon.

RFC 5751 has support for this behavior in Section 2.5.3, so I think it's worth considering that this policy choice exists in operational deployments.  That said, I think your comment raises a very good point though because it underlies some of our motivation for writing this draft.  We think supporting existing practices is important to help bolster DANE's deployment.  I don't think we want our protocols to show up and be incompatible with existing deployments on day 1, if we can reasonably avoid it, right?  That could actually deal a much harsher blow to DANE than anything else: 
	``this thing just doesn't work at all…'' 
could be quite hard to overcome.

> would be a security concern? That seems a little uhm, far fetched :)

Maybe an organization wants to control the ability of external RPs to learn specific types of keying material, but may want/need to continue to expose other types.  That was actually an operational problem encountered after Heartbleed for some places.

> say it is already secured?

If I want to ensure that some keys are public and some are not (based on how they are used, i.e. signing or encrypting), I likely want configuration options to help me there.  That's part of the point.  Do the other two points (management and scaling) make more sense than this one?  Is it primarily the ``security concern'' statement that seems untenable?

Eric

---

From: "Rose, Scott" <[email-masked]>
Date: Tue, 26 Aug 2014 17:50:30 +0000

> requirements on HOW to use it, instead of defining a new future protocol?
Noted - the requirements are for capabilities, so maybe "protocol" is a bad choice of words.  This draft is to start to flesh out requirements and get the discussion going with the goal to improve the SMIMEA draft, or other drafts.  

> sub-typing these days is frowned upon.

Just listing the options, even bad ones. :)  The main reason for being able to differentiate between signing and encrypting keys is the size issue, but also reduce the risk of a client encrypting an email with a receiver's signing key by mistake.  Enterprises may have the encrypting key stored at the receiving MTA, but not the signing key.

Scott

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

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

---

From: Paul Wouters <[email-masked]>
Date: Tue, 26 Aug 2014 14:45:38 -0400 (EDT)

> Noted - the requirements are for capabilities, so maybe "protocol" is a bad choice of words.  This draft is to start to flesh out requirements and get the discussion going with the goal to improve…

So it is an smime-dane-usage draft? Similar to:

http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-usage-00

I'm not sure if this new document and that one should be merged or not.
There will be similar concerns but also very different concerns.

Paul

---

From: "Rose, Scott" <[email-masked]>
Date: Tue, 26 Aug 2014 19:25:44 +0000

> There will be similar concerns but also very different concerns.

Possibly, but it would require some work.  Or else there would be a SMIMEA and SMIMEA-usage documents as the result.  In effect, a mirror of the OPENPGPKEY and its usage document pair.  

Scott

---

From: "Osterweil, Eric" <[email-masked]>
Date: Tue, 26 Aug 2014 21:03:12 +0000

> Although you are using DANE for that, the general topic is email-end-to-end. You might therefore want to instead discuss the principles on the "endymail" mailing list that Stephen Farrell just anno…

In addition to anywhere else that this topic resonates, I would say it's important to couple this work with the S/MIME draft here in DANE.  That was the impetus for writing it.

Eric