From nobody Mon Jun 1 12:35:27 2015 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3E31B2FC4 for ; Mon, 1 Jun 2015 10:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, SPF_HELO_PASS=-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 J7gEb0p-jMmF for ; Mon, 1 Jun 2015 10:43:07 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0648.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::648]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C4401A8029 for ; Mon, 1 Jun 2015 10:43:07 -0700 (PDT) Received: from BY2PR06MB1831.namprd06.prod.outlook.com (25.163.33.145) by BY2PR06MB696.namprd06.prod.outlook.com (10.141.225.17) with Microsoft SMTP Server (TLS) id 15.1.172.22; Mon, 1 Jun 2015 17:42:47 +0000 Received: from BLUPR0601CA0006.namprd06.prod.outlook.com (25.163.210.16) by BY2PR06MB1831.namprd06.prod.outlook.com (25.163.33.145) with Microsoft SMTP Server (TLS) id 15.1.172.22; Mon, 1 Jun 2015 17:42:45 +0000 Received: from BY2FFO11FD048.protection.gbl (2a01:111:f400:7c0c::180) by BLUPR0601CA0006.outlook.office365.com (2a01:111:e400:5940::16) with Microsoft SMTP Server (TLS) id 15.1.172.22 via Frontend Transport; Mon, 1 Jun 2015 17:42:45 +0000 Authentication-Results: spf=pass (sender IP is 199.135.140.17) smtp.mailfrom=fs.fed.us; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of fs.fed.us designates 199.135.140.17 as permitted sender) receiver=protection.outlook.com; client-ip=199.135.140.17; helo=mail.usda.gov; Received: from mail.usda.gov (199.135.140.17) by BY2FFO11FD048.mail.protection.outlook.com (10.1.15.176) with Microsoft SMTP Server (TLS) id 15.1.172.14 via Frontend Transport; Mon, 1 Jun 2015 17:42:44 +0000 Received: from 001FSN2MPN1-046.001f.mgd2.msft.net ([169.254.6.131]) by 001FSN2MMR1-007.001f.mgd2.msft.net ([199.135.140.17]) with mapi id 14.03.0224.003; Mon, 1 Jun 2015 17:42:24 +0000 From: "Nordgren, Bryce L -FS" To: "endymail@ietf.org" Thread-Topic: Group/Enterprise encrypted email Thread-Index: AdCaU4EBKI9vXfbmSrKplnpcKmT5cgCPeK3w Date: Mon, 1 Jun 2015 17:42:23 +0000 Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E7DFBBD@001FSN2MPN1-046.001f.mgd2.msft.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.7.27.143] Content-Type: multipart/alternative; boundary="_000_82E7C9A01FD0764CACDD35D10F5DFB6E7DFBBD001FSN2MPN1046001_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD048; 1:WqW+S50+85IdziB3SqUaKK4zrch9oHe+p3i2O7zy60yMaeN0GvlRCkn9wqiYaguQ5s1JTDQcsZhzNgS+s8j1koQzG4HHiH1HwLKrZbvNeeGKg5XmannRKIPx5bnr8J4hqPJG5U6uHeuhZfQpymr63HQmie66n9/6VXJHedO3P+XjFaF8L3HrTJhCQMjvQJ2YW29Jpzae1W8ahzrBmm4haSrkja1plWY2sZG602GwLR4yOZzf0SLCY2kHOnx6Jk0nE4yvtxTeUu0PT1JlJJhfGA== X-Forefront-Antispam-Report: CIP:199.135.140.17; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(438002)(76104003)(377454003)(189002)(199003)(64706001)(19300405004)(84326002)(2920100001)(15975445007)(92566002)(66066001)(86146001)(22746005)(74482002)(68736005)(46102003)(22756005)(102836002)(2900100001)(19580395003)(69596002)(106466001)(77156002)(450100001)(62966003)(2930100002)(104016003)(5890100001)(512954002)(2501003)(26826002)(19625215002)(86362001)(50986999)(54356999)(33656002)(16236675004)(189998001)(110136002)(6806004)(5001860100001)(81156007)(107886002)(19580405001)(2656002)(87936001)(2351001)(5001830100001)(5001960100002)(97736004)(4001540100001)(55846006)(80862005)(79686002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR06MB1831; H:mail.usda.gov; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR06MB1831; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR06MB696; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:BY2PR06MB1831; BCL:0; PCL:0; RULEID:; SRVR:BY2PR06MB1831; X-Forefront-PRVS: 05947791E4 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jun 2015 17:42:44.6664 (UTC) X-MS-Exchange-CrossTenant-Id: 49808c08-7df8-4c41-af62-7a0827de9408 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=49808c08-7df8-4c41-af62-7a0827de9408; Ip=[199.135.140.17]; Helo=[mail.usda.gov] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR06MB1831 X-OriginatorOrg: fs.fed.us Archived-At: X-Mailman-Approved-At: Mon, 01 Jun 2015 12:35:25 -0700 Subject: [Endymail] FW: Group/Enterprise encrypted email X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 17:43:13 -0000 --_000_82E7C9A01FD0764CACDD35D10F5DFB6E7DFBBD001FSN2MPN1046001_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was directed to this list because I posted the following to [kitten]. I l= ooked at the archives here, and it seems that my proposed email key gatekee= per (run by the entity providing the email account) may solve the key distr= ibution problem for transit, both for point to point ops as well as mailing= lists. No promises. It's not like I spend my life thinking about this stuff. Bryce From: Nordgren, Bryce L -FS Sent: Friday, May 29, 2015 4:36 PM To: kitten@ietf.org Subject: Group/Enterprise encrypted email This is a "what if" message, centered around trying to make email encryptio= n as painless as email signing. I want to be able to encrypt an email messa= ge once, no matter how many recipients there are. An enterprise should be a= ble to decrypt employees' email to ensure there's no misbehavior. I want as= little "extra" supporting infrastructure as possible. I also want to minim= ize the amount of inter-organizational coordination required. What if sending an encrypted email required clients to contact an email key= gatekeeper (EKG)? The EKG issues one-time-use encryption keys to authorize= d senders, and releases the decryption key once (only) to each recipient. Detailed flow: When encryption is desired, the sender's email client formats a key request= to the EKG and signs it using the sender's email signing key. The key requ= est includes the recipient's email addresses, but not their public keys, wh= ich are unknown. If the EKG is configured to recognize the sender, it repli= es with: 1] an encryption key, encrypted with the sender's public email sig= ning key; and 2] a plaintext copy of the key request, signed by the EKG its= elf. The sender then decrypts the encryption key, encrypts the message and = attachments, and attaches the signed key request. Poof. The message is sent= . If the sender's client stores outgoing mail in a "sent mail" folder, the = stored copy must be encrypted using some other means. The EKG-signed key request includes: 1] a unique identifier for the encrypt= ion key; 2] contact info, so recipients can locate the EKG; and 3] of cours= e, the list of recipients (part of the original key request). The Sender's organization can decrypt the outbound email at a gateway by co= ntacting the EKG and retrieving the decryption key (which could be the same= as the encryption key if symmetric, or the other half of an asymmetric key= pair if not.) The recipient's organization (assuming different than sender's organization= ) cannot decrypt the inbound email at a gateway. The recipient's email client detects the EKG's signed key request attached = to the email. The EKG's signature is verified. The recipient's client uses = the recipient's email signing cert to sign the EKG-signed key request, and = sends to the EKG using the contact information provided. The EKG verifies the recipients' signature. The EKG verifies that the recip= ient's certificate contains an email address that is included as a recipien= t in the original key request. The EKG verifies its own signature. The EKG = encrypts the email's decryption key using the recipient's public email sign= ing key, and signs the response. The recipient verifies the signature (ensu= ring same EKG signed key request and decryption key request) and decrypts t= he message/attachments. If the message is to be stored, it must be re-encrypted in a locally recove= rable fashion, likely with the recipient's credentials. If the recipient's = organization is concerned about decrypting inbound email, the "locally reco= verable fashion" should allow authorized individuals/services access. The o= riginal ciphertext should not be stored after decryption, and the decryptio= n key must not be stored. Probably best not to get too psycho over this: th= e recipient can always cut and paste to some cleartext medium like word, or= take a screenshot. Reasonable assurance that clients keep things encrypted= when they're received encrypted is what we're after. The EKG keeps track of which recipients have requested the decryption key. = Recipients are allowed to request the key once and only once. When all reci= pients have requested the decryption key, that key must never be served out= again. The EKG should not re-use encryption keys for subsequent messages. Clearly, the EKG needs to be just as publicly available as the organization= 's mailserver. I do not believe there would need to be anything special in = DNS (no "EKG" records, etc.) To summarize: The EKG knows nothing about sen= ders or recipients other than what the certificates tell it. Encryption key= s for email messages are one-time-use, and shared among sender and all reci= pients. Recipients get decryption keys by having a certificate with a match= ing email address. No extra coordination is involved over and above the con= figuration necessary to verify email signatures. What do you think? Is there an obvious reason this hasn't been done before? Bryce --_000_82E7C9A01FD0764CACDD35D10F5DFB6E7DFBBD001FSN2MPN1046001_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I was directed to this= list because I posted the following to [kitten]. I looked at the archives = here, and it seems that my proposed email key gatekeeper (run by the entity= providing the email account) may solve the key distribution problem for transit, both for point to point ops as w= ell as mailing lists.

 

No promises. It’= s not like I spend my life thinking about this stuff.

 

Bryce

 

From: Nordgren= , Bryce L -FS
Sent: Friday, May 29, 2015 4:36 PM
To: kitten@ietf.org
Subject: Group/Enterprise encrypted email

 

This is a “what if” message, centered ar= ound trying to make email encryption as painless as email signing. I want t= o be able to encrypt an email message once, no matter how many recipients t= here are. An enterprise should be able to decrypt employees’ email to ensure there’s no misbehavior. I want as l= ittle “extra” supporting infrastructure as possible. I also wan= t to minimize the amount of inter-organizational coordination required.

 

What if sending an encrypted email required clients = to contact an email key gatekeeper (EKG)? The EKG issues one-time-use encry= ption keys to authorized senders, and releases the decryption key once (onl= y) to each recipient.

 

Detailed flow:

 

When encryption is desired, the sender’s email= client formats a key request to the EKG and signs it using the sender̵= 7;s email signing key. The key request includes the recipient’s email= addresses, but not their public keys, which are unknown. If the EKG is configured to recognize the sender, it replies with: 1] an e= ncryption key, encrypted with the sender’s public email signing key; = and 2] a plaintext copy of the key request, signed by the EKG itself. The s= ender then decrypts the encryption key, encrypts the message and attachments, and attaches the signed key request.= Poof. The message is sent. If the sender’s client stores outgoing ma= il in a “sent mail” folder, the stored copy must be encrypted u= sing some other means.

 

The EKG-signed key request includes: 1] a unique ide= ntifier for the encryption key; 2] contact info, so recipients can locate t= he EKG; and 3] of course, the list of recipients (part of the original key = request).

 

The Sender’s organization can decrypt the outb= ound email at a gateway by contacting the EKG and retrieving the decryption= key (which could be the same as the encryption key if symmetric, or the ot= her half of an asymmetric keypair if not.)

 

The recipient’s organization (assuming differe= nt than sender’s organization) cannot decrypt the inbound email at a = gateway.

 

The recipient’s email client detects the EKG&#= 8217;s signed key request attached to the email. The EKG’s signature = is verified. The recipient’s client uses the recipient’s email = signing cert to sign the EKG-signed key request, and sends to the EKG using the contact information provided.

 

The EKG verifies the recipients’ signature. Th= e EKG verifies that the recipient’s certificate contains an email add= ress that is included as a recipient in the original key request. The EKG v= erifies its own signature. The EKG encrypts the email’s decryption key using the recipient’s public email sign= ing key, and signs the response. The recipient verifies the signature (ensu= ring same EKG signed key request and decryption key request) and decrypts t= he message/attachments.

 

If the message is to be stored, it must be re-encryp= ted in a locally recoverable fashion, likely with the recipient’s cre= dentials. If the recipient’s organization is concerned about decrypti= ng inbound email, the “locally recoverable fashion” should allow authorized individuals/services access. The original cipherte= xt should not be stored after decryption, and the decryption key must not b= e stored. Probably best not to get too psycho over this: the recipient can = always cut and paste to some cleartext medium like word, or take a screenshot. Reasonable assurance that clients = keep things encrypted when they’re received encrypted is what we̵= 7;re after.

 

The EKG keeps track of which recipients have request= ed the decryption key. Recipients are allowed to request the key once and o= nly once. When all recipients have requested the decryption key, that key m= ust never be served out again. The EKG should not re-use encryption keys for subsequent messages.<= /p>

 

Clearly, the EKG needs to be just as publicly availa= ble as the organization’s mailserver. I do not believe there would ne= ed to be anything special in DNS (no “EKG” records, etc.) To su= mmarize:  The EKG knows nothing about senders or recipients other than what the certificates tell it. Encryption keys for email messag= es are one-time-use, and shared among sender and all recipients. Recipients= get decryption keys by having a certificate with a matching email address.= No extra coordination is involved over and above the configuration necessary to verify email signatures.

 

What do you think? Is there an obvious reason this h= asn’t been done before?

 

Bryce

