Subject: [dane] Fwd: New Version Notification for draft-osterweil-dane-ent-email-reqs-01.txt

From: "Rose, Scott" <[email-masked]>
Date: Wed, 26 Nov 2014 00:07:06 +0000

We submitted a new version of the email-reqs draft.  This version is likely not perfect, but I wanted it to appear before the US Thanksgiving holiday so people have a chance to look at it before the interim meeting.  

Text and requirements are cleaned up a bit and added example use cases for non-trivial requirements.  Also added a new section of requirements that are not really DANE relevant, but added for completeness and just to have them documented somewhere.  A new DANE type is probably not the ideal solution for all of these requirements.

Comments welcome, now or during/after the interim meeting,
Scott

Begin forwarded message:

> From: <[email-masked]>
> Subject: New Version Notification for draft-osterweil-dane-ent-email-reqs-01.txt
> Date: November 25, 2014 at 7:03:29 PM EST
> To: Scott Rose <[email-masked]>, Doug Montgomery <[email-masked]>, "Doug Montgomery" <[email-masked]>, Scott Rose <[email-masked]>
> 
> 
> A new version of I-D, draft-osterweil-dane-ent-email-reqs-01.txt
> has been successfully submitted by Scott Rose and posted to the
> IETF repository.
> 
> Name:		draft-osterweil-dane-ent-email-reqs
> Revision:	01
> Title:		Enterprise Requirements for Secure Email Key Management
> Document date:	2014-11-25
> Group:		Individual Submission
> Pages:		7
> URL:            http://www.ietf.org/internet-drafts/draft-osterweil-dane-ent-email-reqs-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-osterweil-dane-ent-email-reqs/
> Htmlized:       http://tools.ietf.org/html/draft-osterweil-dane-ent-email-reqs-01
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-osterweil-dane-ent-email-reqs-01
> 
> Abstract:
>   Individuals and organizations have expressed a wish to have the
>   ability to send encrypted and/or digitally signed email end-to-end.
>   One key obstacle to end-to-end email security is the difficulty in
>   discovering, obtaining, and validating email credentials across
>   administrative domains.  This document addresses foreseeable adoption
>   obstacles for encrypted and digitally signed email in enterprises,
>   and outlines requirements.  Some of the requirements below are not
>   DANE specific, and all may not be solvable with a DANE solution, but
>   are included for completeness and as an attempt to give a holistic
>   view of enterprise email security requirements.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 26 Nov 2014 01:04:56 +0000

> Comments welcome, now or during/after the interim meeting,

* REQ-2 seems to suggest DNAME in a context where I would generally
  expect CNAME (linking one leaf record to another).  DNAMEs would
  far more likely be used when all users have addresses in each of
  two or more equivalent domains.

* I think REQ-5 is a leap from the underlying desire of constraining
  credentials to specific uses.  It states that it must be possible
  to convey negative assertions (don't use key K for purpose P'),
  while it may be quite sufficient to use positive assertions,
  which have better security semantics (use K for purpose P), and
  anything not asserted is by definition not valid.

  Thus the requirement ought to be implementation neutral, and whether
  it is implemented in positive or negative terms is an implementation
  choice not a requirement.

* REQ-6 seems to be substantially the same as 5.

* REQ-7 is I think too concise.  What is it about?

* REQ-8 feels wrong.  It is turtles all the way down,
  the merging enterprise's applications may be using some other
  protocol.  The protocol cannot encompass all competing protocols.
  Applications may need to support multiple protocols, and perhaps
  a meta protocol (obligatory xkcd reference anyone) could be used
  to signal which one to apply to which user.  However it may simply
  be better for a new protocol to keep things simple and aim to
  displace rather than entrench legacy options.

* I don't understand REQ-10.

* Is REQ-11 confusing application implementing the protocol with the
  protocol?  If not what is it saying?

* REQ-12 is definitely an application and not a protocol requirement.

* REQ-13 seems to be reprise of REQ-5/6.

* REQ-15 feels like a derived "requirement" from some other unstated
  assumptions.  What is its real purpose?  The words "authenticated
  denial of existence" are I think unfortunate in this context,
  since they have a very specific meaning in DNSSEC, which likely
  differs from the intention here.

