Re: [dane] S/MIME draft

["Osterweil, Eric" <[e-mail]>]

Hey Paul,

Wow, thanks for the really quick read! :)

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

> On Tue, 26 Aug 2014, Osterweil, Eric wrote:
> 
>> 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
> 
> 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?

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
> 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?

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
> requirements on HOW to use it, instead of defining a new future protocol?

I think we feel it is the former.

> 	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.

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.

> 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 :)

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.

> If it is in public DNS, anyone can do it. If it is in private DNS, I'd
> 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