--_000_82E7C9A01FD0764CACDD35D10F5DFB6E7DFBBD001FSN2MPN1046001_-- From nobody Mon Jun 1 12:35:28 2015 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C41D61B30C6; Mon, 1 Jun 2015 11:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 qtXlswH_tqIs; Mon, 1 Jun 2015 11:25:06 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0055.outbound.protection.outlook.com [207.46.100.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74EC91B30B6; Mon, 1 Jun 2015 11:24:54 -0700 (PDT) Received: from CO2PR06CA044.namprd06.prod.outlook.com (10.141.242.44) by CY1PR0601MB1563.namprd06.prod.outlook.com (25.163.232.141) with Microsoft SMTP Server (TLS) id 15.1.172.22; Mon, 1 Jun 2015 18:24:53 +0000 Received: from BL2FFO11OLC015.protection.gbl (2a01:111:f400:7c09::142) by CO2PR06CA044.outlook.office365.com (2a01:111:e400:142a::44) with Microsoft SMTP Server (TLS) id 15.1.172.22 via Frontend Transport; Mon, 1 Jun 2015 18:24:53 +0000 Authentication-Results: spf=pass (sender IP is 199.135.140.18) smtp.mailfrom=fs.fed.us; MIT.EDU; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of fs.fed.us designates 199.135.140.18 as permitted sender) receiver=protection.outlook.com; client-ip=199.135.140.18; helo=mail.usda.gov; Received: from mail.usda.gov (199.135.140.18) by BL2FFO11OLC015.mail.protection.outlook.com (10.173.160.81) with Microsoft SMTP Server (TLS) id 15.1.184.11 via Frontend Transport; Mon, 1 Jun 2015 18:24:52 +0000 Received: from 001FSN2MPN1-046.001f.mgd2.msft.net ([169.254.6.131]) by 001FSN2MMR1-008.001f.mgd2.msft.net ([199.135.140.18]) with mapi id 14.03.0224.003; Mon, 1 Jun 2015 18:24:29 +0000 From: "Nordgren, Bryce L -FS" To: Benjamin Kaduk Thread-Topic: [kitten] Group/Enterprise encrypted email Thread-Index: AdCaU4EBKI9vXfbmSrKplnpcKmT5cgAGnCmAAIkbNEA= Date: Mon, 1 Jun 2015 18:24:29 +0000 Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E7DFBF9@001FSN2MPN1-046.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7DF8C3@001FSN2MPN1-046.001f.mgd2.msft.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.7.27.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11OLC015; 1:yZeta8lB2RFZPu3s1UKcao8/t4HCmx6whVqi3O3J3mfFGj0NYGm5+fxaUvw1gSVRb3Cbky4d3TeCLFuGaUyh6GeFhKBP7H2v2QIfUJ/bVXan+W9gqzTjkg/QgnO/Z7JzWqa5RVH772S46WiLoh2W/9YP9TDNuhUiBDXdoDGS2pF8FSIXgbmuN6CTG8Ie44+82VVzjtvsAAU90crEMmhEIT7ebkjAumisOuM+mkwSm4it2OoiaLH66QGQoobQ+rpAzv0+189eSllA6OxKPPLytJ1dR/Btrb8AMR+jFt7hq7I= X-Forefront-Antispam-Report: CIP:199.135.140.18; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(438002)(199003)(13464003)(164054003)(51704005)(189002)(87936001)(2656002)(2171001)(22756005)(55846006)(64706001)(77156002)(97756001)(68736005)(102836002)(22746005)(62966003)(46406003)(46102003)(6806004)(47776003)(74482002)(66066001)(19580395003)(19580405001)(69596002)(92566002)(86146001)(566704002)(50986999)(50466002)(561944003)(26826002)(86362001)(33656002)(76176999)(54356999)(104016003)(5001860100001)(2920100001)(5001960100002)(5001830100001)(5001920100001)(81156007)(106466001)(110136002)(4001540100001)(2950100001)(2900100001)(189998001)(23726002)(97736004)(80862005)(79686002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0601MB1563; H:mail.usda.gov; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0601MB1563; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:CY1PR0601MB1563; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0601MB1563; X-Forefront-PRVS: 05947791E4 X-OriginatorOrg: fs.fed.us X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jun 2015 18:24:52.7751 (UTC) X-MS-Exchange-CrossTenant-Id: 49808c08-7df8-4c41-af62-7a0827de9408 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=49808c08-7df8-4c41-af62-7a0827de9408; Ip=[199.135.140.18]; Helo=[mail.usda.gov] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0601MB1563 Archived-At: X-Mailman-Approved-At: Mon, 01 Jun 2015 12:35:25 -0700 Cc: "kitten@ietf.org" , "endymail@ietf.org" Subject: Re: [Endymail] [kitten] Group/Enterprise encrypted email X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 18:25:08 -0000 > -----Original Message----- > From: Benjamin Kaduk [mailto:kaduk@MIT.EDU] > > You might have better luck on the endymail list, which is considering way= s to > improve email privacy. I don't recall whether a scheme substantially sim= ilar > to your proposal has been discussed there, but there should be a good cro= p > of people interested in improving the state of email to comment there. Hi Ben and Nico,=20 I thumbed through the endymail archives and things appear to be sort of dea= d. I forwarded the message there anyway just in case someone's still listen= ing. Lot of activity at first, then nothing till now. I just thought it was= kind of neat. :) If it fails to spark any discussion I'll move on. My proposal seems to get around a few of the problems endymail identified s= imply by using a per-message key for in-flight data only. Quite a lot of th= e endymail discussion revolves around key management/distribution for end u= sers. All of it involves using something related to the user's identity to = encrypt email. My proposal appears to be distinct from anything discussed t= here because of my focus on per-message keys unrelated to anyone's identity= . This also distinguishes it from Identity based encryption (thanks Nico!).= The EKG never holds (or releases) keys related to someone's identity. This= scheme has the potential to be a form of OTR protection by configuring the= EKG correctly, anthough if you configure the EKG to hand the key out like = candy, why bother encrypting it? Enterprises will likely not configure thei= r key guardians in this way. Drawbacks are that you can only send encrypted email if your email provider= operates an EKG, you and all your recipients have been issued "email addre= ss certificates" by the respective mail providers, and your recipients must= have a PKI anchor your email provider is configured to trust. For enterpri= ses interested in protecting their IP and operating their own email servers= , this is not likely to be problematic. I suspect webmail clients could als= o participate, as the webmail server would be decrypting the message and th= en displaying it over https. Thanks, Bryce From nobody Mon Jun 1 21:49:16 2015 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E06D1ACEC5 for ; Mon, 1 Jun 2015 21:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 Jc2QFTw0LxQW for ; Mon, 1 Jun 2015 21:49:09 -0700 (PDT) Received: from mr11p24im-asmtp002.me.com (mr11p24im-asmtp002.me.com [17.110.78.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5B521ACEBE for ; Mon, 1 Jun 2015 21:49:09 -0700 (PDT) Received: from denhp (c-24-17-210-106.hsd1.wa.comcast.net [24.17.210.106]) by mr11p24im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NPA006BUW1UD720@mr11p24im-asmtp002.me.com> for endymail@ietf.org; Tue, 02 Jun 2015 04:49:09 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-06-02_05:2015-05-29,2015-06-02,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1506020070 From: Trevor Freeman To: "'Nordgren, Bryce L -FS'" , endymail@ietf.org References: <82E7C9A01FD0764CACDD35D10F5DFB6E7DFBBD@001FSN2MPN1-046.001f.mgd2.msft.net> In-reply-to: <82E7C9A01FD0764CACDD35D10F5DFB6E7DFBBD@001FSN2MPN1-046.001f.mgd2.msft.net> Date: Mon, 01 Jun 2015 21:49:06 -0700 Message-id: <000d01d09cef$76039f10$620add30$@icloud.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="----=_NextPart_000_000E_01D09CB4.C9A64DB0" X-Mailer: Microsoft Outlook 14.0 Thread-index: AQI4r1yN6a8adADhwF3Fb1Vfc9FNL5zIesBQ Content-language: en-us Archived-At: Subject: Re: [Endymail] FW: Group/Enterprise encrypted email X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 04:49:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000E_01D09CB4.C9A64DB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Bryce, What you propose is very similar to the Plasma work. The Plasma server functions like a EKG as you describe. We generalized the model more so we made authentication to the Plasma server via user tokens so it is possible to support a broader set of authentication mechanisms and authentication levels e.g. Facebook or Google+, as well as PIV cards. Since we support user tokes we can also do Attribute Based Access Control if the message contents warrant e.g. if the message has ITAR material. There were a number of compares built a POC to show this works and interoperates. Here is the requirements document if you are interested. Doing late key binging via an EKG does have a number of advantages over early key binding. It is generally much more forgiving. It does not requires everybody to have encryption keys at send time. It scales better if you have a large number of recipients. It also does not require recipient key escrow to prevent data loss if you lose your encryption key. This main issue is the security and scope of the EKG key or keys. Here is the draft if you want to read more. https://datatracker.ietf.org/doc/draft-freeman-plasma-requirements/ Trevor From: Endymail [mailto:endymail-bounces@ietf.org] On Behalf Of Nordgren, Bryce L -FS Sent: Monday, June 01, 2015 10:42 AM To: endymail@ietf.org Subject: [Endymail] FW: Group/Enterprise encrypted email I was directed to this list because I posted the following to [kitten]. I looked at the archives here, and it seems that my proposed email key gatekeeper (run by the entity providing the email account) may solve the key distribution problem for transit, both for point to point ops as well as mailing lists. No promises. It's not like I spend my life thinking about this stuff. Bryce From: Nordgren, Bryce L -FS Sent: Friday, May 29, 2015 4:36 PM To: kitten@ietf.org Subject: Group/Enterprise encrypted email This is a "what if" message, centered around trying to make email encryption as painless as email signing. I want to be able to encrypt an email message once, no matter how many recipients there are. An enterprise should be able to decrypt employees' email to ensure there's no misbehavior. I want as little "extra" supporting infrastructure as possible. I also want to minimize the amount of inter-organizational coordination required. What if sending an encrypted email required clients to contact an email key gatekeeper (EKG)? The EKG issues one-time-use encryption keys to authorized senders, and releases the decryption key once (only) to each recipient. Detailed flow: When encryption is desired, the sender's email client formats a key request to the EKG and signs it using the sender's email signing key. The key request includes the recipient's email addresses, but not their public keys, which are unknown. If the EKG is configured to recognize the sender, it replies with: 1] an encryption key, encrypted with the sender's public email signing key; and 2] a plaintext copy of the key request, signed by the EKG itself. The sender then decrypts the encryption key, encrypts the message and attachments, and attaches the signed key request. Poof. The message is sent. If the sender's client stores outgoing mail in a "sent mail" folder, the stored copy must be encrypted using some other means. The EKG-signed key request includes: 1] a unique identifier for the encryption key; 2] contact info, so recipients can locate the EKG; and 3] of course, the list of recipients (part of the original key request). The Sender's organization can decrypt the outbound email at a gateway by contacting the EKG and retrieving the decryption key (which could be the same as the encryption key if symmetric, or the other half of an asymmetric keypair if not.) The recipient's organization (assuming different than sender's organization) cannot decrypt the inbound email at a gateway. The recipient's email client detects the EKG's signed key request attached to the email. The EKG's signature is verified. The recipient's client uses the recipient's email signing cert to sign the EKG-signed key request, and sends to the EKG using the contact information provided. The EKG verifies the recipients' signature. The EKG verifies that the recipient's certificate contains an email address that is included as a recipient in the original key request. The EKG verifies its own signature. The EKG encrypts the email's decryption key using the recipient's public email signing key, and signs the response. The recipient verifies the signature (ensuring same EKG signed key request and decryption key request) and decrypts the message/attachments. If the message is to be stored, it must be re-encrypted in a locally recoverable fashion, likely with the recipient's credentials. If the recipient's organization is concerned about decrypting inbound email, the "locally recoverable fashion" should allow authorized individuals/services access. The original ciphertext should not be stored after decryption, and the decryption key must not be stored. Probably best not to get too psycho over this: the recipient can always cut and paste to some cleartext medium like word, or take a screenshot. Reasonable assurance that clients keep things encrypted when they're received encrypted is what we're after. The EKG keeps track of which recipients have requested the decryption key. Recipients are allowed to request the key once and only once. When all recipients have requested the decryption key, that key must never be served out again. The EKG should not re-use encryption keys for subsequent messages. Clearly, the EKG needs to be just as publicly available as the organization's mailserver. I do not believe there would need to be anything special in DNS (no "EKG" records, etc.) To summarize: The EKG knows nothing about senders or recipients other than what the certificates tell it. Encryption keys for email messages are one-time-use, and shared among sender and all recipients. Recipients get decryption keys by having a certificate with a matching email address. No extra coordination is involved over and above the configuration necessary to verify email signatures. What do you think? Is there an obvious reason this hasn't been done before? Bryce ------=_NextPart_000_000E_01D09CB4.C9A64DB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Bryce,

What you propose is very = similar to the Plasma work. The Plasma server functions like a EKG as = you describe. We generalized the model more so we made authentication to = the Plasma server via user tokens so it is possible to support a broader = set of authentication mechanisms and authentication levels e.g. Facebook = or Google+, as well as PIV cards.  Since we support user tokes we = can also do Attribute Based Access Control if the message contents = warrant e.g. if the message has ITAR material.  There were a number = of compares built a POC to show this works and interoperates. =

Here is the requirements document if you are = interested.

Doing late key binging via an EKG does have a = number of advantages over early key binding. It is generally much more = forgiving. It does not requires everybody to have encryption keys at = send time. It scales better if you have a large number of recipients. It = also does not require recipient key escrow to prevent data loss if you = lose your encryption key.  This main issue is the security and = scope of the EKG key or keys.

Here is the draft if you = want to read more. https://datatracker.ietf.org/doc/draft-freeman-plasma-requirements/

 

Trevor

 

 

I was directed to this list because I posted the = following to [kitten]. I looked at the archives here, and it seems that = my proposed email key gatekeeper (run by the entity providing the email = account) may solve the key distribution problem for transit, both for = point to point ops as well as mailing lists.

 

No promises. It’s = not like I spend my life thinking about this = stuff.

 

Bryce

 

 

This is a = “what if” message, centered around trying to make email = encryption as painless as email signing. I want to be able to encrypt an = email message once, no matter how many recipients there are. An = enterprise should be able to decrypt employees’ email to ensure = there’s no misbehavior. I want as little “extra” = supporting infrastructure as possible. I also want to minimize the = amount of inter-organizational coordination required.

 

What if = sending an encrypted email required clients to contact an email key = gatekeeper (EKG)? The EKG issues one-time-use encryption keys to = authorized senders, and releases the decryption key once (only) to each = recipient.

 

Detailed flow:

 

When = encryption is desired, the sender’s email client formats a key = request to the EKG and signs it using the sender’s email signing = key. The key request includes the recipient’s email addresses, but = not their public keys, which are unknown. If the EKG is configured to = recognize the sender, it replies with: 1] an encryption key, encrypted = with the sender’s public email signing key; and 2] a plaintext = copy of the key request, signed by the EKG itself. The sender then = decrypts the encryption key, encrypts the message and attachments, and = attaches the signed key request. Poof. The message is sent. If the = sender’s client stores outgoing mail in a “sent mail” = folder, the stored copy must be encrypted using some other = means.

 

The EKG-signed key request includes: 1] a unique = identifier for the encryption key; 2] contact info, so recipients can = locate the EKG; and 3] of course, the list of recipients (part of the = original key request).

 

The = Sender’s organization can decrypt the outbound email at a gateway = by contacting the EKG and retrieving the decryption key (which could be = the same as the encryption key if symmetric, or the other half of an = asymmetric keypair if not.)

 

The = recipient’s organization (assuming different than sender’s = organization) cannot decrypt the inbound email at a gateway. =

 

The recipient’s email client detects the = EKG’s signed key request attached to the email. The EKG’s = signature is verified. The recipient’s client uses the = recipient’s email signing cert to sign the EKG-signed key request, = and sends to the EKG using the contact information provided. =

 

The EKG verifies the recipients’ signature. The = EKG verifies that the recipient’s certificate contains an email = address that is included as a recipient in the original key request. The = EKG verifies its own signature. The EKG encrypts the email’s = decryption key using the recipient’s public email signing key, and = signs the response. The recipient verifies the signature (ensuring same = EKG signed key request and decryption key request) and decrypts the = message/attachments.

 

If the = message is to be stored, it must be re-encrypted in a locally = recoverable fashion, likely with the recipient’s credentials. If = the recipient’s organization is concerned about decrypting inbound = email, the “locally recoverable fashion” should allow = authorized individuals/services access. The original ciphertext should = not be stored after decryption, and the decryption key must not be = stored. Probably best not to get too psycho over this: the recipient can = always cut and paste to some cleartext medium like word, or take a = screenshot. Reasonable assurance that clients keep things encrypted when = they’re received encrypted is what we’re = after.

 

The EKG keeps track of which recipients have requested = the decryption key. Recipients are allowed to request the key once and = only once. When all recipients have requested the decryption key, that = key must never be served out again. The EKG should not re-use encryption = keys for subsequent messages.

 

Clearly, the = EKG needs to be just as publicly available as the organization’s = mailserver. I do not believe there would need to be anything special in = DNS (no “EKG” records, etc.) To summarize:  The EKG = knows nothing about senders or recipients other than what the = certificates tell it. Encryption keys for email messages are = one-time-use, and shared among sender and all recipients. Recipients get = decryption keys by having a certificate with a matching email address. = No extra coordination is involved over and above the configuration = necessary to verify email signatures.

 

What do you = think? Is there an obvious reason this hasn’t been done before? =

 

Bryce

