Re: [dane] S/MIME draft

On Aug 26, 2014, at 11:22 AM, Paul Wouters <paul@nohats.ca> 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? 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?
> 
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.  

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

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

> 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
> 
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane

===================================
Scott Rose
NIST
scott.rose@nist.gov
+1 301-975-8439
Google Voice: +1 571-249-3671
http://www.dnsops.gov/
===================================