From carl@redhoundsoftware.com Thu Nov 21 14:21:23 2013 Return-Path: X-Original-To: plasma@ietfa.amsl.com Delivered-To: plasma@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEFF1AE28A for ; Thu, 21 Nov 2013 14:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moKcaL2B_T7G for ; Thu, 21 Nov 2013 14:21:20 -0800 (PST) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) by ietfa.amsl.com (Postfix) with ESMTP id 126E61AE06D for ; Thu, 21 Nov 2013 14:21:19 -0800 (PST) Received: by mail-qc0-f175.google.com with SMTP id x20so307050qcv.6 for ; Thu, 21 Nov 2013 14:21:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version:content-type:content-transfer-encoding; bh=aYY1wX4Bmhed3RUA4A4uWXJrK8f/7FgHvc6E3/tbag8=; b=YZtZz0JNIQKJHzLgW8uA2WNI508lyDmbp/fxpI8ydNxgFbHLDq3DbrvQW8/XvAfZO7 NPvFXA9fp+G6d704SCBFeVj8U/50KBgN890Yq3M2tO28N9uDu6RDdqDsw5DHBFqtIBPN wBZTvFbDj9zZ/wtueLktUijJ38G82Xz0sYunJd7bGy8RaEfO129TbMMiY4cFk5hIrJwf 49fehCOU/XJuo7rdofScYDBrJTjvWCJFOuSENwpIH+GNN9w12ZBuUegCZXLUbZLXe+l6 ZOMRg3zRCB4o85m42EHPdMTnqk4O6ILK7e5JLg0pZK9xA6iGb2qJZpuRofU5LfNzZ7v4 WCQA== X-Gm-Message-State: ALoCoQlCEG6FTK5+ND54+kvL1b7Q69mgtgN0VIEn1tJvHR2XMWUPyJnoeR1KKumqjw6bCx+VersF X-Received: by 10.224.120.65 with SMTP id c1mr15751853qar.56.1385072472892; Thu, 21 Nov 2013 14:21:12 -0800 (PST) Received: from [192.168.2.9] (pool-173-79-121-197.washdc.fios.verizon.net. [173.79.121.197]) by mx.google.com with ESMTPSA id jw9sm73479841qeb.2.2013.11.21.14.21.11 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 21 Nov 2013 14:21:12 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Thu, 21 Nov 2013 17:21:08 -0500 From: Carl Wallace To: Message-ID: Thread-Topic: draft-freeman-plasma-requirements-08 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [plasma] draft-freeman-plasma-requirements-08 X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 22:21:23 -0000 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." From Diana.Proud-Madruga@va.gov Fri Nov 22 12:36:31 2013 Return-Path: X-Original-To: plasma@ietfa.amsl.com Delivered-To: plasma@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7BE1ADFEF for ; Fri, 22 Nov 2013 12:36:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.026 X-Spam-Level: X-Spam-Status: No, score=-6.026 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cG2-zSkJgC2q for ; Fri, 22 Nov 2013 12:36:30 -0800 (PST) Received: from gwwmta1.va.gov (gwwmta1.va.gov [152.131.26.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1824A1ACCEA for ; Fri, 22 Nov 2013 12:36:28 -0800 (PST) X-SBRS: None X-MID: 244257329 From: "Proud-Madruga, Diana L. (DRC)" To: "plasma@ietf.org" Date: Fri, 22 Nov 2013 14:35:42 -0600 Thread-Topic: plasma Digest, Vol 25, Issue 1 attachments Thread-Index: Ac7nwXom953Bc6t1TQ65vUwP0DmNaw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [plasma] plasma Digest, Vol 25, Issue 1 attachments X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 20:36:31 -0000 I am unable to read the today's topic or the Digest Footer attachments.=20 Diana Proud-Madruga, CISSP, GSEC Security Analyst Dynamic Research Corporation|High Performance Technology Group (619) 467-5568 (Office) dproud-madruga@drc.com=20 diana.proud-madruga@va.gov -----Original Message----- From: plasma [mailto:plasma-bounces@ietf.org] On Behalf Of plasma-request@i= etf.org Sent: Friday, November 22, 2013 12:00 PM To: plasma@ietf.org Subject: plasma Digest, Vol 25, Issue 1 Send plasma mailing list submissions to plasma@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/plasma or, via email, send a message with subject or body 'help' to plasma-request@ietf.org You can reach the person managing the list at plasma-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of plasma digest..." From Dave.Button@gdc4s.com Fri Nov 22 13:15:51 2013 Return-Path: X-Original-To: plasma@ietfa.amsl.com Delivered-To: plasma@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F771AE20D for ; Fri, 22 Nov 2013 13:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.876 X-Spam-Level: X-Spam-Status: No, score=0.876 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWyKGQIgoZZI for ; Fri, 22 Nov 2013 13:15:49 -0800 (PST) Received: from ma05egs03.gdc4s.com (ma05egs03.gdc4s.com [192.206.187.82]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8EA1ADFD7 for ; Fri, 22 Nov 2013 13:15:49 -0800 (PST) Received: from unknown (HELO ma05egi02.gdc4s.com) ([10.230.4.11]) by ma05egs03.gdc4s.com with ESMTP; 22 Nov 2013 16:15:41 -0500 Received: from MARC4SMSG22.rc4s.com (marc4smsg22.rc4s.com [10.232.60.35]) by ma05egi02.gdc4s.com (8.13.8/8.13.8) with ESMTP id rAMLFfu0007508 for ; Fri, 22 Nov 2013 16:15:41 -0500 Received: from MARC4SMAMSG12.rc4s.com ([169.254.3.176]) by MARC4SMSG22.rc4s.com ([10.232.60.35]) with mapi id 14.03.0158.001; Fri, 22 Nov 2013 16:15:40 -0500 From: "Button, Dave" To: "plasma@ietf.org" Thread-Index: Ac7nx/6+vv3NEPw5QZCzE2mlMnZW7w== Date: Fri, 22 Nov 2013 21:15:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.232.60.55] Content-Type: multipart/alternative; boundary="_000_B8EE0710E3EE8E47893AC06015E322229B30CEMARC4SMAMSG12rc4s_" MIME-Version: 1.0 Subject: [plasma] (no subject) X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 21:15:51 -0000 --_000_B8EE0710E3EE8E47893AC06015E322229B30CEMARC4SMAMSG12rc4s_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This message and/or attachments may include information subject to GDC4S S.= P. 1.8.6 and GD Corporate Policy 07-105 and is intended to be accessed only= by authorized recipients. Use, storage and transmission are governed by G= eneral Dynamics and its policies. Contractual restrictions apply to third = parties. Recipients should refer to the policies or contract to determine = proper handling. Unauthorized review, use, disclosure or distribution is p= rohibited. If you are not an intended recipient, please contact the sender= and destroy all copies of the original message. --_000_B8EE0710E3EE8E47893AC06015E322229B30CEMARC4SMAMSG12rc4s_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