------=_NextPart_000_000E_01D09CB4.C9A64DB0-- From nobody Mon Jun 1 22:07:15 2015 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7424D1B29CE for ; Mon, 1 Jun 2015 22:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 rHsVREsroZBA for ; Mon, 1 Jun 2015 22:07:13 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 854311A0461 for ; Mon, 1 Jun 2015 22:07:12 -0700 (PDT) Received: by wifw1 with SMTP id w1so129802044wif.0 for ; Mon, 01 Jun 2015 22:07:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=XMpu53eSP52u/XqBFHFu0zSrfkD0Sz0rVdMjy7ovJ0E=; b=xKNv5uHb/BCgbJa5ddMo1Cs/UyvKeH92ry7HsnqFR8uHPesjKEEZPuSDGUo4+dGYtm qz9w+btbSMMJHFzWt/msXs39lFgrVQbk7twzdgG00leF7c1FknZ2Dy9GJ98EtdmsoLDj SaBDhtNoS3uqAI/TCx9s17CBzt6Au6Go/Uy9iQkEvovlaAtBPyx0Yi9Y1lOcrZD+IWop z21OLCcNYnoOgliZM+Vlp1pMg+SpF1e/aCYBmMc6kawjNa6yYbHBq1Tiltb6y0Haqs3P h5JD650BOwnVLR5VPZb7ozwr35MpTJcDGyzhWpJyr/UUGcpfWPnVmNgjfBF5yV0E3nR8 BNhw== MIME-Version: 1.0 X-Received: by 10.180.9.6 with SMTP id v6mr27454384wia.83.1433221631296; Mon, 01 Jun 2015 22:07:11 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Mon, 1 Jun 2015 22:07:11 -0700 (PDT) Date: Mon, 1 Jun 2015 22:07:11 -0700 Message-ID: From: Watson Ladd To: endymail Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Endymail] Why S/MIME and OpenPGP ecosystems fall short X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 05:07:14 -0000 Dear all, Let's compare a messaging system like TextSecure to the experience of secure email messaging. A user downloads TextSecure, starts using it. It has a familiar UI, and encrypts when it can without any explicit user invocation. If they want to validate keys, they can do so easily: there is one fingerprint and clear instructions on how to compare it. The semantics are exactly what is expected. Compare to what happens with GPG. Immediately the user is asked to make important choices with no guidance. Key discover is separate step. When sending messages, they have to choose several orders of operations and ciphers, with the wrong choice having consequences. I don't think any choices have the right semantics. A lot of this has been ruled out of scope as UI issues, but I don't think so: I think that solving these issues require removing many of the problems that we expose to users. Certainly some plugins do a very good job of fixing some of these headaches, but I don't think any of them are as reliable as TextSecure. It's clear to me that this isn't easily fixable by standards work alone: much of the damage is baked in to the functioning of S/MIME and PGP. What needs to happen is that we need to come up with good ideas around key management that are actually deployable, and provide the semantics people want. Sincerely, Watson Ladd From nobody Tue Jun 2 02:49:07 2015 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909D21A907F for ; Tue, 2 Jun 2015 02:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 nebZHv3398KM for ; Tue, 2 Jun 2015 02:49:04 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A7961B29D8 for ; Tue, 2 Jun 2015 02:49:03 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 6AD0AFA0065; Tue, 2 Jun 2015 09:49:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1433238541; bh=WuYfaeckL6pgZBLPXkLW5F4njMJTVvP7mHqWCd0W1jc=; h=From:To:Subject:References:Date:From; b=q4E5Wqg3vHHrjuXplW04UQfVYWyFXkWtJ+9SIPof9FSTRTXNSRugLXgRcDDzNOuHK eMiNxSue1EVRKGBrjN7CFDpIHkyeFnCzy4tkuGv+o7lL8qCCZU4EV/27avJMf+1L20 pcqLGJL9QwZDcH6Tm+W3SEgbs+pwB6kutCHz+mqk= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1433238540-28872-28871/12/38; Tue, 2 Jun 2015 09:49:00 +0000 From: Arnt Gulbrandsen To: Watson Ladd , endymail@ietf.org Message-Id: References: Mime-Version: 1.0 Content-Type: text/plain; format=flowed Date: Tue, 2 Jun 2015 09:49:00 +0000 Archived-At: Subject: Re: [Endymail] Why S/MIME and OpenPGP ecosystems fall short X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 09:49:05 -0000 Agreed. But: Good luck. The GPG fans will fight you every step of the way. Arnt From nobody Tue Jun 2 11:53:16 2015 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4E21ACE16 for ; Tue, 2 Jun 2015 11:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 XKGU-XYVC0sT for ; Tue, 2 Jun 2015 11:53:07 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0088.outbound.protection.outlook.com [207.46.100.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56EAF1ACE14 for ; Tue, 2 Jun 2015 11:53:07 -0700 (PDT) Received: from CY1PR0601CA0020.namprd06.prod.outlook.com (25.160.162.30) by BY2PR0601MB1559.namprd06.prod.outlook.com (25.163.107.141) with Microsoft SMTP Server (TLS) id 15.1.172.22; Tue, 2 Jun 2015 18:53:05 +0000 Received: from BY2FFO11FD004.protection.gbl (2a01:111:f400:7c0c::175) by CY1PR0601CA0020.outlook.office365.com (2a01:111:e400:4c00::30) with Microsoft SMTP Server (TLS) id 15.1.184.17 via Frontend Transport; Tue, 2 Jun 2015 18:53:05 +0000 Authentication-Results: spf=pass (sender IP is 199.135.140.15) smtp.mailfrom=fs.fed.us; icloud.com; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of fs.fed.us designates 199.135.140.15 as permitted sender) receiver=protection.outlook.com; client-ip=199.135.140.15; helo=mail.usda.gov; Received: from mail.usda.gov (199.135.140.15) by BY2FFO11FD004.mail.protection.outlook.com (10.1.14.158) with Microsoft SMTP Server (TLS) id 15.1.184.11 via Frontend Transport; Tue, 2 Jun 2015 18:53:05 +0000 Received: from 001FSN2MPN1-046.001f.mgd2.msft.net ([169.254.6.131]) by 001FSN2MMR1-005.001f.mgd2.msft.net ([199.135.140.15]) with mapi id 14.03.0224.003; Tue, 2 Jun 2015 18:52:51 +0000 From: "Nordgren, Bryce L -FS" To: Trevor Freeman , "endymail@ietf.org" Thread-Topic: [Endymail] FW: Group/Enterprise encrypted email Thread-Index: AdCaU4EBKI9vXfbmSrKplnpcKmT5cgCPeK3wABeENQAAG8dZUA== Date: Tue, 2 Jun 2015 18:52:51 +0000 Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E7E1094@001FSN2MPN1-046.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7DFBBD@001FSN2MPN1-046.001f.mgd2.msft.net> <000d01d09cef$76039f10$620add30$@icloud.com> In-Reply-To: <000d01d09cef$76039f10$620add30$@icloud.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.7.27.143] Content-Type: multipart/alternative; boundary="_000_82E7C9A01FD0764CACDD35D10F5DFB6E7E1094001FSN2MPN1046001_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD004; 1:vA5+KK5xJJLAo5MfXUDp4tOslFsXqKrWsnEgIo6hnhG8gh95OMQEm1szaX+RYnRjR71k0YlYc3ZTPU9uGGMoTT1jZjh1aXRzciH/+znv8EQ1CWDHV4+OKEqp+I6/EkB6x7G9XCVm3LwL51BStYE45nTK0xp0qdmAErnWGmb3EbKWG3hHU85J/87NqPM70QAKC+6G/0Z5p4GdBKXk85/e6Oasnc6fvjHElWOr3pttPPfTxcS4a6nIIjYGwiWJUKpiypPh3F+rgnuLAI2zX3rMJpthi5boQOFe3fuR2MH7Vnw= X-Forefront-Antispam-Report: CIP:199.135.140.15; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009020)(438002)(189002)(199003)(76104003)(377454003)(51914003)(16236675004)(104016003)(19617315012)(87936001)(46102003)(15975445007)(2920100001)(5001770100001)(97736004)(22746005)(22756005)(26826002)(2900100001)(102836002)(68736005)(74482002)(6806004)(106466001)(55846006)(2656002)(19580395003)(19300405004)(19580405001)(2950100001)(54356999)(81156007)(33656002)(4001540100001)(512954002)(19625215002)(76176999)(50986999)(69596002)(66066001)(86146001)(64706001)(92566002)(86362001)(5001860100001)(77156002)(5001830100001)(189998001)(84326002)(62966003)(2501003)(5890100001)(5001960100002)(107886002)(7059030)(80862005)(79686002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR0601MB1559; H:mail.usda.gov; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0601MB1559; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:BY2PR0601MB1559; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0601MB1559; X-Forefront-PRVS: 05954A7C45 X-OriginatorOrg: fs.fed.us X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jun 2015 18:53:05.1307 (UTC) X-MS-Exchange-CrossTenant-Id: 49808c08-7df8-4c41-af62-7a0827de9408 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=49808c08-7df8-4c41-af62-7a0827de9408; Ip=[199.135.140.15]; Helo=[mail.usda.gov] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0601MB1559 Archived-At: Subject: Re: [Endymail] FW: Group/Enterprise encrypted email X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 18:53:15 -0000 --_000_82E7C9A01FD0764CACDD35D10F5DFB6E7E1094001FSN2MPN1046001_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Trevor, thanks for the link. I like the multiple ways to authenticate to plasma servers, and of course y= our "late key binding". Sounds so much more professional than my version! I= n my quick read, I was not able to locate how I would specify who gets acce= ss to the keys for my message, or whether that was bound to the message pay= load. Does the message contain an untamperable list of authorized recipient= s? I have some concerns about the DRM, basically that I'd like to see it facto= red out into a separate doc. To me, the point of encrypted messaging is to = deliver content to a specified party while preventing others from snooping.= If I have concerns about what that party might do with the content upon re= ceipt, I shouldn't be sending it to them in the first place. You just can't= fix stupid. But let's say we try to fix stupid. And we specify a perfect message DRM ec= osystem. Screenshots will likely still work. Cell phones with cameras can a= lways still be pointed at the screen. Are you really comfortable stating th= at any situation has a "high", "significant", or even "some" confidence tha= t policy is enforced when just about anyone can defeat the system with a ke= ypress? Will users, after they defeat it themselves? Will security officers= ? Attachments. The perfect DRM-compliant email client will have to decrypt th= e attachment payload and hand it off to the application which recognizes it= . At this point it has been exported from the DRM system and you again must= trust the other party will use it appropriately. Either that, or assimilat= e every possible application which can process every possible attachment in= to your DRM system. Such a system would be like "Ultraviolet for Everything= ". The solution to both of these drawbacks is "think before you send", which i= s what you should do if you're dealing with sensitive data anyway. Simplifi= es the spec immensely, by providing a clear, well defined, easily understoo= d user responsibility. Even an "Ultraviolet for Everything" approach does n= ot relieve the user of this responsibility. IMHO, the design of a comprehen= sive DRM system for all content is a much different animal than just making= sure the content is delivered reliably and protected from snooping. I reco= mmend starting with just secure transport and tackling DRM later. Finally, a secure, self-contained DRM system excludes open source software = by definition. If anyone can comment out the "enforcement code" then recomp= ile, all confidence is low. This is why open source blue ray players on Lin= ux rely on cracking old codes: no one will give them "good" codes. On the o= ther hand, secure delivery of "no strings attached" encrypted messages is s= omething that open source can do very well. Respecting this boundary line i= s an excellent reason to split the spec into transport and DRM. Just some thoughts. Bryce From: Trevor Freeman [mailto:trevor.freeman99@icloud.com] Sent: Monday, June 01, 2015 10:49 PM To: Nordgren, Bryce L -FS; endymail@ietf.org Subject: RE: [Endymail] FW: Group/Enterprise encrypted email Hi Bryce, What you propose is very similar to the Plasma work. The Plasma server func= tions like a EKG as you describe. We generalized the model more so we made = authentication to the Plasma server via user tokens so it is possible to su= pport a broader set of authentication mechanisms and authentication levels = e.g. Facebook or Google+, as well as PIV cards. Since we support user toke= s we can also do Attribute Based Access Control if the message contents war= rant e.g. if the message has ITAR material. There were a number of compare= s built a POC to show this works and interoperates. Here is the requirements document if you are interested. Doing late key binging via an EKG does have a number of advantages over ear= ly key binding. It is generally much more forgiving. It does not requires e= verybody to have encryption keys at send time. It scales better if you have= a large number of recipients. It also does not require recipient key escro= w to prevent data loss if you lose your encryption key. This main issue is= the security and scope of the EKG key or keys. Here is the draft if you want to read more. https://datatracker.ietf.org/do= c/draft-freeman-plasma-requirements/ Trevor From: Endymail [mailto:endymail-bounces@ietf.org] On Behalf Of Nordgren, Br= yce L -FS Sent: Monday, June 01, 2015 10:42 AM To: endymail@ietf.org Subject: [Endymail] FW: Group/Enterprise encrypted email I was directed to this list because I posted the following to [kitten]. I l= ooked at the archives here, and it seems that my proposed email key gatekee= per (run by the entity providing the email account) may solve the key distr= ibution problem for transit, both for point to point ops as well as mailing= lists. No promises. It's not like I spend my life thinking about this stuff. Bryce From: Nordgren, Bryce L -FS Sent: Friday, May 29, 2015 4:36 PM To: kitten@ietf.org Subject: Group/Enterprise encrypted email This is a "what if" message, centered around trying to make email encryptio= n as painless as email signing. I want to be able to encrypt an email messa= ge once, no matter how many recipients there are. An enterprise should be a= ble to decrypt employees' email to ensure there's no misbehavior. I want as= little "extra" supporting infrastructure as possible. I also want to minim= ize the amount of inter-organizational coordination required. What if sending an encrypted email required clients to contact an email key= gatekeeper (EKG)? The EKG issues one-time-use encryption keys to authorize= d senders, and releases the decryption key once (only) to each recipient. Detailed flow: When encryption is desired, the sender's email client formats a key request= to the EKG and signs it using the sender's email signing key. The key requ= est includes the recipient's email addresses, but not their public keys, wh= ich are unknown. If the EKG is configured to recognize the sender, it repli= es with: 1] an encryption key, encrypted with the sender's public email sig= ning key; and 2] a plaintext copy of the key request, signed by the EKG its= elf. The sender then decrypts the encryption key, encrypts the message and = attachments, and attaches the signed key request. Poof. The message is sent= . If the sender's client stores outgoing mail in a "sent mail" folder, the = stored copy must be encrypted using some other means. The EKG-signed key request includes: 1] a unique identifier for the encrypt= ion key; 2] contact info, so recipients can locate the EKG; and 3] of cours= e, the list of recipients (part of the original key request). The Sender's organization can decrypt the outbound email at a gateway by co= ntacting the EKG and retrieving the decryption key (which could be the same= as the encryption key if symmetric, or the other half of an asymmetric key= pair if not.) The recipient's organization (assuming different than sender's organization= ) cannot decrypt the inbound email at a gateway. The recipient's email client detects the EKG's signed key request attached = to the email. The EKG's signature is verified. The recipient's client uses = the recipient's email signing cert to sign the EKG-signed key request, and = sends to the EKG using the contact information provided. The EKG verifies the recipients' signature. The EKG verifies that the recip= ient's certificate contains an email address that is included as a recipien= t in the original key request. The EKG verifies its own signature. The EKG = encrypts the email's decryption key using the recipient's public email sign= ing key, and signs the response. The recipient verifies the signature (ensu= ring same EKG signed key request and decryption key request) and decrypts t= he message/attachments. If the message is to be stored, it must be re-encrypted in a locally recove= rable fashion, likely with the recipient's credentials. If the recipient's = organization is concerned about decrypting inbound email, the "locally reco= verable fashion" should allow authorized individuals/services access. The o= riginal ciphertext should not be stored after decryption, and the decryptio= n key must not be stored. Probably best not to get too psycho over this: th= e recipient can always cut and paste to some cleartext medium like word, or= take a screenshot. Reasonable assurance that clients keep things encrypted= when they're received encrypted is what we're after. The EKG keeps track of which recipients have requested the decryption key. = Recipients are allowed to request the key once and only once. When all reci= pients have requested the decryption key, that key must never be served out= again. The EKG should not re-use encryption keys for subsequent messages. Clearly, the EKG needs to be just as publicly available as the organization= 's mailserver. I do not believe there would need to be anything special in = DNS (no "EKG" records, etc.) To summarize: The EKG knows nothing about sen= ders or recipients other than what the certificates tell it. Encryption key= s for email messages are one-time-use, and shared among sender and all reci= pients. Recipients get decryption keys by having a certificate with a match= ing email address. No extra coordination is involved over and above the con= figuration necessary to verify email signatures. What do you think? Is there an obvious reason this hasn't been done before? Bryce --_000_82E7C9A01FD0764CACDD35D10F5DFB6E7E1094001FSN2MPN1046001_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Trevor, thanks for = the link.

 

I like the multiple wa= ys to authenticate to plasma servers, and of course your “late key bi= nding”. Sounds so much more professional than my version! In my quick= read, I was not able to locate how I would specify who gets access to the keys for my message, or whether that was bound to t= he message payload. Does the message contain an untamperable list of author= ized recipients?

 

I have some concerns a= bout the DRM, basically that I’d like to see it factored out into a s= eparate doc. To me, the point of encrypted messaging is to deliver content = to a specified party while preventing others from snooping. If I have concerns about what that party might do with the = content upon receipt, I shouldn’t be sending it to them in the first = place. You just can’t fix stupid.

 

But let’s say we= try to fix stupid. And we specify a perfect message DRM ecosystem. Screens= hots will likely still work. Cell phones with cameras can always still be p= ointed at the screen. Are you really comfortable stating that any situation has a “high”, “significant= 221;, or even “some” confidence that policy is enforced when ju= st about anyone can defeat the system with a keypress? Will users, after th= ey defeat it themselves? Will security officers?

 

Attachments. The perfe= ct DRM-compliant email client will have to decrypt the attachment payload a= nd hand it off to the application which recognizes it. At this point it has= been exported from the DRM system and you again must trust the other party will use it appropriately. Either tha= t, or assimilate every possible application which can process every possibl= e attachment into your DRM system. Such a system would be like “Ultra= violet for Everything”.

 

The solution to both o= f these drawbacks is “think before you send”, which is what you= should do if you’re dealing with sensitive data anyway. Simplifies t= he spec immensely, by providing a clear, well defined, easily understood user responsibility. Even an “Ultraviolet for Ever= ything” approach does not relieve the user of this responsibility. IM= HO, the design of a comprehensive DRM system for all content is a much diff= erent animal than just making sure the content is delivered reliably and protected from snooping. I recommend starting wi= th just secure transport and tackling DRM later.

 

Finally, a secure, sel= f-contained DRM system excludes open source software by definition. If anyo= ne can comment out the “enforcement code” then recompile, all c= onfidence is low. This is why open source blue ray players on Linux rely on cracking old codes: no one will give them “= good” codes. On the other hand, secure delivery of “no strings = attached” encrypted messages is something that open source can do ver= y well. Respecting this boundary line is an excellent reason to split the spec into transport and DRM.

 

Just some thoughts.

Bryce

 

From: Trevor F= reeman [mailto:trevor.freeman99@icloud.com]
Sent: Monday, June 01, 2015 10:49 PM
To: Nordgren, Bryce L -FS; endymail@ietf.org
Subject: RE: [Endymail] FW: Group/Enterprise encrypted email

 

