Re: [plasma] draft-freeman-plasma-requirements-08

[Trevor Freeman <[e-mail]>]

Hi Carl

Thanks for taking time to review the draft

This is great feedback and I am sure it will help improve the document

I plan to get these changes in by the end of the month.

Thanks again
Trevor

Sent from my Windows Phone
________________________________
From: Carl Wallace<mailto:[e-mail]>
Sent: ‎11/‎21/‎2013 16:41
To: [e-mail]<mailto:[e-mail]>
Subject: [plasma] draft-freeman-plasma-requirements-08

After IETF 88 I read this document for this first time.  Below are some
comments.

General

- The document is too long.  The use cases seem unnecessary to support the
primary (?) motivation - i.e., ESS security labels don't work as desired.

- Should state early in the document whether or not use of S/MIME (i.e.,
CMS) is a requirement or if the aim is to do something different (first
bullet in 5.2 asserts backwards compatibility but is pretty far into the
document and section 5.2 is a bit fuzzy).

- For a document that asserts an email focus up front, there is too much
focus on SAML/XACML concepts.  An email focus for the document might be to
reference a new recipient info type that points to a key server (and maybe
a signed attribute for instructions to key server too).  While the
document sets the table with ESS labels as the objection, it seems like
the real objection is premature release of CEKs relative to access control
decisions (which doesn't necessarily have anything to do with labels).
With a different orientation, most of the work would then be in the
definition of the key server interface (including formats, like a
RecipientInfo lockbox) and key server operations, where the SAML/XACML
material would probably fit more naturally.

Comments
- The vocabulary section seems misplaced on a first read through.  It
would benefit from some text in the introductory section that alludes to
the proposed architecture, or at least describes some of the SAML/XACML
concepts that appear in the vocabulary section.
- In section 2.1, bullet 7 applies more to S/MIME than ESS security
labels.
- The last paragraph in section 2.2 would benefit from some connection to
S/MIME, i.e., describe how a S/MIME sender benefits from delegating
authentication of a recipient to a SAML attribute provider who uses
username/password for authentication.
- Why is section 2.3 necessary?
- I would break section 2 into two parts: one part would provide
background on things like SAML.  The other would catalog problems with
current mechanisms.  Sections 2.1 and 2.5 would fall in the latter part.
It's not altogether clear why the other sections are necessary in a
document generating requirements for improved email access control
mechanisms.
- Requirements should be organized around functions, perhaps: sender
generation/release of email and keys, intermediary receipt/storage/release
of email and keys, recipient acquisition of email and key, attribute
generation/aggregation/storage/release, access control policy
definition/storage/evaluation/versioning/expiry.
- The last paragraph in section 3.2.1 is not clear.  Why would Bob's use
of the same username/password attest to his identity in an email he sends
in response to a message from the bank?  Is this suggesting he
authenticates to some key server interface to obtain a new signature key
and that attests to his identity?
- Section 3.3 seems like a bit of a stretch as a requirement given Dave
could simply copy and paste mail into a new thread.
- Section 3.4.1 refers to a curious concept: "finding all instances of the
data".  How would any access control mechanism account apply policies to
data already released?  This section notes that Frank labels an email with
Project X and Company Foo's IP labels.  How would a recipient know which
label applied to which portions of the email?  This section concludes with
the idea that Grace can no longer access Program X mail.  It should
probably more simply state that she can no longer retrieve CEKs for
Program X mail from the server.  She may well have access to Program X
mail through a local copy.  Generally this section is confusing and seems
likely to render email threads very difficult to manage as multiple labels
are applied that all parties may not be able to access.  How would labels
be removed if one were to forward a message or reply to a message while
including only the part associated with one of the labels?
- In 3.4.2, where is Grace's signature generated, i.e., by Grace or by the
server?  Item (f) is difficult to parse.  Some explanation as to how one
can be required by policy to confirm compliance with policy without
knowing the specifics of the policy would be helpful.  This section
asserts a requirement to support exchange of forms that does not seem to
appear elsewhere in the document.  These sections appear to address
web-based access to a workflow more than secure email.
- Section 3.5 describes (more or less) how anyone with same attributes as
Grace can access email sent to Grace.  Is there a requirement for Frank to
be able to send email to Grace such that only Grace can access it?  What
prevents Brian from obtaining the key even if Grace is not away and did
not forward the message?
- Section 3.6 (like several other sections) asserts a requirement for
recipient's to be able to confirm the email is from a specific sender.  If
server-applied signatures are used, how does this work?  If user-applied
signatures are used doesn't this violate one of the primary aims of the
work, i.e., to support users who do not possess an S/MIME credential?
- How do you permit the mail server from leaking attributes to a sender
via failure notices?  For example, Alice sends various test messages to
Bob under different policies to determine which attributes are associated
with him.
- In section 3.8, should inbound inspection also search for leakage to
unauthorized parties?
- Is there a requirement to enable a sender to be able to express a
specific version of a policy be used at enforcement time (vs some later
version)?
- Is there a requirement for communications partners to be able to
contribute attributes to others?  For example, Alice may associate some
attribute with Frank to allow him to participate in some exchange.
- Section 5.2 seems to reference the "basic policy" concept in conflicting
ways, i.e., as backwards compatible with current S/MIME practices and to
accomodate users with no certificate.

Some additional security considerations:
- Use of an authentication mechanism that can be reset via control of an
email account is problematic in support of an email access control tool.
- Granting access to different portions of an email message is similarly
weak as ESS labels given there is no cryptographic separation between
different groups of users accessing a single message.
- Is there any need to provide an indication that a key has already been
released to Bob or someone purporting to be Bob in the past?  For example,
in section 3.2.1.
- Need to discuss migration from one algorithm to another in the event an
algorithm is deemed no longer suitable.  What's the lifetime of
documents/keys held by a plasma server?

Some additional privacy considerations
- Moving the decryption capability to servers enables "pervasive
monitoring" in ways that end-to-end encryption does not.  Some discussion
of the trade off is warranted (including perhaps how it is not a
significant change due to escrow of encryption keys in current practice).
- Downloading keys allows for automated read receipt generation.  Is this
desirable?

Miscellaneous
- Given the references to SAML, XACML, etc., should KEYPROV be cited as a
key format spec to use?

Nits
- In section 2, change "without certificates" to "without valid
certificates".
- In section 2.1, bullet 6, s/enforce/enforced.
- In section 2.2, s/replying party/relying party. (multiple occurrences)
- In section 2.2, s/a mean/a means.
- In section 2.2, s/by to a subjects/to a subject's. (the sentence
containing this change is pretty difficult to parse in general)
- In section 2.2.1, s/subject's themselves/subjects themselves.
- In section 3.1, should this reference Alice's ISP or her email service
provider?
- In section 3.2.1, s/recipients identity/recipient's identity
- In section 3.4.1, s/confidentiality  its own/confidentiality of its own
- In section 3.4.2, s/Franks/Frank's
- In section 3.6 bullet (4), delete " : , then encrypts the message."


_______________________________________________
plasma mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/plasma