* I see no discussion of case sensitivity.  For example, a domain
  in which addresses are case insensitive could publish records
  (at a suitably encoded label) associated with a case-tagged email
  "address" that is not valid 5322 syntax:

	lowercase@[email-masked]

	(as distinct from "lowercase@joeuser"@example.com, and
	 I would expect the quotes in quoted localparts to be
	 part of the input to the encoded address).

  Then applications that don't find a match for the user supplied
  case could try the above variant instead, and not run into
  collisions at domains where addresses are case-sensitive, because
  such domains would not publish data for such prefixes.

  With a bit of cleverness we can handle case sensitivity without
  imposing on the freedom of the destination domain to be case
  sensitive or not.

* Should there be some discussion of EAI?  Are UTF-8 localparts
  also subject to attempts at case conversion?  Any other EAI
  issues?

-- 
	Viktor.

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 26 Nov 2014 19:30:23 +0100

>  two or more equivalent domains.

Why? The following example makes sense for aliasing:

  _smimecert.example.com. IN DNAME _smimecert.example.net. 

> * REQ-7 is I think too concise.  What is it about?

I believe something like this:

_smimecert.example.com. IN DNAME _smimecert.example.com.provider.net.

>  displace rather than entrench legacy options.

I agree. For me, this feels like optimizing for the publish side (of which there are few) instead of optimizing for the client (of which there any many). Also, this adds complexity. I can see that it would be easier for an enterprise to say *._smimecert.example.com. IN SMIMEA go-see-ldap, but if one can put one SMIMEA RR in the DNS, one can easily loop through that LDAP thing and publish all the certs. I'd like to optimize for simplicity in this case.

	jakob

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 26 Nov 2014 19:30:34 +0100

REQ-5: Please elaborate on why normal certificate keyUsage is not usable to distinguish between certificates used for encryption/signing.

	jakob

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 26 Nov 2014 18:34:06 +0000

>   _smimecert.example.com. IN DNAME _smimecert.example.net. 

I thought the text was talking about a given user, not an entire domain.

> _smimecert.example.com. IN DNAME _smimecert.example.com.provider.net.

Better text is perhaps needed to explain.

-- 
	Viktor.

---

From: "Rose, Scott" <[email-masked]>
Date: Sat, 29 Nov 2014 01:11:40 +0000

The requirement comes from the desire to tie cert/keys with functionality.  Some enterprises may get their certs issued by CA's that set both keyUsage flags, yet want two certs for different purposes. MUA's will have to decide how to handle situations when the keyUsage field does not match the usage statement in the SMIMEA RR.  It should be checked, but behavior when there are discrepancies will need to be specified.

Also, being able to specify signing and encrypting functions for raw keys may come in handy.  It also helps in the reject case, where a domain can reject one usage for a cert.  

Scott

On Nov 26, 2014, at 1:30 PM, Jakob Schlyter <[email-masked]> wrote:

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

---

From: Doug Montgomery <[email-masked]>
Date: Sat, 29 Nov 2014 00:18:30 -0500

On Tue, Nov 25, 2014 at 8:04 PM, Viktor Dukhovni <[email-masked]>
wrote:

> > We submitted a new version of the email-reqs draft.  This version is
> likely not perfect, but I wanted it to appear before the US Thanksgiving
> holiday so people have a chance to look at it before the interim meeting.
> >
> > Text and requirements are cleaned up a bit and added example use cases
> for non-trivial requirements.  Also added a new section of requirements
> that are not really DANE relevant, but added for completeness and just to
> have them documented somewhere.  A new DANE type is probably not the ideal
> solution for all of these requirements.
> >

There are two issues that need to be addressed here.

1. Some enterprise identity management systems bind encryption and signing
keys to network identities for other purposes (i.e., not specific to
email).   The requirement addressed the ability for domains to indicate
that even though you might know of such keys through other means, they are
not valid for end-to-end SMIME usage in this domain.

2. The semantics during incremental deployment, and persistent partial
deployment must be well defined.   i.e., one must be able to definitively
determine if the lack of a positive assertion is a purposeful statement of
key usage policy, or a transient condition of partial deployment.

It was not apparent to us how the absence of positive assertions could
address these requirements.

dougm
-- 
DougM at Work