Hi Bryce,

What you propose is ve= ry similar to the Plasma work. The Plasma server functions like a EKG as yo= u describe. We generalized the model more so we made authentication to the = Plasma server via user tokens so it is possible to support a broader set of authentication mechanisms and auth= entication levels e.g. Facebook or Google+, as well as PIV cards.  = ;Since we support user tokes we can also do Attribute Based Access Control = if the message contents warrant e.g. if the message has ITAR material.  There were a number of compares built a P= OC to show this works and interoperates.

Here is the requiremen= ts document if you are interested.

Doing late key binging= via an EKG does have a number of advantages over early key binding. It is = generally much more forgiving. It does not requires everybody to have encry= ption keys at send time. It scales better if you have a large number of recipients. It also does not require recipie= nt key escrow to prevent data loss if you lose your encryption key.  T= his main issue is the security and scope of the EKG key or keys.

Here is the draft if y= ou want to read more. https://datatracker.ietf.org/doc/draft-freeman-plasma-requirements/

 

Trevor

 

From: Endymail= [mailto:endymail-bounces@ietf= .org] On Behalf Of Nordgren, Bryce L -FS
Sent: Monday, June 01, 2015 10:42 AM
To: endymail@ietf.org
Subject: [Endymail] FW: Group/Enterprise encrypted email<= /span>

 

I was directed to this= list because I posted the following to [kitten]. I looked at the archives = here, and it seems that my proposed email key gatekeeper (run by the entity= providing the email account) may solve the key distribution problem for transit, both for point to point ops as w= ell as mailing lists.

 

No promises. It’= s not like I spend my life thinking about this stuff.

 

Bryce

 

From: Nordgren= , Bryce L -FS
Sent: Friday, May 29, 2015 4:36 PM
To: kitten@ietf.org
Subject: Group/Enterprise encrypted email

 

This is a “what if” message, centered ar= ound trying to make email encryption as painless as email signing. I want t= o be able to encrypt an email message once, no matter how many recipients t= here are. An enterprise should be able to decrypt employees’ email to ensure there’s no misbehavior. I want as l= ittle “extra” supporting infrastructure as possible. I also wan= t to minimize the amount of inter-organizational coordination required.

 

What if sending an encrypted email required clients = to contact an email key gatekeeper (EKG)? The EKG issues one-time-use encry= ption keys to authorized senders, and releases the decryption key once (onl= y) to each recipient.

 

Detailed flow:

 

When encryption is desired, the sender’s email= client formats a key request to the EKG and signs it using the sender̵= 7;s email signing key. The key request includes the recipient’s email= addresses, but not their public keys, which are unknown. If the EKG is configured to recognize the sender, it replies with: 1] an e= ncryption key, encrypted with the sender’s public email signing key; = and 2] a plaintext copy of the key request, signed by the EKG itself. The s= ender then decrypts the encryption key, encrypts the message and attachments, and attaches the signed key request.= Poof. The message is sent. If the sender’s client stores outgoing ma= il in a “sent mail” folder, the stored copy must be encrypted u= sing some other means.

 

The EKG-signed key request includes: 1] a unique ide= ntifier for the encryption key; 2] contact info, so recipients can locate t= he EKG; and 3] of course, the list of recipients (part of the original key = request).

 

The Sender’s organization can decrypt the outb= ound email at a gateway by contacting the EKG and retrieving the decryption= key (which could be the same as the encryption key if symmetric, or the ot= her half of an asymmetric keypair if not.)

 

The recipient’s organization (assuming differe= nt than sender’s organization) cannot decrypt the inbound email at a = gateway.

 

The recipient’s email client detects the EKG&#= 8217;s signed key request attached to the email. The EKG’s signature = is verified. The recipient’s client uses the recipient’s email = signing cert to sign the EKG-signed key request, and sends to the EKG using the contact information provided.

 

The EKG verifies the recipients’ signature. Th= e EKG verifies that the recipient’s certificate contains an email add= ress that is included as a recipient in the original key request. The EKG v= erifies its own signature. The EKG encrypts the email’s decryption key using the recipient’s public email sign= ing key, and signs the response. The recipient verifies the signature (ensu= ring same EKG signed key request and decryption key request) and decrypts t= he message/attachments.

 

If the message is to be stored, it must be re-encryp= ted in a locally recoverable fashion, likely with the recipient’s cre= dentials. If the recipient’s organization is concerned about decrypti= ng inbound email, the “locally recoverable fashion” should allow authorized individuals/services access. The original cipherte= xt should not be stored after decryption, and the decryption key must not b= e stored. Probably best not to get too psycho over this: the recipient can = always cut and paste to some cleartext medium like word, or take a screenshot. Reasonable assurance that clients = keep things encrypted when they’re received encrypted is what we̵= 7;re after.

 

The EKG keeps track of which recipients have request= ed the decryption key. Recipients are allowed to request the key once and o= nly once. When all recipients have requested the decryption key, that key m= ust never be served out again. The EKG should not re-use encryption keys for subsequent messages.<= /p>

 

Clearly, the EKG needs to be just as publicly availa= ble as the organization’s mailserver. I do not believe there would ne= ed to be anything special in DNS (no “EKG” records, etc.) To su= mmarize:  The EKG knows nothing about senders or recipients other than what the certificates tell it. Encryption keys for email messag= es are one-time-use, and shared among sender and all recipients. Recipients= get decryption keys by having a certificate with a matching email address.= No extra coordination is involved over and above the configuration necessary to verify email signatures.

 

What do you think? Is there an obvious reason this h= asn’t been done before?

 

Bryce

--_000_82E7C9A01FD0764CACDD35D10F5DFB6E7E1094001FSN2MPN1046001_-- From nobody Tue Jun 2 19:28:11 2015 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8F61B32C9 for ; Tue, 2 Jun 2015 19:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.521 X-Spam-Level: X-Spam-Status: No, score=0.521 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 PEgxA1cn4VVT for ; Tue, 2 Jun 2015 19:28:08 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 648451B32C8 for ; Tue, 2 Jun 2015 19:28:08 -0700 (PDT) Received: by qgep100 with SMTP id p100so4553408qge.3 for ; Tue, 02 Jun 2015 19:28:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IhrKdjvyedRUIT1/9OHnyGlcgNgiOyiTzblPES3ZYjg=; b=TY7LdVFtE7nK0FYcHrEnLb2ir4ZA4LWd6prWGkBgLDreAfODLcQqWYvb+EQJtk3Q2m I/eVz49bR4bFcksSEfFh3eVssIbJaFFgWBVkp6Gt4bKE/Hzws0FZH2dwrM//NHI9/Avi cy8RIOM9uax/I+9SvudLJx8KdGEZ6K1pxPOpw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IhrKdjvyedRUIT1/9OHnyGlcgNgiOyiTzblPES3ZYjg=; b=hAwxMhLZIlDTb5JvsQI3azq/7SQZchjM3VHrHuRtM/ANnE2Huq9mBSaKzV4FYdDnkJ F2m2J2xXQOJpcMZFsiChQz5GccWmZ8Da3UWYpyjMjjyT2MeoDwEEZ7D99iRJ3ktYmJ+n Tc3L0o3h7j/gE/cnqdr7W263S2yCzirc4fZ3m+jYr/X6otRkrvMOgsJn0DnU4BwjPDq2 E5hGSodx68XUo/piC1UexTD3n0Lt/Gj4UJKLblZHvdHYuMCxyaqjLo8MFPjlmK9LEvuX GA91xnTUwe/mWT1p5Bcw4cnDeSvqCiin8Ei/rpu6+8MCwtXff/iP4hXCngIdoNdnf6lC a/hQ== X-Gm-Message-State: ALoCoQkYjQWXumRXObhz5sChulPaoRt3a3EYncgSbILWz1cdLSC6yo1JWIDymGqoJRSP0sWfTFYE MIME-Version: 1.0 X-Received: by 10.55.16.200 with SMTP id 69mr9507507qkq.98.1433298487691; Tue, 02 Jun 2015 19:28:07 -0700 (PDT) Received: by 10.140.51.103 with HTTP; Tue, 2 Jun 2015 19:28:07 -0700 (PDT) In-Reply-To: References: Date: Tue, 2 Jun 2015 21:28:07 -0500 Message-ID: From: Tom Ritter To: Watson Ladd Content-Type: multipart/alternative; boundary=001a113ac574376138051793cf00 Archived-At: Cc: endymail Subject: [Endymail] Why S/MIME and OpenPGP ecosystems fall short X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 02:28:10 -0000 --001a113ac574376138051793cf00 Content-Type: text/plain; charset=ISO-8859-1 I'm a big fan of TextSecure, but comparing TS and Email ignores many of the difficult problems TS has been able to dodge that email cannot. The biggest one I'll put forth is Key Authenticity[0]. I'm not talking about the fingerprint comparisons (they're about the same there.) In TS, I ask the central TS server "What's the key for Watson Ladd <1 555 123 4567>" and it gives me a key that I can reasonably believe is yours. TS is the central authority. Email's central authority would obviously be federated at the provider, but now we're gated on our email providers supporting some sort of Key Directory. Google and Yahoo are going to do this, but that doesn't solve the problem for everyone. This was solved for DNSSEC with the DLV - a central authority everyone agreed was able to provide you with a server's keys. Who will be the Email Lookaside Vector? Who will everyone agree to trust? There are other very difficult problems TS dodges, but an email solution must confront immediately. To be honest I'm not entirely certain TS' current mechanism for resolving some of these, maybe someone more familiar with TS' implementation can comment? - Multi-Device. TS is by-and-large single device. I thought at some point they had support for multi-devices - and I thought that worked by me giving the central directory multiple keys, and senders encrypted to all of them. I assume the central directory authenticated the user using the user's phone number. When people envision seemless email encryption they usually envision it detecting that the recipient has a key and either prompting the sender to encrypt or just encrypting automatically. - Privacy. TS sends your entire address book to the server and tells you which contacts have TS. Are we going to do this for email? Or are we going to do per-email queries? How does it handle the "user is composing offline" case? In TS, you can't send a message to someone who doesn't have a key - that problem doesn't exist. I'm confident there are others, I half-composed a few more, but I'll leave them to another time. On 2 June 2015 at 00:07, Watson Ladd wrote: > It's clear to me that this isn't easily fixable by standards work > alone I agree. > much of the damage is baked in to the functioning of S/MIME and > PGP. I'm not sure I agree with this point though. PGP at least is flexible enough that you don't care about interoperability, you can select a subset of functionality and build your system on top of that. And then if you reach critical mass, you can make people want to interoperate with *you*. Which is basically what Google did, Yahoo followed suite, and if they succeed as much as they wish to - we will in turn follow. > What needs to happen is that we need to come up with good ideas > around key management that are actually deployable, and provide the > semantics people want. I agree-ish. I think we need to come up with good implementations and user experiences of key management - not just ideas. -tom [0] I say Authenticity instead of Discovery, because one can reasonably point to a Keyserver and say "Discovery is solved." But the on the scale of Authenticity, keyservers have zero, and a central directory has "some, but not all". --001a113ac574376138051793cf00 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm a big fan of TextSecure, bu= t comparing TS and Email ignores many of the difficult problems TS has been= able to dodge that email cannot.