This message and/or attachments may include informa= tion subject to GDC4S S.P. 1.8.6 and GD Corporate Policy 07-105 and is inte= nded to be accessed only by authorized recipients.  Use, storage and transmission are governed by General Dy= namics and its policies.  Contractual restrictions apply to third part= ies.  Recipients should refer to the policies or contract to determine= proper handling.  Unauthorized review, use, disclosure or distribution is prohibited.  If you are not an intended recipient,= please contact the sender and destroy all copies of the original message.

 

--_000_B8EE0710E3EE8E47893AC06015E322229B30CEMARC4SMAMSG12rc4s_-- From trevorf@exchange.microsoft.com Fri Nov 22 14:22:57 2013 Return-Path: X-Original-To: plasma@ietfa.amsl.com Delivered-To: plasma@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502F61AE1D6 for ; Fri, 22 Nov 2013 14:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqCqlXPuZtCn for ; Fri, 22 Nov 2013 14:22:53 -0800 (PST) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.92]) by ietfa.amsl.com (Postfix) with ESMTP id 649D01AE06E for ; Fri, 22 Nov 2013 14:22:52 -0800 (PST) Received: from BLUSR01CA102.namsdf01.sdf.exchangelabs.com (10.255.124.147) by BLUSR01MB590.namsdf01.sdf.exchangelabs.com (10.255.124.164) with Microsoft SMTP Server (TLS) id 15.0.837.3; Fri, 22 Nov 2013 02:33:55 +0000 Received: from BY1FFOFD003.ffo.gbl (64.4.22.87) by BLUSR01CA102.outlook.office365.com (10.255.124.147) with Microsoft SMTP Server (TLS) id 15.0.837.0 via Frontend Transport; Fri, 22 Nov 2013 02:33:55 +0000 Received: from hybrid.exchange.microsoft.com (131.107.147.100) by BY1FFOFD003.mail.o365filtering.com (10.1.16.90) with Microsoft SMTP Server (TLS) id 15.0.837.0 via Frontend Transport; Fri, 22 Nov 2013 02:33:55 +0000 Received: from DFM-TK5MBX15-07.exchange.corp.microsoft.com (157.54.109.46) by DFM-TK5EDG15-02.exchange.corp.microsoft.com (157.54.27.97) with Microsoft SMTP Server (TLS) id 15.0.842.0; Thu, 21 Nov 2013 18:33:30 -0800 Received: from DFM-TK5MBX15-05.exchange.corp.microsoft.com (157.54.109.44) by DFM-TK5MBX15-07.exchange.corp.microsoft.com (157.54.109.46) with Microsoft SMTP Server (TLS) id 15.0.775.36; Thu, 21 Nov 2013 18:33:30 -0800 Received: from DFM-TK5MBX15-05.exchange.corp.microsoft.com ([157.54.109.44]) by DFM-TK5MBX15-05.exchange.corp.microsoft.com ([169.254.5.151]) with mapi id 15.00.0775.031; Thu, 21 Nov 2013 18:33:29 -0800 From: Trevor Freeman To: Carl Wallace , "plasma@ietf.org" Thread-Topic: [plasma] draft-freeman-plasma-requirements-08 Thread-Index: AQHO5ys6LF6muY45WUW36zDxSXJrJg== Date: Fri, 22 Nov 2013 02:33:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_b229735159b74d3e97efd37e1fa88d44DFMTK5MBX1505exchangeco_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.147.100; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(52604005)(189002)(199002)(43784003)(19580395003)(80976001)(51856001)(54356001)(53806001)(74706001)(74876001)(551544002)(87936001)(74366001)(16236675003)(83072001)(69226001)(47976001)(47736001)(50986001)(84326002)(49866001)(76482001)(65816001)(56776001)(80022001)(4396001)(54316002)(71186001)(47446002)(15975445006)(74502001)(85306002)(74662001)(31966008)(76786001)(76796001)(19580405001)(83322001)(77982001)(59766001)(77096001)(56816003)(79102001)(6806004)(44976005)(20776003)(63696002)(81686001)(81342001)(2656002)(33646001)(81542001)(46102001)(87266001)(81816001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUSR01MB590; H:hybrid.exchange.microsoft.com; CLIP:131.107.147.100; FPR:; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Forefront-PRVS: 0038DE95A2 X-OriginatorOrg: exchange.microsoft.com Subject: Re: [plasma] draft-freeman-plasma-requirements-08 X-BeenThere: plasma@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The PoLicy Augmented S/Mime \(plasma\) bof discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 22:22:57 -0000 --_000_b229735159b74d3e97efd37e1fa88d44DFMTK5MBX1505exchangeco_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable 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 Sent: =FD11/=FD21/=FD2013 16:41 To: plasma@ietf.org 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 plasma@ietf.org https://www.ietf.org/mailman/listinfo/plasma --_000_b229735159b74d3e97efd37e1fa88d44DFMTK5MBX1505exchangeco_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
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
Sent: =FD11= /=FD21/=FD2013 16:41
To: plasma@ietf.org
Subject: [plas= ma] 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 b= e to
reference a new recipient info type that points to a key server (and maybe<= br> 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<= br> 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<= br> 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 par= t.
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<= br> 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 u= se
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 poli= cies 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 whi= ch
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 se= ems
likely to render email threads very difficult to manage as multiple labels<= br> are applied that all parties may not be able to access.  How would lab= els
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<= br> 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 Fran= k to
be able to send email to Grace such that only Grace can access it?  Wh= at
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-appli= ed
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 t= o
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 som= e
attribute with Frank to allow him to participate in some exchange.
- Section 5.2 seems to reference the "basic policy" concept in co= nflicting
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 exam= ple,
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 di= scussion
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 t= his
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 va= lid
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.&q= uot;


_______________________________________________
plasma mailing list
plasma@ietf.org
https://www.ietf.o= rg/mailman/listinfo/plasma
 --_000_b229735159b74d3e97efd37e1fa88d44DFMTK5MBX1505exchangeco_--