The biggest one I'll put forth is Key Authenticity[0].=A0 = I'm not talking about the fingerprint comparisons (they're about th= e same there.) In TS, I ask the central TS server "What's the key = for Watson Ladd <1 555 123 4567>" and it gives me a key that I c= an reasonably believe is yours. TS is the central authority.

= Email's central authority would= obviously=A0be federated at the provider, but now we're gated on our ema= il providers supporting some sort of Key Directory. Google and Yahoo are go= ing to do this, but that doesn't solve the problem for everyone. This w= as solved for DNSSEC with the DLV - a central authority everyone agreed was= able to provide you with a server's keys. Who will be the Email Lookas= ide Vector? Who will everyone agree to trust?=A0

There are other very difficult problems TS dod= ges, but an email solution must confront immediately.=A0 To be honest I'= ;m not entirely certain TS' current mechanism for resolving some of the= se, maybe someone more familiar with TS' implementation can comment?

- Multi-Device. TS is b= y-and-large single device. I thought at some point they had support for mul= ti-devices - and I thought that worked by me giving the central directory m= ultiple keys, and senders encrypted to all of them. I assume the central di= rectory authenticated the user using the user's phone number.=A0=

When people envision seemless email encrypt= ion they usually envision it detecting that the recipient has a key and eit= her prompting the sender to encrypt or just encrypting automatically.=A0

- Privacy. TS sends your entire a= ddress book to the server and tells you which contacts have TS. Are we goin= g to do this for email? Or are we going to do per-email queries? How does i= t handle the "user is composing offline" case?=A0 In TS,=A0you can't send a message to so= meone who doesn't have a key - that problem doesn't exist.

I'm confident there are others, I h= alf-composed a few more, but I'll leave them to another time.

On 2 June 20= 15 at 00:07, Watson Ladd <watsonbladd@gmail.com> wrote:=
> It's clear to me that = this isn't easily fixable by standards work
> alone

I agree.
<= div style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:sma= ll">
> much of the damage is baked in to the functioning o= f S/MIME and
> PGP.=A0

I'm not sure I ag= ree with this point though.=A0 PGP at least is flexible enough that you don= 't care about interoperability, you can select a subset of functionalit= y and build your system on top of that.=A0 And then if you reach critical m= ass, you can make people want to interoperate with *you*.=A0 Which is basic= ally what Google did, Yahoo followed suite, and if they succeed as much as = they wish to - we will in turn follow.

> What n= eeds to happen is that we need to come up with good ideas
> around ke= y management that are actually deployable, and provide the
> semantic= s people want.

I agree-ish.=A0 I think we need to come up with good = implementations and user experiences of key management - not just ideas.
-tom

[0] I say Authenticity instead of Discovery, because one c= an reasonably point to a Keyserver and say "Discovery is solved."= =A0But the on the scale of Authenticity, keyservers have zero, and a centr= al directory has "some, but not all".
--001a113ac574376138051793cf00-- From nobody Wed Jun 3 02:59:37 2015 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059D91A00DF for ; Wed, 3 Jun 2015 02:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.049 X-Spam-Level: ** X-Spam-Status: No, score=2.049 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 QtaWJeLO6C7O for ; Wed, 3 Jun 2015 02:59:34 -0700 (PDT) Received: from nekare.kjorling.se (nekare.kjorling.se [89.221.249.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F33D81A0087 for ; Wed, 3 Jun 2015 02:59:33 -0700 (PDT) Received: by nekare.kjorling.se (Postfix, from userid 1001) id 8A2E6114083; Wed, 3 Jun 2015 09:59:31 +0000 (UTC) X-Spam-Details: BAYES_00=-1.9, SPF_FAIL=0.001, T_FILL_THIS_FORM_SHORT=0.01 (nekare.kjorling.se) Received: from yeono.kjorling.se (h-9-65.a328.priv.bahnhof.se [46.59.9.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "yeono", Issuer "yeono" (not verified)) by nekare.kjorling.se (Postfix) with ESMTPS id BB98C114073 for ; Wed, 3 Jun 2015 09:59:19 +0000 (UTC) Received: from yeono.kjorling.se (localhost [127.0.0.1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by yeono (Postfix) with ESMTPS id 7913A17F1 for ; Wed, 3 Jun 2015 11:59:19 +0200 (CEST) Date: Wed, 3 Jun 2015 09:59:17 +0000 From: Michael =?utf-8?B?S2rDtnJsaW5n?= To: endymail@ietf.org Message-ID: <20150603095917.GC25546@yeono.kjorling.se> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [Endymail] Why S/MIME and OpenPGP ecosystems fall short X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 09:59:36 -0000 On 1 Jun 2015 22:07 -0700, from watsonbladd@gmail.com (Watson Ladd): > Compare to what happens with GPG. Immediately the user is asked to > make important choices with no guidance. Key discover is separate > step. When sending messages, they have to choose several orders of > operations and ciphers, with the wrong choice having consequences. I > don't think any choices have the right semantics. A lot of this has > been ruled out of scope as UI issues, but I don't think so: I think > that solving these issues require removing many of the problems that > we expose to users. Certainly some plugins do a very good job of > fixing some of these headaches, but I don't think any of them are as > reliable as TextSecure. I have absolutely zero experience with TextSecure so cannot compare against that, but are you talking about the _protocols and standards_ (OpenPGP) or the _implementation_ (GnuPG, PGP) in the above? GnuPG is somewhat technical, but OpenPGP does not have to be exposed that way to the user. We can fix the _implementation_ by making sure the defaults offered are reasonable and secure (according to current knowledge, adjusting over time as necessary and maintaining a margin for error) and adding a very first step asking whether the user wants a simple or advanced key generation process. The simple process would use those default values and only prompt the user for what is specifically needed (perhaps only their name, email address and desired passphrase); the advanced process would allow the user to select algorithm, key size, etc just like the normal key generation process in GnuPG does today. This would be reasonable because _the defaults should already be reasonably safe_; if they aren't, then they should be adjusted. The simple process could even start out by generating a small, throwaway key pair (say, perhaps, a 256-bit RSA key pair) with a short generation wallclock timeout _to determine the system's performance_ and adjust the key length to be generated upwards if the system is fast enough to handle generating and using a longer key pair. _For example_, set the default to RSA encrypt+sign with a 2048 bit modulus, but if the system is fast enough to _generate_ a 256 bit RSA key pair within, say, 200 ms, _then_ use 3072 bits instead; if 100 ms, _then_ 4096 bits instead. (Modulus lengths and timings are arbitrary and for example purposes only.) This will allow the software to gracefully move toward longer keys when the system is fast enough to handle them, without needing modification later, at the cost of a small amount of entropy (which could in principle be fed back into the system PRNG). With something like that, we remove at least _one_ of the major obstacles you (quite rightly) point out, namely the user immediately being confronted with the choice of (in my case) RSA/RSA (sign/encrypt), DSA/ElGamal, DSA (sign only) and RSA (sign only), followed by picking a key size. If the current defaults (with GnuPG, dual-use RSA 2048 bits modulus) are reasonably sane then regular users don't need to be confronted with those choices and we don't compromise security compared to today, yet power users can be given the opportunity to shoot themselves in the foot (or pick a higher degree of security at the cost of some performance). This doesn't solve key distribution and discovery, but it should solve at least one part of key generation. -- Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) From nobody Wed Jun 3 11:01:11 2015 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2B81A1AE6 for ; Wed, 3 Jun 2015 11:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 CfHvH3MfRo4h for ; Wed, 3 Jun 2015 11:01:01 -0700 (PDT) Received: from mr11p24im-asmtp002.me.com (mr11p24im-asmtp002.me.com [17.110.78.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CAC61A1ADD for ; Wed, 3 Jun 2015 11:01:01 -0700 (PDT) Received: from denhp (c-24-17-210-106.hsd1.wa.comcast.net [24.17.210.106]) by mr11p24im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NPD00J0HRDF7K10@mr11p24im-asmtp002.me.com> for endymail@ietf.org; Wed, 03 Jun 2015 18:00:54 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-06-03_09:2015-06-03,2015-06-03,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1506030220 From: Trevor Freeman To: "'Nordgren, Bryce L -FS'" , endymail@ietf.org References: <82E7C9A01FD0764CACDD35D10F5DFB6E7DFBBD@001FSN2MPN1-046.001f.mgd2.msft.net> <000d01d09cef$76039f10$620add30$@icloud.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7E1094@001FSN2MPN1-046.001f.mgd2.msft.net> In-reply-to: <82E7C9A01FD0764CACDD35D10F5DFB6E7E1094@001FSN2MPN1-046.001f.mgd2.msft.net> Date: Wed, 03 Jun 2015 11:00:52 -0700 Message-id: <007001d09e27$3c3083f0$b4918bd0$@icloud.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="----=_NextPart_000_0071_01D09DEC.8FD44400" X-Mailer: Microsoft Outlook 14.0 Thread-index: AQI4r1yN6a8adADhwF3Fb1Vfc9FNLwJxMimUAfuiTKCcp4EawA== Content-language: en-us Archived-At: Subject: Re: [Endymail] FW: Group/Enterprise encrypted email X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 18:01:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0071_01D09DEC.8FD44400 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Bryce, The technical specs are in a separate draft. We modified S/MIME but there is nothing to stop this being applied to PGP. https://datatracker.ietf.org/doc/draft-schaad-plasma-cms/ The Plasma token which is generated by the EKG s bound to the message by a detached signature. The token has an encrypted payload which can contain policy dependent metadata such as a recipient list. Not all polices require a receipt list. Plasma does not attempt DRM in that it places no technical obligations on the receipt when we release the decryption key. SMIME or PGP encryption is Identity Based Access Control since the sender is authorizing the receipt based on the identity binding to the key. We were putting email based content on par with content which was published via the web. So if you wanted to send content covered by a policy, you would get the same protection and policy enforcement as if you published via the web. This is not about fixing stupid, its more not requiring clairvoyance about every recipient. Another aspect is Plasma allows for device attributes so before we release the decryption key we can requires information about the state of the environment. That way if the recipient is infected, we can block decryption which is another plus for late binding. Again his is option so for low assurance polices you probably not care. Plasma can also handle multiple polices on a single message so if there were mixed content, we can selectively release keys i.e. it allows for auto redaction. Trevor From: Endymail [mailto:endymail-bounces@ietf.org] On Behalf Of Nordgren, Bryce L -FS Sent: Tuesday, June 02, 2015 11:53 AM To: Trevor Freeman; endymail@ietf.org Subject: Re: [Endymail] FW: Group/Enterprise encrypted email Hi Trevor, thanks for the link. I like the multiple ways to authenticate to plasma servers, and of course your "late key binding". Sounds so much more professional than my version! In my quick read, I was not able to locate how I would specify who gets access to the keys for my message, or whether that was bound to the message payload. Does the message contain an untamperable list of authorized recipients? I have some concerns about the DRM, basically that I'd like to see it factored out into a separate doc. To me, the point of encrypted messaging is to deliver content to a specified party while preventing others from snooping. If I have concerns about what that party might do with the content upon receipt, I shouldn't be sending it to them in the first place. You just can't fix stupid. But let's say we try to fix stupid. And we specify a perfect message DRM ecosystem. Screenshots will likely still work. Cell phones with cameras can always still be pointed at the screen. Are you really comfortable stating that any situation has a "high", "significant", or even "some" confidence that policy is enforced when just about anyone can defeat the system with a keypress? Will users, after they defeat it themselves? Will security officers? Attachments. The perfect DRM-compliant email client will have to decrypt the attachment payload and hand it off to the application which recognizes it. At this point it has been exported from the DRM system and you again must trust the other party will use it appropriately. Either that, or assimilate every possible application which can process every possible attachment into your DRM system. Such a system would be like "Ultraviolet for Everything". The solution to both of these drawbacks is "think before you send", which is what you should do if you're dealing with sensitive data anyway. Simplifies the spec immensely, by providing a clear, well defined, easily understood user responsibility. Even an "Ultraviolet for Everything" approach does not relieve the user of this responsibility. IMHO, the design of a comprehensive DRM system for all content is a much different animal than just making sure the content is delivered reliably and protected from snooping. I recommend starting with just secure transport and tackling DRM later. Finally, a secure, self-contained DRM system excludes open source software by definition. If anyone can comment out the "enforcement code" then recompile, all confidence is low. This is why open source blue ray players on Linux rely on cracking old codes: no one will give them "good" codes. On the other hand, secure delivery of "no strings attached" encrypted messages is something that open source can do very well. Respecting this boundary line is an excellent reason to split the spec into transport and DRM. Just some thoughts. Bryce From: Trevor Freeman [mailto:trevor.freeman99@icloud.com] Sent: Monday, June 01, 2015 10:49 PM To: Nordgren, Bryce L -FS; endymail@ietf.org Subject: RE: [Endymail] FW: Group/Enterprise encrypted email Hi Bryce, What you propose is very similar to the Plasma work. The Plasma server functions like a EKG as you describe. We generalized the model more so we made authentication to the Plasma server via user tokens so it is possible to support a broader set of authentication mechanisms and authentication levels e.g. Facebook or Google+, as well as PIV cards. Since we support user tokes we can also do Attribute Based Access Control if the message contents warrant e.g. if the message has ITAR material. There were a number of compares built a POC to show this works and interoperates. Here is the requirements document if you are interested. Doing late key binging via an EKG does have a number of advantages over early key binding. It is generally much more forgiving. It does not requires everybody to have encryption keys at send time. It scales better if you have a large number of recipients. It also does not require recipient key escrow to prevent data loss if you lose your encryption key. This main issue is the security and scope of the EKG key or keys. Here is the draft if you want to read more. https://datatracker.ietf.org/doc/draft-freeman-plasma-requirements/ Trevor From: Endymail [mailto:endymail-bounces@ietf.org] On Behalf Of Nordgren, Bryce L -FS Sent: Monday, June 01, 2015 10:42 AM To: endymail@ietf.org Subject: [Endymail] FW: Group/Enterprise encrypted email I was directed to this list because I posted the following to [kitten]. I looked at the archives here, and it seems that my proposed email key gatekeeper (run by the entity providing the email account) may solve the key distribution problem for transit, both for point to point ops as well as mailing lists. No promises. It's not like I spend my life thinking about this stuff. Bryce From: Nordgren, Bryce L -FS Sent: Friday, May 29, 2015 4:36 PM To: kitten@ietf.org Subject: Group/Enterprise encrypted email This is a "what if" message, centered around trying to make email encryption as painless as email signing. I want to be able to encrypt an email message once, no matter how many recipients there are. An enterprise should be able to decrypt employees' email to ensure there's no misbehavior. I want as little "extra" supporting infrastructure as possible. I also want to minimize the amount of inter-organizational coordination required. What if sending an encrypted email required clients to contact an email key gatekeeper (EKG)? The EKG issues one-time-use encryption keys to authorized senders, and releases the decryption key once (only) to each recipient. Detailed flow: When encryption is desired, the sender's email client formats a key request to the EKG and signs it using the sender's email signing key. The key request includes the recipient's email addresses, but not their public keys, which are unknown. If the EKG is configured to recognize the sender, it replies with: 1] an encryption key, encrypted with the sender's public email signing key; and 2] a plaintext copy of the key request, signed by the EKG itself. The sender then decrypts the encryption key, encrypts the message and attachments, and attaches the signed key request. Poof. The message is sent. If the sender's client stores outgoing mail in a "sent mail" folder, the stored copy must be encrypted using some other means. The EKG-signed key request includes: 1] a unique identifier for the encryption key; 2] contact info, so recipients can locate the EKG; and 3] of course, the list of recipients (part of the original key request). The Sender's organization can decrypt the outbound email at a gateway by contacting the EKG and retrieving the decryption key (which could be the same as the encryption key if symmetric, or the other half of an asymmetric keypair if not.) The recipient's organization (assuming different than sender's organization) cannot decrypt the inbound email at a gateway. The recipient's email client detects the EKG's signed key request attached to the email. The EKG's signature is verified. The recipient's client uses the recipient's email signing cert to sign the EKG-signed key request, and sends to the EKG using the contact information provided. The EKG verifies the recipients' signature. The EKG verifies that the recipient's certificate contains an email address that is included as a recipient in the original key request. The EKG verifies its own signature. The EKG encrypts the email's decryption key using the recipient's public email signing key, and signs the response. The recipient verifies the signature (ensuring same EKG signed key request and decryption key request) and decrypts the message/attachments. If the message is to be stored, it must be re-encrypted in a locally recoverable fashion, likely with the recipient's credentials. If the recipient's organization is concerned about decrypting inbound email, the "locally recoverable fashion" should allow authorized individuals/services access. The original ciphertext should not be stored after decryption, and the decryption key must not be stored. Probably best not to get too psycho over this: the recipient can always cut and paste to some cleartext medium like word, or take a screenshot. Reasonable assurance that clients keep things encrypted when they're received encrypted is what we're after. The EKG keeps track of which recipients have requested the decryption key. Recipients are allowed to request the key once and only once. When all recipients have requested the decryption key, that key must never be served out again. The EKG should not re-use encryption keys for subsequent messages. Clearly, the EKG needs to be just as publicly available as the organization's mailserver. I do not believe there would need to be anything special in DNS (no "EKG" records, etc.) To summarize: The EKG knows nothing about senders or recipients other than what the certificates tell it. Encryption keys for email messages are one-time-use, and shared among sender and all recipients. Recipients get decryption keys by having a certificate with a matching email address. No extra coordination is involved over and above the configuration necessary to verify email signatures. What do you think? Is there an obvious reason this hasn't been done before? Bryce ------=_NextPart_000_0071_01D09DEC.8FD44400 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Bryce,

The technical specs are = in a separate draft. We modified S/MIME but there is nothing to stop = this being applied to PGP.

https:= //datatracker.ietf.org/doc/draft-schaad-plasma-cms/=

 

The Plasma token which = is generated by the EKG s bound to the message by a detached signature. = The token has an encrypted payload which can contain policy dependent = metadata such as a recipient list. Not all polices require a receipt = list.

Plasma does not attempt DRM in that it places no = technical obligations on the receipt when we release the decryption key. = SMIME or PGP encryption is Identity Based Access Control since the = sender is authorizing the receipt based on the identity binding to the = key. We were putting email based content on par with content which was = published via the web.  So if you wanted to send content covered by = a policy, you would get the same protection and policy enforcement as if = you published via the web. This is not about fixing stupid, its more not = requiring clairvoyance about every recipient.

 

Another aspect is Plasma = allows for device attributes so before we release the decryption key we = can requires information about the state of the environment. That way if = the recipient is infected, we can block decryption which is another plus = for late binding. Again his is option so for low assurance polices you = probably not care.

 

Plasma can also handle = multiple polices on a single message so if there were mixed content, we = can selectively release keys i.e. it allows for auto redaction. =

 

Trevor

 

From:= = Endymail [mailto:endymail-bounces@ietf.org] On Behalf Of = Nordgren, Bryce L -FS
Sent: Tuesday, June 02, 2015 11:53 = AM
To: Trevor Freeman; endymail@ietf.org
Subject: = Re: [Endymail] FW: Group/Enterprise encrypted = email

 

Hi Trevor, thanks for the = link.

 

I like the multiple ways = to authenticate to plasma servers, and of course your “late key = binding”. Sounds so much more professional than my version! In my = quick read, I was not able to locate how I would specify who gets access = to the keys for my message, or whether that was bound to the message = payload. Does the message contain an untamperable list of authorized = recipients?

 

I have some concerns = about the DRM, basically that I’d like to see it factored out into = a separate doc. To me, the point of encrypted messaging is to deliver = content to a specified party while preventing others from snooping. If I = have concerns about what that party might do with the content upon = receipt, I shouldn’t be sending it to them in the first place. You = just can’t fix stupid.

 

But let’s say we = try to fix stupid. And we specify a perfect message DRM ecosystem. = Screenshots will likely still work. Cell phones with cameras can always = still be pointed at the screen. Are you really comfortable stating that = any situation has a “high”, “significant”, or = even “some” confidence that policy is enforced when just = about anyone can defeat the system with a keypress? Will users, after = they defeat it themselves? Will security = officers?

 

Attachments. The perfect = DRM-compliant email client will have to decrypt the attachment payload = and hand it off to the application which recognizes it. At this point it = has been exported from the DRM system and you again must trust the other = party will use it appropriately. Either that, or assimilate every = possible application which can process every possible attachment into = your DRM system. Such a system would be like “Ultraviolet for = Everything”.

 

The solution to both of = these drawbacks is “think before you send”, which is what = you should do if you’re dealing with sensitive data anyway. = Simplifies the spec immensely, by providing a clear, well defined, = easily understood user responsibility. Even an “Ultraviolet for = Everything” approach does not relieve the user of this = responsibility. IMHO, the design of a comprehensive DRM system for all = content is a much different animal than just making sure the content is = delivered reliably and protected from snooping. I recommend starting = with just secure transport and tackling DRM = later.

 

Finally, a secure, = self-contained DRM system excludes open source software by definition. = If anyone can comment out the “enforcement code” then = recompile, all confidence is low. This is why open source blue ray = players on Linux rely on cracking old codes: no one will give them = “good” codes. On the other hand, secure delivery of = “no strings attached” encrypted messages is something that = open source can do very well. Respecting this boundary line is an = excellent reason to split the spec into transport and = DRM.

 

Just some = thoughts.

Bryce

 

From:= = Trevor Freeman [mailto:trevor.freeman99@iclou= d.com]
Sent: Monday, June 01, 2015 10:49 PM
To: = Nordgren, Bryce L -FS; endymail@ietf.org
Subject: RE: [Endymail] FW: Group/Enterprise encrypted = email

 

Hi Bryce,

What you propose is very = similar to the Plasma work. The Plasma server functions like a EKG as = you describe. We generalized the model more so we made authentication to = the Plasma server via user tokens so it is possible to support a broader = set of authentication mechanisms and authentication levels e.g. Facebook = or Google+, as well as PIV cards.  Since we support user tokes we = can also do Attribute Based Access Control if the message contents = warrant e.g. if the message has ITAR material.  There were a number = of compares built a POC to show this works and interoperates. =

Here is the requirements document if you are = interested.

Doing late key binging via an EKG does have a = number of advantages over early key binding. It is generally much more = forgiving. It does not requires everybody to have encryption keys at = send time. It scales better if you have a large number of recipients. It = also does not require recipient key escrow to prevent data loss if you = lose your encryption key.  This main issue is the security and = scope of the EKG key or keys.

Here is the draft if you = want to read more. https://datatracker.ietf.org/doc/draft-freeman-plasma-requirements/

 

Trevor

 

From:= = Endymail [mailto:endymail-bounces@ietf.or= g] On Behalf Of Nordgren, Bryce L -FS
Sent: Monday, = June 01, 2015 10:42 AM
To: endymail@ietf.org
Subject: [Endymail] FW: Group/Enterprise encrypted = email

 

I was directed to this list because I posted the = following to [kitten]. I looked at the archives here, and it seems that = my proposed email key gatekeeper (run by the entity providing the email = account) may solve the key distribution problem for transit, both for = point to point ops as well as mailing lists.

 

No promises. It’s = not like I spend my life thinking about this = stuff.

 

Bryce

 

From:= = Nordgren, Bryce L -FS
Sent: Friday, May 29, 2015 4:36 = PM
To: kitten@ietf.org
Subject: = Group/Enterprise encrypted email

 

This is a = “what if” message, centered around trying to make email = encryption as painless as email signing. I want to be able to encrypt an = email message once, no matter how many recipients there are. An = enterprise should be able to decrypt employees’ email to ensure = there’s no misbehavior. I want as little “extra” = supporting infrastructure as possible. I also want to minimize the = amount of inter-organizational coordination required.

 

What if = sending an encrypted email required clients to contact an email key = gatekeeper (EKG)? The EKG issues one-time-use encryption keys to = authorized senders, and releases the decryption key once (only) to each = recipient.

 

Detailed flow:

 

When = encryption is desired, the sender’s email client formats a key = request to the EKG and signs it using the sender’s email signing = key. The key request includes the recipient’s email addresses, but = not their public keys, which are unknown. If the EKG is configured to = recognize the sender, it replies with: 1] an encryption key, encrypted = with the sender’s public email signing key; and 2] a plaintext = copy of the key request, signed by the EKG itself. The sender then = decrypts the encryption key, encrypts the message and attachments, and = attaches the signed key request. Poof. The message is sent. If the = sender’s client stores outgoing mail in a “sent mail” = folder, the stored copy must be encrypted using some other = means.

 

The EKG-signed key request includes: 1] a unique = identifier for the encryption key; 2] contact info, so recipients can = locate the EKG; and 3] of course, the list of recipients (part of the = original key request).

 

The = Sender’s organization can decrypt the outbound email at a gateway = by contacting the EKG and retrieving the decryption key (which could be = the same as the encryption key if symmetric, or the other half of an = asymmetric keypair if not.)

 

The = recipient’s organization (assuming different than sender’s = organization) cannot decrypt the inbound email at a gateway. =

 

The recipient’s email client detects the = EKG’s signed key request attached to the email. The EKG’s = signature is verified. The recipient’s client uses the = recipient’s email signing cert to sign the EKG-signed key request, = and sends to the EKG using the contact information provided. =

 

The EKG verifies the recipients’ signature. The = EKG verifies that the recipient’s certificate contains an email = address that is included as a recipient in the original key request. The = EKG verifies its own signature. The EKG encrypts the email’s = decryption key using the recipient’s public email signing key, and = signs the response. The recipient verifies the signature (ensuring same = EKG signed key request and decryption key request) and decrypts the = message/attachments.

 

If the = message is to be stored, it must be re-encrypted in a locally = recoverable fashion, likely with the recipient’s credentials. If = the recipient’s organization is concerned about decrypting inbound = email, the “locally recoverable fashion” should allow = authorized individuals/services access. The original ciphertext should = not be stored after decryption, and the decryption key must not be = stored. Probably best not to get too psycho over this: the recipient can = always cut and paste to some cleartext medium like word, or take a = screenshot. Reasonable assurance that clients keep things encrypted when = they’re received encrypted is what we’re = after.

 

The EKG keeps track of which recipients have requested = the decryption key. Recipients are allowed to request the key once and = only once. When all recipients have requested the decryption key, that = key must never be served out again. The EKG should not re-use encryption = keys for subsequent messages.

 

Clearly, the = EKG needs to be just as publicly available as the organization’s = mailserver. I do not believe there would need to be anything special in = DNS (no “EKG” records, etc.) To summarize:  The EKG = knows nothing about senders or recipients other than what the = certificates tell it. Encryption keys for email messages are = one-time-use, and shared among sender and all recipients. Recipients get = decryption keys by having a certificate with a matching email address. = No extra coordination is involved over and above the configuration = necessary to verify email signatures.

 

What do you = think? Is there an obvious reason this hasn’t been done before? =

 

Bryce

------=_NextPart_000_0071_01D09DEC.8FD44400-- From nobody Wed Jun 3 12:51:08 2015 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955801B2A01 for ; Wed, 3 Jun 2015 12:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 rwm-TlOirbD4 for ; Wed, 3 Jun 2015 12:51:05 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0619.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:619]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE1771ACE86 for ; Wed, 3 Jun 2015 12:49:51 -0700 (PDT) Received: from CO2PR06CA012.namprd06.prod.outlook.com (10.141.242.12) by BLUPR06MB1825.namprd06.prod.outlook.com (25.162.225.15) with Microsoft SMTP Server (TLS) id 15.1.172.22; Wed, 3 Jun 2015 19:49:32 +0000 Received: from BL2FFO11FD016.protection.gbl (2a01:111:f400:7c09::123) by CO2PR06CA012.outlook.office365.com (2a01:111:e400:142a::12) with Microsoft SMTP Server (TLS) id 15.1.184.17 via Frontend Transport; Wed, 3 Jun 2015 19:49:32 +0000 Authentication-Results: spf=pass (sender IP is 199.135.140.17) smtp.mailfrom=fs.fed.us; icloud.com; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of fs.fed.us designates 199.135.140.17 as permitted sender) receiver=protection.outlook.com; client-ip=199.135.140.17; helo=mail.usda.gov; Received: from mail.usda.gov (199.135.140.17) by BL2FFO11FD016.mail.protection.outlook.com (10.173.160.224) with Microsoft SMTP Server (TLS) id 15.1.184.11 via Frontend Transport; Wed, 3 Jun 2015 19:49:31 +0000 Received: from 001FSN2MPN1-046.001f.mgd2.msft.net ([169.254.6.131]) by 001FSN2MMR1-007.001f.mgd2.msft.net ([199.135.140.17]) with mapi id 14.03.0224.003; Wed, 3 Jun 2015 19:49:16 +0000 From: "Nordgren, Bryce L -FS" To: Trevor Freeman , "endymail@ietf.org" Thread-Topic: [Endymail] FW: Group/Enterprise encrypted email Thread-Index: AdCaU4EBKI9vXfbmSrKplnpcKmT5cgCPeK3wABeENQAAG8dZUAAyKjMAAADg6CA= Date: Wed, 3 Jun 2015 19:49:16 +0000 Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E7E154A@001FSN2MPN1-046.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7DFBBD@001FSN2MPN1-046.001f.mgd2.msft.net> <000d01d09cef$76039f10$620add30$@icloud.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7E1094@001FSN2MPN1-046.001f.mgd2.msft.net> <007001d09e27$3c3083f0$b4918bd0$@icloud.com> In-Reply-To: <007001d09e27$3c3083f0$b4918bd0$@icloud.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.7.27.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD016; 1:X7lpxzj12bW6o4xd8rgr2r0KLgqwwIgwwUPFaxAJqH09q9DTzBeaU6Ye/W+wBOiu9oh2AapfV3TLy07rGn3YI9x1IwkHH0N95/Rx3+ZpAl1EMjm1u/e8XM8rka4V2lZVhDo0Ar6CMEpbK6hziNuYGNf//zAHMP5gYvsT9zzIUxnoRVIoQGE581BRcRionhVD25k35J/PjQF7cCRzwr9oiyZyJBOpwmX+LSu3ZBxqlgIDl7Wtj28yP4hu5bbG3b2X7gLaDDQAuRts718HPParC3wDGsvB1ZvEGcNPVFAyJRo= X-Forefront-Antispam-Report: CIP:199.135.140.17; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(438002)(164054003)(199003)(189002)(46102003)(33656002)(189998001)(23726002)(26826002)(97736004)(86362001)(86146001)(4001540100001)(107886002)(5890100001)(104016003)(62966003)(106466001)(47776003)(5001770100001)(74482002)(5001960100002)(64706001)(2501003)(50466002)(66066001)(5001860100001)(54356999)(97756001)(81156007)(46406003)(77156002)(22746005)(102836002)(2656002)(15975445007)(68736005)(22756005)(87936001)(19580395003)(76176999)(69596002)(5001830100001)(92566002)(50986999)(93886004)(6806004)(2900100001)(55846006)(2950100001)(2920100001)(7059030)(14444003)(80862005)(79686002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1825; H:mail.usda.gov; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1825; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:BLUPR06MB1825; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1825; X-Forefront-PRVS: 05961EBAFC X-OriginatorOrg: fs.fed.us X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jun 2015 19:49:31.6753 (UTC) X-MS-Exchange-CrossTenant-Id: 49808c08-7df8-4c41-af62-7a0827de9408 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=49808c08-7df8-4c41-af62-7a0827de9408; Ip=[199.135.140.17]; Helo=[mail.usda.gov] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1825 Archived-At: Subject: Re: [Endymail] FW: Group/Enterprise encrypted email X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 19:51:07 -0000 Please forgive my organizations' utter reliance on an email client that can= 't even quote correctly. Not to mention it keeps trying to make hyperlinks = in a plain text message. > The technical specs are in a separate draft. We modified S/MIME but there= is nothing=20 > to stop this being applied to PGP. > https://datatracker.ietf.org/doc/draft-schaad-plasma-cms/ Thanks. I'll put it on my list. Is this the correct place to provide feedba= ck or is there another IETF list? >Plasma does not attempt DRM in that it places no technical obligations on = the receipt=20 >when we release the decryption key.=20 > ... > So if you wanted to send content covered by a policy, you would get the s= ame protection=20 > and policy enforcement as if you published via the web. I'm having a hard time wrapping my head around the notion of enforcement co= mingling with "no obligations on receipt" of the key. Enforcement is an obl= igation. > Not all polices require a receipt list. Why would you send something to someone if you weren't going to allow them = to decrypt it? If you need finer grained control than an email list affords= , perhaps an email list is not an appropriate solution. All email-related p= olicies should require a recipient list, and in addition the policy's list = should be synchronized with the email's recipient list (albeit, the policy = can refer to the same list of people by non email identifiers). It's probab= ly going to be hard enough just making sure that everyone's identifier some= how tracks back to their email address, and you're not giving away access t= o someone you didn't send the message to. Section 4.1 seems too centered on the end user's ISP. I have a few email ac= counts, none of which are from my ISP. (gmail, yahoo, work, etc.) Suggest c= hanging to "mail provider" or equivalent. >From section 4.4.1:=20 (5) Frank clicks the "send email" button. The client signs the email using his smart card private key and includes the certificate with the appropriate public key for verification of the signature by recipients. The client then encrypts the message and obtains a token for the message from a server that will enable the recipients' servers to enforce the access control requirements for Frank, and sends the email to his email server. Unless the client is encrypting with Frank's smart card private key, I thin= k it needs to contact "a server that will enable the recipients' servers to= enforce the access control requirements" to obtain the encryption key.=20 Editorial note: I think it would be helpful to define how many servers ther= e are, what they are called, and the role for each one then use that nomenc= lature consistently throughout the use cases. I know you outlined a "generi= c access control model", and include a vocabulary, but the list appears to = be missing the thing that makes and releases keys, which is kind of a corne= rstone of this architecture. I'm also somewhat unclear as to how many of th= e "xx xx Point" items are servers, and which are clients. (7) Once Grace has shown she passes the policy requirements, the PDEP releases the message Content Encryption Key (CEK) to Grace using her level 3 encryption certificate. Does the PDEP do all the key management? (e.g., does Frank contact the PDEP= to get a new key for his message?) (9) The CEK Grace received has a Time To Live (TTL) value which defines when Grace must discard the CEK and reapply for a new CEK. =20 I'd like to point out that an adversary would just keep the CEK. Or make a = plaintext/alternate ciphertext copy of the content while the CEK is still v= alid.=20 Even with well behaved actors, in the case of attachments, it is likely tha= t the attachment will have to be decrypted, saved on disk in plaintext, and= opened with an external application. They have a "forever" copy even when = the CEK expires. Why would they even notice that a CEK expired? It is probably worth stressing in security considerations that the only rat= ional assumption is: "once decrypted, always accessible". While the example= is designed to show that confidentiality policies change over time, the s= olution proposed by this system only allows for an expansion of the pool of= actors in possession of your sensitive data, never a reduction. Ever.=20 > Another aspect is Plasma allows for device attributes so before we=20 > release the decryption key we can requires information about the=20 > state of the environment. That way if the recipient is infected, we=20 > can block decryption which is another plus for late binding. Again=20 > his is option so for low assurance polices you probably not care.=20 For high assurance policies, I would assume infected/malicious clients to b= e lying. Particularly if they were not administered by me, and probably eve= n then. Should you ever expect any response other than "I'm healthy and you= can trust me!"? Am I missing something?=20 Thanks, Bryce From nobody Wed Jun 3 13:08:13 2015 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8462D1A6EE0 for ; Wed, 3 Jun 2015 13:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 F0mkQQ9KIEu4 for ; Wed, 3 Jun 2015 13:08:02 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01B021A90B3 for ; Wed, 3 Jun 2015 13:08:01 -0700 (PDT) Received: by labko7 with SMTP id ko7so16847717lab.2 for ; Wed, 03 Jun 2015 13:07:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=QgR1SppmSk89pJcd4q9EHpb+/4eaQMUXXm9jxjzpmX8=; b=GSpvJYWV55mYyYJNPclEv7KqbbsOu9SI0+Jle0BqfGcbWIm0pPd/IXPWFa7cKsW5WK cRsqJfGa3vlaoCbtf8oNE0zq8rQOJZjShJh2Sqft8JnjjJbQNG8XPQFSAOcxEhbWflSd h0QJoKtUrqn2/esdv5+vHTpEtVUTvpvBlcCTXTOpfPyyse5KehnkKA3DTyZt04YK8wHT zwD71lsaXGp/APn5LoHT95nV6Bqig+EZdp+Kdm0iq6LjdRzICsP2Fh1reSQD2bCLYKJA Z1tcMQCYQZ5keUcNlhc7/RfODKWN77VpHyL0PnrsA74YSxbWTXwzqpOIHc/22uNfvWOL S9zQ== MIME-Version: 1.0 X-Received: by 10.112.166.5 with SMTP id zc5mr19303830lbb.91.1433362079454; Wed, 03 Jun 2015 13:07:59 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Wed, 3 Jun 2015 13:07:59 -0700 (PDT) In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E7E154A@001FSN2MPN1-046.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7DFBBD@001FSN2MPN1-046.001f.mgd2.msft.net> <000d01d09cef$76039f10$620add30$@icloud.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7E1094@001FSN2MPN1-046.001f.mgd2.msft.net> <007001d09e27$3c3083f0$b4918bd0$@icloud.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7E154A@001FSN2MPN1-046.001f.mgd2.msft.net> Date: Wed, 3 Jun 2015 16:07:59 -0400 X-Google-Sender-Auth: DHGDukry1nH_v4Uw-UFA1B5U3ps Message-ID: From: Phillip Hallam-Baker To: "Nordgren, Bryce L -FS" Content-Type: multipart/alternative; boundary=001a11c26906949e950517a29d72 Archived-At: Cc: Trevor Freeman , "endymail@ietf.org" Subject: Re: [Endymail] FW: Group/Enterprise encrypted email X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 20:08:03 -0000 --001a11c26906949e950517a29d72 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 3, 2015 at 3:49 PM, Nordgren, Bryce L -FS wrote: > > I'm having a hard time wrapping my head around the notion of enforcement > comingling with "no obligations on receipt" of the key. Enforcement is an > obligation. Trevor sais 'no Technical obligations'. I think what he means here is that people who use this technology are probably going to use clients that make a best effort to not leak confidential bits but not require the use of trustworthy hardware that can provide technical enforcement. In other words, I can use a completely open source client modified in any way I like without having to get the executable signed by someone the rights owner trusts. In a corporate context, this makes perfect sense. If I am downloading company confidential material to my laptop, I want to be able to read it on the laptop but I don't want to accidentally send a copy to someone else by doing an unfortunate 'reply all'. --001a11c26906949e950517a29d72 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 3, 2015 at 3:49 PM, Nordgren, Bryce L -FS <bnordgren@fs.fed.us> wrote:
I'm having a hard time wrapping my head around the notion of enf= orcement comingling with "no obligations on receipt" of the key. = Enforcement is an obligation.

Trevor sais &= #39;no Technical obligations'. I think what he means here is that peopl= e who use this technology are probably going to use clients that make a bes= t effort to not leak confidential bits but not require the use of trustwort= hy hardware that can provide technical enforcement. In other words, I can u= se a completely open source client modified in any way I like without havin= g to get the executable signed by someone the rights owner trusts.




--001a11c26906949e950517a29d72-- From nobody Wed Jun 3 13:46:12 2015 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9371A9128 for ; Wed, 3 Jun 2015 13:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 R9BDVFG4A0aM for ; Wed, 3 Jun 2015 13:46:09 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0065.outbound.protection.outlook.com [207.46.100.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 066FE1A910F for ; Wed, 3 Jun 2015 13:46:08 -0700 (PDT) Received: from BY2PR06MB1831.namprd06.prod.outlook.com (25.163.33.145) by BY2PR06MB172.namprd06.prod.outlook.com (10.242.47.153) with Microsoft SMTP Server (TLS) id 15.1.172.22; Wed, 3 Jun 2015 20:46:08 +0000 Received: from BY2PR06CA033.namprd06.prod.outlook.com (10.141.250.151) by BY2PR06MB1831.namprd06.prod.outlook.com (25.163.33.145) with Microsoft SMTP Server (TLS) id 15.1.172.22; Wed, 3 Jun 2015 20:46:06 +0000 Received: from BY2FFO11FD014.protection.gbl (2a01:111:f400:7c0c::158) by BY2PR06CA033.outlook.office365.com (2a01:111:e400:2c60::23) with Microsoft SMTP Server (TLS) id 15.1.184.17 via Frontend Transport; Wed, 3 Jun 2015 20:46:06 +0000 Authentication-Results: spf=pass (sender IP is 199.135.140.15) smtp.mailfrom=fs.fed.us; hallambaker.com; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of fs.fed.us designates 199.135.140.15 as permitted sender) receiver=protection.outlook.com; client-ip=199.135.140.15; helo=mail.usda.gov; Received: from mail.usda.gov (199.135.140.15) by BY2FFO11FD014.mail.protection.outlook.com (10.1.14.76) with Microsoft SMTP Server (TLS) id 15.1.184.11 via Frontend Transport; Wed, 3 Jun 2015 20:46:05 +0000 Received: from 001FSN2MPN1-046.001f.mgd2.msft.net ([169.254.6.131]) by 001FSN2MMR1-005.001f.mgd2.msft.net ([199.135.140.15]) with mapi id 14.03.0224.003; Wed, 3 Jun 2015 20:45:29 +0000 From: "Nordgren, Bryce L -FS" To: Phillip Hallam-Baker Thread-Topic: [Endymail] FW: Group/Enterprise encrypted email Thread-Index: AdCaU4EBKI9vXfbmSrKplnpcKmT5cgCPeK3wABeENQAAG8dZUAAyKjMAAADg6CAAA4+bgAAAQ2EA Date: Wed, 3 Jun 2015 20:45:27 +0000 Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E7E159E@001FSN2MPN1-046.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7DFBBD@001FSN2MPN1-046.001f.mgd2.msft.net> <000d01d09cef$76039f10$620add30$@icloud.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7E1094@001FSN2MPN1-046.001f.mgd2.msft.net> <007001d09e27$3c3083f0$b4918bd0$@icloud.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7E154A@001FSN2MPN1-046.001f.mgd2.msft.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.7.27.143] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD014; 1:1X8wbwV8A80l8ewnXrdYur2kg40Pgt9ybaKjxaDcZEw+iXJxVRA10oPNxLtMymQhO5hDxJ1Dnai33QFkaj7XejyFbKdSeuLAnB6eUEUe7YKg1X6UIaYGDLUdYlr/qsMDpI1t8/s6J7eASdWhJmt/T3BlaZdPOncI2OQMACbAEeDrvsgq4Xo7F7/j4qcWMBcFdmY0/K65xKgY5B/u9MBKgUA718TVtf5uHBk6o1e8btwcuoQ5bnZtNUyR/IKJTlA2FAbXmv6hIfX0TUm8uqvOhrd04HxY7eM8qDK4fapjFCg= X-Forefront-Antispam-Report: CIP:199.135.140.15; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(438002)(189002)(199003)(2920100001)(66066001)(2900100001)(106466001)(86146001)(92566002)(47776003)(64706001)(22756005)(69596002)(102836002)(46102003)(2950100001)(68736005)(104016003)(5890100001)(22746005)(93886004)(74482002)(81156007)(50986999)(26826002)(86362001)(23676002)(76176999)(54356999)(33656002)(110136002)(189998001)(5001860100001)(2656002)(5001830100001)(62966003)(55846006)(5001960100002)(97736004)(6806004)(4001540100001)(87936001)(77156002)(50466002)(7059030)(80862005)(79686002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR06MB1831; H:mail.usda.gov; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR06MB1831; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR06MB172; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:BY2PR06MB1831; BCL:0; PCL:0; RULEID:; SRVR:BY2PR06MB1831; X-Forefront-PRVS: 05961EBAFC X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jun 2015 20:46:05.8433 (UTC) X-MS-Exchange-CrossTenant-Id: 49808c08-7df8-4c41-af62-7a0827de9408 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=49808c08-7df8-4c41-af62-7a0827de9408; Ip=[199.135.140.15]; Helo=[mail.usda.gov] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR06MB1831 X-OriginatorOrg: fs.fed.us Archived-At: Cc: Trevor Freeman , "endymail@ietf.org" Subject: Re: [Endymail] FW: Group/Enterprise encrypted email X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 20:46:10 -0000 PiBJbiBhIGNvcnBvcmF0ZSBjb250ZXh0LCB0aGlzIG1ha2VzIHBlcmZlY3Qgc2Vuc2UuIElmIEkg YW0gZG93bmxvYWRpbmcgY29tcGFueSBjb25maWRlbnRpYWwgDQo+IG1hdGVyaWFsIHRvIG15IGxh cHRvcCwgSSB3YW50IHRvIGJlIGFibGUgdG8gcmVhZCBpdCBvbiB0aGUgbGFwdG9wIGJ1dCBJIGRv bid0IHdhbnQgdG8gYWNjaWRlbnRhbGx5IA0KPiBzZW5kIGEgY29weSB0byBzb21lb25lIGVsc2Ug YnkgZG9pbmcgYW4gdW5mb3J0dW5hdGUgJ3JlcGx5IGFsbCcuDQoNClNvIGFub3RoZXIgdGhpbmcg dG8gbm90ZSBpbiBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBpcyB0aGF0IHRoaXMgaXMgYSBzY2hl bWUgaW50ZW5kZWQgdG8gcHJvdGVjdCB3ZWxsIGJlaGF2ZWQgYWN0b3JzIHdobyBoYXZlIGdvb2Qg aGFiaXRzIGFuZCBhbiBob25lc3Qgc29mdHdhcmUgZWNvc3lzdGVtIGZyb20gY2F1c2luZyBkYW1h Z2UgZHVlIHRvIHNwZWNpZmljIHNpbmdsZSBob25lc3QgbWlzdGFrZXMuIEl0IGlzIG5vdCBpbnRl bmRlZCB0byBwcm90ZWN0IGFnYWluc3QgYWR2ZXJzYXJpZXMsIHdlbGwgYmVoYXZlZCBhY3RvcnMg d2hvIGhhdmUgc2xvcHB5IGhhYml0cywgd2VsbCBiZWhhdmVkIGFjdG9ycyB3aG8gbWFrZSBtb3Jl IHRoYW4gb25lIG1pc3Rha2Ugb24gdGhlIHNhbWUgbWVzc2FnZSAocmVwbHkgYWxsICsgYXR0YWNo bWVudCB3aXRoIG5vIHRhZy9pbmFwcHJvcHJpYXRlIHRhZyksIG9yIHdlbGwgYmVoYXZlZCBhY3Rv cnMgd2hvIG1ha2UgYSBzaW5nbGUgbWlzdGFrZSBmcm9tIHdoaWNoIG11bHRpcGxlIGNvcnJlbGF0 ZWQgaW5jb3JyZWN0IGFjdGlvbnMgYXJlIGRlcml2ZWQgKG1pc2NsYXNzaWZ5IGNvbnRlbnQgLT4g aW5jb3JyZWN0IGNvbnRlbnQgdGFnL2luY29ycmVjdCBtYWlsaW5nIGxpc3QpLiANCg0KSW4gbGln aHQgb2YgdGhlc2UgdGhpbmdzLCBJIHRoaW5rIGFueSBsYW5ndWFnZSBhYm91dCAiZW5zdXJpbmcg dGhhdCBwb2xpY3kgaXMgZm9sbG93ZWQiIG9yIHRoZSBsaWtlIHNob3VsZCBqdXN0IGJlIGV4cHVu Z2VkLiBJZiB0aGUgdGFyZ2V0IGlzIHRvIGVuY291cmFnZSB3ZWxsLW1lYW5pbmcgcGFydG5lcnMg dG8gZG8gdGhlIGFjY2VwdGVkIHRoaW5nLCB0aGF0J3MgaG93IGl0IHNob3VsZCBiZSBwcmVzZW50 ZWQuDQoNCkJyeWNlDQoNCg0KDQoNCg0K From nobody Wed Jun 3 14:09:55 2015 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980541B2E62 for ; Wed, 3 Jun 2015 14:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.123 X-Spam-Level: X-Spam-Status: No, score=0.123 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 OF4g9183Vr86 for ; Wed, 3 Jun 2015 14:09:53 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E51631B2E61 for ; Wed, 3 Jun 2015 14:09:52 -0700 (PDT) Received: by labpy14 with SMTP id py14so17978145lab.0 for ; Wed, 03 Jun 2015 14:09:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=NfzeD3Ezeykjp85EVDRkL+M6nUgcxT7gcuvxDRinWlE=; b=z8i+SzGneNC0VJpNXUGsyOiK2EiU69F9QnC1YtrUqKiLEguMbD4HCs65cIXaXihZr0 a47dn3XYvgR878YYkTWIbtXTmUWpuTDylyBR5kBh8MipX89IREnrimhYd6NwOMTgYrEt khBZvnX2+Z8kQGbO0NPZ4Rdhn/1BRIQ3w0ybdqf1BxwC+GwuhwyLlskUGbGZ3YO1JXIq KTDZtEMGW+rbWPypm2FTnTqh7at9vPoboYbd1RfO55NESjYmW88mbA2Gb7FR2ySeHqam UoKdS2FIGvcGsaVQQ4MRLtkpWpe/JBHvNRdADWXHMB3vzQAE4kwc5iXx2yxL4K2TLAZl f/dw== MIME-Version: 1.0 X-Received: by 10.112.126.42 with SMTP id mv10mr27815843lbb.58.1433365791470; Wed, 03 Jun 2015 14:09:51 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Wed, 3 Jun 2015 14:09:51 -0700 (PDT) In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E7E159E@001FSN2MPN1-046.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7DFBBD@001FSN2MPN1-046.001f.mgd2.msft.net> <000d01d09cef$76039f10$620add30$@icloud.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7E1094@001FSN2MPN1-046.001f.mgd2.msft.net> <007001d09e27$3c3083f0$b4918bd0$@icloud.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7E154A@001FSN2MPN1-046.001f.mgd2.msft.net> <82E7C9A01FD0764CACDD35D10F5DFB6E7E159E@001FSN2MPN1-046.001f.mgd2.msft.net> Date: Wed, 3 Jun 2015 17:09:51 -0400 X-Google-Sender-Auth: 9yYQ6KTq5HyvItwV0EBgIu-WZhU Message-ID: From: Phillip Hallam-Baker To: "Nordgren, Bryce L -FS" Content-Type: multipart/alternative; boundary=001a11c36bc6d579f10517a37a28 Archived-At: Cc: Trevor Freeman , "endymail@ietf.org" Subject: Re: [Endymail] FW: Group/Enterprise encrypted email X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 21:09:54 -0000 --001a11c36bc6d579f10517a37a28 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 3, 2015 at 4:45 PM, Nordgren, Bryce L -FS wrote: > > In a corporate context, this makes perfect sense. If I am downloading > company confidential > > material to my laptop, I want to be able to read it on the laptop but I > don't want to accidentally > > send a copy to someone else by doing an unfortunate 'reply all'. > > So another thing to note in security considerations is that this is a > scheme intended to protect well behaved actors who have good habits and an > honest software ecosystem from causing damage due to specific single honest > mistakes. It is not intended to protect against adversaries, well behaved > actors who have sloppy habits, well behaved actors who make more than one > mistake on the same message (reply all + attachment with no > tag/inappropriate tag), or well behaved actors who make a single mistake > from which multiple correlated incorrect actions are derived (misclassify > content -> incorrect content tag/incorrect mailing list). > > In light of these things, I think any language about "ensuring that policy > is followed" or the like should just be expunged. If the target is to > encourage well-meaning partners to do the accepted thing, that's how it > should be presented. As I said to a former director of the NSA recently, the fact that Snowden and Manning had effectively unrestricted access to such a large amount of data is an indictment of both the institution and the approach to controlling information. The classification level of a document is a measure of the ego of the author/classifier, not how important it is to keep it secret. If keeping documents secret causes operational difficulties, people will not attach the security labels necessary to control them properly. Trying to absolutely control the flow of information has a lousy track record. And not just in the US but FOIA means that the US examples are rather more obvious. Trying to lock everything down resulted in security systems so complicated, even an MIT professor was unable to figure them out when he was made CIA director. The lesson we have learned is that imperfect security systems that are acceptable to end users are much more effective than theoretically perfect schemes that users bypass. It is possible that the US federal govt. will learn the same lesson someday. If they ever do, they know where to look. --001a11c36bc6d579f10517a37a28 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 3, 2015 at 4:45 PM, Nordgren, Bryce L -FS <bnordgren@fs.fed.us> wrote:
>= ; In a corporate context, this makes perfect sense. If I am downloading com= pany confidential
> material to my laptop, I want to be able to read it on the laptop but = I don't want to accidentally
> send a copy to someone else by doing an unfortunate 'reply all'= ;.

So another thing to note in security considerations is that this is = a scheme intended to protect well behaved actors who have good habits and a= n honest software ecosystem from causing damage due to specific single hone= st mistakes. It is not intended to protect against adversaries, well behave= d actors who have sloppy habits, well behaved actors who make more than one= mistake on the same message (reply all + attachment with no tag/inappropri= ate tag), or well behaved actors who make a single mistake from which multi= ple correlated incorrect actions are derived (misclassify content -> inc= orrect content tag/incorrect mailing list).

In light of these things, I think any language about "ensuring that po= licy is followed" or the like should just be expunged. If the target i= s to encourage well-meaning partners to do the accepted thing, that's h= ow it should be presented.

As I said to a f= ormer director of the NSA recently, the fact that Snowden and Manning had e= ffectively unrestricted access to such a large amount of data is an indictm= ent of both the institution and the approach to controlling information.

The classification level of a document is a measure = of the ego of the author/classifier, not how important it is to keep it sec= ret. If keeping documents secret causes operational difficulties, people wi= ll not attach the security labels necessary to control them properly.
=

Trying to absolutely control the flow of information ha= s a lousy track record. And not just in the US but FOIA means that the US e= xamples are rather more obvious. Trying to lock everything down resulted in= security systems so complicated, even an MIT professor was unable to figur= e them out when he was made CIA director.=C2=A0

--001a11c36bc6d579f10517a37a28-- From nobody Wed Jun 3 15:20:24 2015 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F641B3001 for ; Wed, 3 Jun 2015 15:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 V3vtccdCPKlV for ; Wed, 3 Jun 2015 15:20:21 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0062.outbound.protection.outlook.com [65.55.169.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 541F91B2FFF for ; Wed, 3 Jun 2015 15:20:20 -0700 (PDT) Received: from CY1PR06MB1836.namprd06.prod.outlook.com (25.162.217.18) by CY1PR06MB1804.namprd06.prod.outlook.com (25.162.216.158) with Microsoft SMTP Server (TLS) id 15.1.172.22; Wed, 3 Jun 2015 22:20:18 +0000 Received: from CY1PR0601CA0032.namprd06.prod.outlook.com (25.160.162.42) by CY1PR06MB1836.namprd06.prod.outlook.com (25.162.217.18) with Microsoft SMTP Server (TLS) id 15.1.172.22; Wed, 3 Jun 2015 22:20:17 +0000 Received: from BN1AFFO11FD019.protection.gbl (2a01:111:f400:7c10::119) by CY1PR0601CA0032.outlook.office365.com (2a01:111:e400:4c00::42) with Microsoft SMTP Server (TLS) id 15.1.184.17 via Frontend Transport; Wed, 3 Jun 2015 22:20:17 +0000 Authentication-Results: spf=pass (sender IP is 199.135.140.11) smtp.mailfrom=fs.fed.us; hallambaker.com; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of fs.fed.us designates 199.135.140.11 as permitted sender) receiver=protection.outlook.com; client-ip=199.135.140.11; helo=mail.usda.gov; Received: from mail.usda.gov (199.135.140.11) by BN1AFFO11FD019.mail.protection.outlook.com (10.58.52.79) with Microsoft SMTP Server (TLS) id 15.1.184.11 via Frontend Transport; Wed, 3 Jun 2015 22:20:16 +0000 Received: from 001FSN2MPN1-046.001f.mgd2.msft.net ([169.254.6.131]) by 001FSN2MMR1-001.001f.mgd2.msft.net ([199.135.140.11]) with mapi id 14.03.0224.003; Wed, 3 Jun 2015 22:20:15 +0000 From: "Nordgren, Bryce L -FS" To: Phillip Hallam-Baker Thread-Topic: [Endymail] FW: Group/Enterprise encrypted email Thread-Index: AdCaU4EBKI9vXfbmSrKplnpcKmT5cgCPeK3wABeENQAAG8dZUAAyKjMAAADg6CAAA4+bgAAAQ2EAAAHlwYAAADEG8A== Date: Wed, 3 Jun 2015 22:20:14 +0000 Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E7E1614@001FSN2MPN1-046.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7DFBBD@001FSN2MPN1-046.001f.mgd2.msft.net> <000d01d09cef$76039f10$620add30$@icloud.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7E1094@001FSN2MPN1-046.001f.mgd2.msft.net> <007001d09e27$3c3083f0$b4918bd0$@icloud.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7E154A@001FSN2MPN1-046.001f.mgd2.msft.net> <82E7C9A01FD0764CACDD35D10F5DFB6E7E159E@001FSN2MPN1-046.001f.mgd2.msft.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.7.27.143] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD019; 1:PjSliuF6n0sioX+23Tf7p1mg67akUxtQFLRTpvsN2ig8M6ROgL2d8TcJlu91veT+pzw0d3cEGr89Z/So4coqsrmFP3RFaUoqcgioZNqfynKj0UwSS+01rrwpXR0XBejRJHjkNLZt3k2eMkQiMN3XA0PmePP+4o2aUku0XKuBBMss+mEqES86Eom6d9S5dhU3nZ9K9zjkKNRl9tPAL2+gW9JVY4y/WUAviaJ1zT/WBWbm00yVGyC9zkHLFGfdFeo9YWpuAArp/7LIUc5pStOMbs3NEiiB0vy3h3jcR57gxJE= X-Forefront-Antispam-Report: CIP:199.135.140.11; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(438002)(199003)(189002)(5001860100001)(77156002)(5001830100001)(92566002)(102836002)(69596002)(110136002)(62966003)(23676002)(46102003)(104016003)(68736005)(5001960100002)(97736004)(54356999)(66066001)(6806004)(4001540100001)(81156007)(26826002)(64706001)(33656002)(74482002)(50986999)(76176999)(2900100001)(2950100001)(2920100001)(561944003)(87936001)(189998001)(86146001)(86362001)(47776003)(22756005)(106466001)(2656002)(55846006)(93886004)(50466002)(22746005)(7059030)(80862005)(79686002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR06MB1836; H:mail.usda.gov; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CY1PR06MB1836; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CY1PR06MB1804; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:CY1PR06MB1836; BCL:0; PCL:0; RULEID:; SRVR:CY1PR06MB1836; X-Forefront-PRVS: 05961EBAFC X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jun 2015 22:20:16.7367 (UTC) X-MS-Exchange-CrossTenant-Id: 49808c08-7df8-4c41-af62-7a0827de9408 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=49808c08-7df8-4c41-af62-7a0827de9408; Ip=[199.135.140.11]; Helo=[mail.usda.gov] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR06MB1836 X-OriginatorOrg: fs.fed.us Archived-At: Cc: Trevor Freeman , "endymail@ietf.org" Subject: Re: [Endymail] FW: Group/Enterprise encrypted email X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 22:20:23 -0000 DQo+VHJ5aW5nIHRvIGFic29sdXRlbHkgY29udHJvbCB0aGUgZmxvdyBvZiBpbmZvcm1hdGlvbiBo YXMgYSBsb3VzeSB0cmFjayByZWNvcmQuIA0KPkFuZCBub3QganVzdCBpbiB0aGUgVVMgYnV0IEZP SUEgbWVhbnMgdGhhdCB0aGUgVVMgZXhhbXBsZXMgYXJlIHJhdGhlciBtb3JlIA0KPm9idmlvdXMu IFRyeWluZyB0byBsb2NrIGV2ZXJ5dGhpbmcgZG93biByZXN1bHRlZCBpbiBzZWN1cml0eSBzeXN0 ZW1zIHNvIGNvbXBsaWNhdGVkLCANCj5ldmVuIGFuIE1JVCBwcm9mZXNzb3Igd2FzIHVuYWJsZSB0 byBmaWd1cmUgdGhlbSBvdXQgd2hlbiBoZSB3YXMgbWFkZSBDSUEgZGlyZWN0b3IuwqANCg0KPlRo ZSBsZXNzb24gd2UgaGF2ZSBsZWFybmVkIGlzIHRoYXQgaW1wZXJmZWN0IHNlY3VyaXR5IHN5c3Rl bXMgdGhhdCBhcmUgYWNjZXB0YWJsZSANCj50byBlbmQgdXNlcnMgYXJlIG11Y2ggbW9yZSBlZmZl Y3RpdmUgdGhhbiB0aGVvcmV0aWNhbGx5IHBlcmZlY3Qgc2NoZW1lcyB0aGF0IHVzZXJzIA0KPmJ5 cGFzcy4gSXQgaXMgcG9zc2libGUgdGhhdCB0aGUgVVMgZmVkZXJhbCBnb3Z0LiB3aWxsIGxlYXJu IHRoZSBzYW1lIGxlc3NvbiBzb21lZGF5LiANCj4gSWYgdGhleSBldmVyIGRvLCB0aGV5IGtub3cg d2hlcmUgdG8gbG9vay4NCg0KSSB0aGluayB3ZSBhcmUgaW4gYWdyZWVtZW50IHRoYXQgdG9wIGRv d24gbWljcm9tYW5hZ2VtZW50IG9mIGluZm9ybWF0aW9uIGZsb3cgaXMgYmFkLiBNeSBjb21tZW50 cyBhcmUgaW50ZW5kZWQgdG8gYWxpZ24gdGhlIGxhbmd1YWdlIGluIHRoZSBkb2Mgd2l0aCB0aGUg YWN0dWFsIHNlY3VyaXR5IHByb3ZpZGVkLCBub3QgY2F1c2UgYW55b25lIHRvIGZpeCBwZXJjZWl2 ZWQgc2VjdXJpdHkgaG9sZXMuIDopIEl0IGRvZXMgdmVyeSBtdWNoIHJlYWQgbGlrZSB0aGUgaW50 ZW50IGlzIHRvIHNldCB1cCBhIERSTSBzdWNoIHRoYXQgY29uZm9ybWluZyBzeXN0ZW1zIHByb3Zp ZGUgY2VydGFpbiBndWFyYW50ZWVzLiBJdCBzaG91bGRuJ3QuDQoNCkknbSBub3QgY2VydGFpbiBJ J3ZlIGJlZW4gcGVyc3VhZGVkIHRoYXQgdGhlIERSTS1lc3F1ZSBhc3BlY3RzIGFyZSB3b3J0aHdo aWxlLiBTdGlja2luZyB3aXRoIG5vcm1hbCwgdW4tYXVnbWVudGVkIGVtYWlsIHNlbWFudGljcyBz aW1wbGlmaWVzIHRoaXMgcHJvcG9zYWwgdG8gdGhlIHBvaW50IHRoYXQgaW1wbGVtZW50ZXJzIG1h eSBiZSBhYmxlIHRvIG1ha2UgdGhlIGVuY3J5cHRpb24gcHJvY2VzcyBjb21wbGV0ZWx5IHRyYW5z cGFyZW50IHRvIHVzZXJzLCBvciBhdCBsZWFzdCBib2lsIGl0IGRvd24gdG8gYSBjaGVja2JveC4g TXVjaCBvZiB0aGUgdmFsdWUgYXNzb2NpYXRlZCB3aXRoIGdlbmVyYWxpemluZyB0aGUgYXZhaWxh YmxlIHBvbGljaWVzIGJleW9uZCAiZW5jcnlwdCB0aGlzIG1lc3NhZ2UgYW5kIGRpc3NlbWluYXRl IGtleXMgdG8gdGhlIGVtYWlsIHJlY2lwaWVudHMiIHNlZW1zIHRvIGJlIHByZWRpY2F0ZWQgb24g cHJvc2UgbWFraW5nIGd1YXJhbnRlZXMgb2YgcG9saWN5IGVuZm9yY2VtZW50IGFjcm9zcyBvcmdh bml6YXRpb25hbCBib3VuZGFyaWVzLiBBIHZlcnkgbXVjaCBjbGVhcmVyIGFuZCBtb3JlIHByZWNp c2UgdmFsdWUgc3RhdGVtZW50IGlzIHdhcnJhbnRlZC4NCg0KUGVyaGFwcyB0aGlzIGlzIGFuc3dl cmVkIGluIHRoYXQgb3RoZXIgc3BlYywgYnV0IEkgZG9uJ3QgeWV0IHNlZSBob3cgdGhlIG1haWwg Y2xpZW50IGtub3dzIHdoYXQgcGFyYW1ldGVycyBhcmUgZXhwZWN0ZWQgYnkgdGhlIHBvbGljeS4g RG9lcyBpdCBuZWVkIHRvIHVuZGVyc3RhbmQgYW5kIGltcGxlbWVudCBhIFVJIGZvciBzb21lIHNv cnQgb2YgcG9saWN5IHNjaGVtYSBsYW5ndWFnZT8NCg0KQmVzdCwNCkJyeWNlDQo= From nobody Thu Jun 4 11:19:19 2015 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D30D1A87C1 for ; Thu, 4 Jun 2015 11:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 dnH7MRk2JExW for ; Thu, 4 Jun 2015 11:19:11 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7992E1A87BD for ; Thu, 4 Jun 2015 11:19:11 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 5BCF5FA0065; Thu, 4 Jun 2015 18:19:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1433441949; bh=IoZjyiB7dTG7va6kb9mbf+A/ua6Y62wOHagzYyiiHgY=; h=From:To:Subject:References:Date:From; b=g/9eKRODn75Lry1PeyG0fvlJljHlebgTQ/0z1A3RVTu5S9IlN0WfP+jpcY+FqP0FO Ci7Efp2cWig7NWJcep9TKBtf5RIGiSLd6po6FJ5VeAXU6r9JSWiujidyJxj4QZSBLM N6j09Wxnng9HZUYdviw1mGkgNE5Pw2/iuax7evIE= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1433441947-28872-28871/12/43; Thu, 4 Jun 2015 18:19:07 +0000 From: Arnt Gulbrandsen To: endymail@ietf.org, Michael =?ISO-8859-1?q?Kj=F6rling?= Message-Id: <4kJBhKBGz4D2R7baTFaYgRv+rNvp6FRmkxAQ7LKhNP4=.sha-256@antelope.email> References: <20150603095917.GC25546@yeono.kjorling.se> Mime-Version: 1.0 Content-Type: text/plain; format=flowed Date: Thu, 4 Jun 2015 18:19:07 +0000 Archived-At: Subject: Re: [Endymail] Why S/MIME and OpenPGP ecosystems fall short X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 18:19:14 -0000 If you have zero experience with textsecure, I suggest that you get some before you continue to talk about these things. Because textsecure is a messaging system with good crypto and good deployment, and that is rare enough to be worth learning from. You cannot just say that textsecure ignores something and silently assume that that thing must be done, solved or supported: maybe ignoring that is precisely the key to wide deployment. Arnt From nobody Thu Jun 4 11:54:09 2015 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D738E1A88A1 for ; Thu, 4 Jun 2015 11:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, 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 h1JnPEuKPhbz for ; Thu, 4 Jun 2015 11:54:06 -0700 (PDT) Received: from mr11p24im-asmtp002.me.com (mr11p24im-asmtp002.me.com [17.110.78.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 356B91A8869 for ; Thu, 4 Jun 2015 11:54:06 -0700 (PDT) Received: from denhp (c-24-17-210-106.hsd1.wa.comcast.net [24.17.210.106]) by mr11p24im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NPF00I8SOI35000@mr11p24im-asmtp002.me.com> for endymail@ietf.org; Thu, 04 Jun 2015 18:54:05 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-06-04_14:2015-06-03,2015-06-04,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1506040242 From: Trevor Freeman To: "'Nordgren, Bryce L -FS'" , 'Phillip Hallam-Baker' References: <82E7C9A01FD0764CACDD35D10F5DFB6E7DFBBD@001FSN2MPN1-046.001f.mgd2.msft.net> <000d01d09cef$76039f10$620add30$@icloud.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7E1094@001FSN2MPN1-046.001f.mgd2.msft.net> <007001d09e27$3c3083f0$b4918bd0$@icloud.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7E154A@001FSN2MPN1-046.001f.mgd2.msft.net> <82E7C9A01FD0764CACDD35D10F5DFB6E7E159E@001FSN2MPN1-046.001f.mgd2.msft.net> <82E7C9A01FD0764CACDD35D10F5DFB6E7E1614@001FSN2MPN1-046.001f.mgd2.msft.net> In-reply-to: <82E7C9A01FD0764CACDD35D10F5DFB6E7E1614@001FSN2MPN1-046.001f.mgd2.msft.net> Date: Thu, 04 Jun 2015 11:54:05 -0700 Message-id: <004901d09ef7$d5a893d0$80f9bb70$@icloud.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-index: AQI4r1yN6a8adADhwF3Fb1Vfc9FNLwJxMimUAfuiTKACF+YyqAEv4b4IAXOSVw0C5yq6lgIS6/KbAeXXBV6cTEZwoA== Content-language: en-us Archived-At: Cc: endymail@ietf.org Subject: Re: [Endymail] FW: Group/Enterprise encrypted email X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 18:54:08 -0000 Hi Bryce, I am not quite sure why you keep asserting Plasma is attempting DRM when = it's not. All its doing is providing the same access controls for email = content as the same content is published via the web - and why should an = organization expect anything less. It help the sender make sure that = recipients are entitled to receive the information and that the sender = has complied with the information protection policy for the information = in the email. Unlike DRM, Plasma does not raise expectations that the = recipient does the right thing with the information. Plasma did show it = is possible to provide additional controls to ensure it is appropriate = only disseminate the decryption keys when policy has been satisfied. We = do not set expectations beyond that because the only strong control is = the act of releasing the decryption key. In the Plasma PoC we showed it = was possible to drive Plasma via a simple combo box selection as a one = stop shop which hid the specifics of each policy. One of the vendors who = participated in the project also did a user trial to test Plasma against = the check box options of today and we got back positive results that = user preferred Plasma to the encrypt message check box. Trevor -----Original Message----- From: Endymail [mailto:endymail-bounces@ietf.org] On Behalf Of Nordgren, = Bryce L -FS Sent: Wednesday, June 03, 2015 3:20 PM To: Phillip Hallam-Baker Cc: Trevor Freeman; endymail@ietf.org Subject: Re: [Endymail] FW: Group/Enterprise encrypted email >Trying to absolutely control the flow of information has a lousy track = record.=20 >And not just in the US but FOIA means that the US examples are rather=20 >more obvious. Trying to lock everything down resulted in security=20 >systems so complicated, even an MIT professor was unable to figure them = out when he was made CIA director. >The lesson we have learned is that imperfect security systems that are=20 >acceptable to end users are much more effective than theoretically=20 >perfect schemes that users bypass. It is possible that the US federal = govt. will learn the same lesson someday. > If they ever do, they know where to look. I think we are in agreement that top down micromanagement of information = flow is bad. My comments are intended to align the language in the doc = with the actual security provided, not cause anyone to fix perceived = security holes. :) It does very much read like the intent is to set up a = DRM such that conforming systems provide certain guarantees. It = shouldn't. I'm not certain I've been persuaded that the DRM-esque aspects are = worthwhile. Sticking with normal, un-augmented email semantics = simplifies this proposal to the point that implementers may be able to = make the encryption process completely transparent to users, or at least = boil it down to a checkbox. Much of the value associated with = generalizing the available policies beyond "encrypt this message and = disseminate keys to the email recipients" seems to be predicated on = prose making guarantees of policy enforcement across organizational = boundaries. A very much clearer and more precise value statement is = warranted. Perhaps this is answered in that other spec, but I don't yet see how the = mail client knows what parameters are expected by the policy. Does it = need to understand and implement a UI for some sort of policy schema = language? Best, Bryce _______________________________________________ Endymail mailing list Endymail@ietf.org https://www.ietf.org/mailman/listinfo/endymail