From nobody Fri Mar 1 00:45:32 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C081311F5 for ; Fri, 1 Mar 2019 00:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.101 X-Spam-Level: *** X-Spam-Status: No, score=3.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 N6-133OiBItF for ; Fri, 1 Mar 2019 00:45:28 -0800 (PST) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 851DB130E11 for ; Fri, 1 Mar 2019 00:45:28 -0800 (PST) Received: from [46.183.103.8] (helo=chu.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1gzdnH-0004Us-La; Fri, 01 Mar 2019 08:45:23 +0000 Date: Fri, 01 Mar 2019 09:45:22 +0100 Message-ID: <87r2brf0f1.wl-neal@walfield.org> From: "Neal H. Walfield" To: Jon Callas Cc: Jon Callas , Bart Butler , "openpgp@ietf.org" , Vincent Breitmoser In-Reply-To: <35C892F7-18A8-401E-828D-5CE180A3A731@icloud.com> References: <87mumh33nc.wl-neal@walfield.org> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> <87h8co2t4v.wl-neal@walfield.org> <35C892F7-18A8-401E-828D-5CE180A3A731@icloud.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-2022-JP Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 08:45:31 -0000 At Thu, 28 Feb 2019 10:39:17 -0800, Jon Callas wrote: > > On Feb 28, 2019, at 12:51 AM, Neal H. Walfield wrote: > >> So I think that a SHOULD is the right way to put it. I care less > >> about what the SHOULD limit should be, but a small hard limit sounds > >> like a bad idea. > > > > Do you still think a hard upper limit is a bad idea? > > No, I don$B!G(Bt think a hard upper limit is a bad idea. In the text you quote above, I said a *small* hard upper limit. And no, I don$B!G(Bt know what small means. I think 16K is small. 256K might be small. AES-GCM has issues about 64G. One might argue that$B!G(Bs a reasonable large upper limit. Me, I think anything in the few megabytes to a gigabyte-ish is just fine. > > Let me rewind a bit and get to my real point which I don$B!G(Bt think I$B!G(Bm making well. > > When one creates a standard, one needs to be careful with > parameters, particularly the MUSTs. Seemingly sensible things can > have downstream effects that convince people to use some other > protocol. Worse, someone$B!G(Bs angry blog post about something can > quickly go into $B!H(Bnot even wrong$B!I(B territory and embed itself into > folklore and you can$B!G(Bt get it out. There are plenty of bad ideas > that someone else has a really reasonable use case for. There are always going to be haters. > ... > This has never caused a problem that I$B!G(Bm aware of. I$B!G(Bm sure it caused a problem that none of us are aware of, and the implementors just solved it on their own. It is this experience that has me wondering about what the restrictions out to be. > > The best way to deal with it in a standard is to have non-normative guidance. It is non-normative guidance that I was suggesting. Let me write an example bit of non-normative guidance below: > ... I think that security concerns should be our first priority. And, any flexibility increases our bug potential. As such, I'm not convinced that we shouldn't use a fixed chunk size. If in a few years, if we decide that the size is wrong, then we can just define a new mode, which uses a different chunk size. In my opinion, it should be impossible represent something that we want to disallow. If we are really worried about the haters, then let's just deflect the criticism: let's use 16 kiB chunks like TLS, as Marcus previously pointed out: https://mailarchive.ietf.org/arch/msg/openpgp/t79iRZ80KHuVTEyVVLAoCLl4Rwc (BFrom RFC 8446: 5.2. Record Payload Protection length: The length (in bytes) of the following TLSCiphertext.encrypted_record, which is the sum of the lengths of the content and the padding, plus one for the inner content type, plus any expansion added by the AEAD algorithm. The length MUST NOT exceed 2^14 + 256 bytes. An endpoint that receives a record that exceeds this length MUST terminate the connection with a "record_overflow" alert. https://tools.ietf.org/html/rfc8446#section-5.2 (A record the approximate equivalent of a chunk.) > The Partial Body Lengths that OpePGP has had from the beginning have no restrictions on them. There$B!G(Bs non-normative guidance that pretty much says you shouldn$B!G(Bt even use them, but there$B!G(Bs no restriction on size. I just reread and I don't think it suggests that Partial Body Lengths should not be used. https://tools.ietf.org/html/rfc4880#section-4.2.2.4 Can you point me to this guidance? This is the first time I hear that chunking is considered to be a bad idea. Thanks, :) Neal From nobody Fri Mar 1 00:58:35 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8095512E7C1 for ; Fri, 1 Mar 2019 00:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 EnR3DuPmFH0x for ; Fri, 1 Mar 2019 00:58:32 -0800 (PST) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 6E54112D84D for ; Fri, 1 Mar 2019 00:58:32 -0800 (PST) Received: from [46.183.103.8] (helo=chu.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1gzdzy-00059y-0H; Fri, 01 Mar 2019 08:58:30 +0000 Date: Fri, 01 Mar 2019 09:58:28 +0100 Message-ID: <87o96vezt7.wl-neal@walfield.org> From: "Neal H. Walfield" To: Bart Butler Cc: "openpgp@ietf.org" , Vincent Breitmoser In-Reply-To: References: <87mumh33nc.wl-neal@walfield.org> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> <87k1hk2tpv.wl-neal@walfield.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] AEAD Chunk Size - Performance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 08:58:35 -0000 At Thu, 28 Feb 2019 19:11:06 +0000, Bart Butler wrote: > "Re. Neal's request, I didn't have the numbers anymore, so I unscientifically created some new ones > > It looks like either Chrome or we have actually fixed the performance issues there with c=8 since the last time I tested it, as for most message sizes the performance is the same as c=12 or even a bit faster, except 128KB-256KB, which fits in one chunk with c=12 and there c=8 is about 1.1x - 1.5x slower. > > In Firefox, for >=64KB messages, c=8 is still about 1.5x - 2.5x slower than c=12, however, it looks like most of the overhead of smaller chunks comes from the streams polyfill, not the web crypto API. So that should probably be possible for us to fix." Thanks for providing these numbers! It's particularly interesting to hear how the performance has changed over time. > I see your logic on 16 kiB but in particular for file encryption I think there's some value to being able to go bigger in the future (L2 cache sizes have changed in the last 20 years as well and will probably change in the next two decades), and to keep the size byte to be able to configure this rather than have an entirely new packet. I think a SHOULD for 16 kiB though is totally appropriate now though for the reasons you mentioned. Although I have a slight preference for 16 kiB due to performance concerns, my first priority is security. I'd like, at the minimum, a hard ceiling, but I'd prefer no chunk size parameter at all. I appreciate backwards compatibility, and I'm willing to go with renaming "chunk size" to "magic value" and fixing that to the C corresponding to 256 kiB chunks. From nobody Fri Mar 1 01:02:03 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E97D12E7C1 for ; Fri, 1 Mar 2019 01:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 77pt2fQc1k9F for ; Fri, 1 Mar 2019 01:01:58 -0800 (PST) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 7743C12D84D for ; Fri, 1 Mar 2019 01:01:58 -0800 (PST) Received: from [46.183.103.8] (helo=chu.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1gze3I-0005DP-Kc; Fri, 01 Mar 2019 09:01:56 +0000 Date: Fri, 01 Mar 2019 10:01:47 +0100 Message-ID: <87mumfezno.wl-neal@walfield.org> From: "Neal H. Walfield" To: Bart Butler Cc: "openpgp@ietf.org" , Vincent Breitmoser In-Reply-To: References: <87mumh33nc.wl-neal@walfield.org> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> <87imx42tj9.wl-neal@walfield.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 09:02:02 -0000 At Thu, 28 Feb 2019 19:44:41 +0000, Bart Butler wrote: > I can't because I do not know--it's an experimental feature in OpenPGP.js. I do know that some users of the library are using it internally in closed systems, and we'd prefer not to break decryption for their existing messages but also prefer not to keep supporting an obsolete draft. You could argue that they shouldn't have used an experimental feature for production but given how overdue AEAD is for PGP I find it difficult to blame them myself. > > ProtonMail doesn't use V5 keys yet at all, as we exist within the federated email ecosystem and it would break compatibility. So this is not coming from us personally, just on behalf of the OpenPGP.js community in general. For continuity, in: Message-ID: <87o96vezt7.wl-neal@walfield.org> https://mailarchive.ietf.org/arch/msg/openpgp/JukTMAMY-RUoHsHxVxyZNht96R4 I proposed changing the chunk size to a magic value whose value is the current C value for 256 kiB chunks, and to fix the chunk size to 256 kiB. From nobody Sun Mar 3 10:36:16 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD14128CF3 for ; Sun, 3 Mar 2019 10:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 MUd5mhy86_m4 for ; Sun, 3 Mar 2019 10:36:12 -0800 (PST) Received: from bitbox.cryptobit.ch (cryptobit.ch [188.40.138.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57E5F130DE7 for ; Sun, 3 Mar 2019 10:36:12 -0800 (PST) Received: from unibox (p5B0F56A4.dip0.t-ipconnect.de [91.15.86.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.cryptobit.ch (Postfix) with ESMTPSA id 44CBgX5W03z12jXm; Sun, 3 Mar 2019 19:36:08 +0100 (CET) Message-ID: <2a014c4a103ba7f52535546f7e77277ea2bdabdf.camel@cryptobitch.de> From: Tobias Mueller To: "Neal H. Walfield" , Jon Callas Cc: Bart Butler , "openpgp@ietf.org" , Vincent Breitmoser Date: Sun, 03 Mar 2019 19:36:08 +0100 In-Reply-To: <87r2brf0f1.wl-neal@walfield.org> References: <87mumh33nc.wl-neal@walfield.org> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> <87h8co2t4v.wl-neal@walfield.org> <35C892F7-18A8-401E-828D-5CE180A3A731@icloud.com> <87r2brf0f1.wl-neal@walfield.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2019 18:36:15 -0000 Hi, On Fri, 2019-03-01 at 09:45 +0100, Neal H. Walfield wrote: > I think that security concerns should be our first priority. And, any > flexibility increases our bug potential. As such, I'm not convinced > that we shouldn't use a fixed chunk size. Note that introducing "chunks" diverts from authenticated encryption and increases the bug potential. That is, an implementation may more easily release plaintext although the ciphertext has been modified. The AE mode is OpenPGP's chance to become a protocol which enjoys the strong security guarantees of AE and catch up with S/MIME. By fixing a "chunk size" you take away the ability to benefit from AE for messages bigger than that size. Implementations could easily collect all chunks and only release the plaintext once all chunks check out successfully. But that could go wrong. And depending on implementations to get things right and clients to use those implementations correctly is exactly what enabled Efail to become an issue. I think it'd be much nicer if the protocol already ensures that my emails do indeed enjoy protection against modification rather than me having to rely too much on clients getting it right. Having said that, I understand the desire for fixing a chunk size to reduce complexity for implementers. My desire as a user is to have a strong and resilient protocol. As such I prefer producing messages that enjoy strong protection against modification. That includes my emails or backups larger than 16kB, 256kB, or whatever size you come up with. Is there another way to do real AE? Cheers, Tobi From nobody Mon Mar 4 00:50:03 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 093CC131031 for ; Mon, 4 Mar 2019 00:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 WyzT3dqKhNqM for ; Mon, 4 Mar 2019 00:50:00 -0800 (PST) Received: from mail.fh-muenster.de (mail.fh-muenster.de [212.201.120.190]) by ietfa.amsl.com (Postfix) with ESMTP id D11661200D7 for ; Mon, 4 Mar 2019 00:49:59 -0800 (PST) Received: from [192.168.178.38] (unknown [185.221.171.60]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: ss560221) by mail.fh-muenster.de (Postfix) with ESMTPSA id EF03A284D36 for ; Mon, 4 Mar 2019 09:49:56 +0100 (CET) To: openpgp@ietf.org References: <87mumh33nc.wl-neal@walfield.org> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> <87h8co2t4v.wl-neal@walfield.org> <35C892F7-18A8-401E-828D-5CE180A3A731@icloud.com> <87r2brf0f1.wl-neal@walfield.org> <2a014c4a103ba7f52535546f7e77277ea2bdabdf.camel@cryptobitch.de> From: Sebastian Schinzel Message-ID: <90a28b7c-1b02-abbb-eb8d-bec5263a9f89@fh-muenster.de> Date: Mon, 4 Mar 2019 09:49:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <2a014c4a103ba7f52535546f7e77277ea2bdabdf.camel@cryptobitch.de> Content-Type: multipart/mixed; boundary="------------6A6A0ABFA2CF68525A608F56" Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 08:50:02 -0000 This is a multi-part message in MIME format. --------------6A6A0ABFA2CF68525A608F56 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Am 03.03.2019 um 19:36 schrieb Tobias Mueller: > Having said that, I understand the desire for fixing a chunk size to > reduce complexity for implementers. My desire as a user is to have a > strong and resilient protocol. As such I prefer producing messages tha= t > enjoy strong protection against modification. That includes my emails > or backups larger than 16kB, 256kB, or whatever size you come up with. Chunking breaks plaintexts of arbitrary size into many smaller "chunks" and adds an authentication tag to each chunk. The advantage of smaller chunks is that the plaintext can be cached until the chunk's auth tag is validated. That's to guarantee that no unauthenticated plaintext is released. (Leaving truncation aside.) Your reasoning regarding proper AE is correct, but you are drawing the wrong conclusions. You want small chunks to do proper AE! This implies no limit to the overall size of the plaintext. I also don't see any reason to keep the variable chunk size. We should fix it to something between 16kB and 64kB. Best, Sebastian --------------6A6A0ABFA2CF68525A608F56 Content-Type: application/pgp-keys; name="pEpkey.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="pEpkey.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBFx7f7wBCADEy6S0t4wB6dKm1ewq7A1KBJLMDAEQlfABLg6TDr77IkHHjIRj sG59ih2WY6VtUwKQLvxU5uKAT6EhCjA5kIOVSFDJCadpRtOZU3aY1Q/2Jzmc4Dm8 L5PWKkmeOQZP9/2bTWoz76znSoXv9mam4PinsSj/JSPOkr8MsjPC94iVIU2D18c8 3DV7w1H0Ff9uP3zuVvRyVy8QMEaU53ANglsTBqKhrulQZK/TrBiAAz6ujlFJsLxH 4gIBcWkhb/RWT0NLyAontpAKscL+31C4F9BZNvXbQ0uHei7N63lPMFnsn73ipjYN nW3Btx+frJjommHDdBNxGdAm0uOwBT+1GLuhABEBAAG0LFNlYmFzdGlhbiBTY2hp bnplbCA8c2NoaW56ZWxAZmgtbXVlbnN0ZXIuZGU+iQFUBBMBCAA+FiEEWm7VYqRv H/tftE4oYCk/uxN6bCUFAlx7f8ACGwMFCQHhM4AFCwkIBwIGFQoJCAsCBBYCAwEC HgECF4AACgkQYCk/uxN6bCX5iAf6ApGLtoIJTXCmE3MGYhRxUe1vpPO0uaQcx8dV IypWMphS3Ck+m/fCu+MoFYUF35RN12LtZDjxAqyl/SRC2Ko1egT72z9oVApWATN2 sOaehwNx1YjixIXv6zzoFW3HaJtjUDNny620n2gRIyOodE9s4O1ZjDmRD9QM+/HK NSiB5epj1W3pyG3zcSsJhwsZKohNlyETgG/uVhD4N3Wo5tjdWYYatJNfNznERbWO HGnvVqnSRlr9aoeGLzQTBN1tROqTnVqYEBRRkZDffac/yTf6rxAZlYHLbrhelUu6 zIqOAnxID0/12Yfwn6XGO5+BzIDLgGYLRtGkmyk3LVoHsADRWLkBDQRce3++AQgA 0wmLbSgzZYHGP3OfLsjfHliaA09lKdmOgqtNCzNReQ1iR/Q42k9t6oHzPkCnW6hc yMRMgjZcx4CHTsdAHqkD3EUrQ2JQO0NWmz3mAYBMCMXGCqium8oAsh1X4deQ7zVm KzvOe+TutZ4K8NkksFhC0E3PABOL3NXNqdqrn2Iakft4yUDDsZphNmFHwCH3DV4/ iP33y0O67gYC55p1kjSSD/AL0OteWAo/3a9korCXx8aAR1CEt1z7D9m+2caRyJzB vbrL7UsxDXJvPxjP0Ahlogu2krDeIcl+9tf2AqllfbZ7b4KiLdMKw6lMpLgBThRN W2S/mRUNwpxfOaODxqeQEQARAQABiQE8BBgBCAAmFiEEWm7VYqRvH/tftE4oYCk/ uxN6bCUFAlx7f74CGwwFCQHhM4AACgkQYCk/uxN6bCUG2Af/fB+KsQ+K+XBEaAsC tABIEfGTGc3eUTGQ3g4KQ3duJbYiE8IrjDhpG3ehn0OAwcjmIhiNc4C4+dgAbzzp XwMVdOJuSSRWa8fomewUn4v990ZEyE5GML/7Fvpv3hwEMvudgREsRxKtRg1KBK0g 6Ut76G1waGPSyABOQxWo6JR8nExsORpbW9ah6xuPnccJ8TnBbeV2642DshQowdNQ 15j3hsyQaJr63UtQSX6hxACPS5h4sQoT6+4pKk90cPLxGoMmqn8+2emAezsSOL2B poE6l8iwDO2I9BhziGgAbU3gMjYfEzG4a+2f0//FeDx2RssX4m3tfLT6xEOClSXt Du4U/Q=3D=3D =3DpBEy -----END PGP PUBLIC KEY BLOCK----- --------------6A6A0ABFA2CF68525A608F56-- From nobody Mon Mar 4 02:38:20 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7409F131119 for ; Mon, 4 Mar 2019 02:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 TVvmenxJUT42 for ; Mon, 4 Mar 2019 02:38:17 -0800 (PST) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 0514B131116 for ; Mon, 4 Mar 2019 02:38:17 -0800 (PST) Received: by mail-ed1-x52d.google.com with SMTP id f19so3806017eds.12 for ; Mon, 04 Mar 2019 02:38:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ltPsjMz+YE4r76OPxMUtDZmF8gMWm0f8GanoEoj05GM=; b=NIkiHg9E5bx+N7S878Ks5mzWsPgj5T5zZPy8P+lA7FAtv9N5C70Q70mWN38Gyk4wMj UoXnkKA1hIohTJQpjY1+pKe/M4jKMhOn1mvxUlDPr3+j/g0J288jfkRY01IBsyE8tQy+ THuHQdlh/agrsy0v1KsWX8FSvxQMN7oZOEYJM08Jjm9yJtO3dbckO90jj6D3yriBiWMX xSwh2c9+AL0851ORgSxSGn6uk+H7DHMc1m8mT/QCuuPtQlG2gmg7z0JQR3vTjhz7+S6r ytyUZTc3+CZBxM7U4wI3qpZ8fbSfBKOZA+jw0ElzjBHRzA7vqVckg7Pr2z2+Ro85lNUK HgVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ltPsjMz+YE4r76OPxMUtDZmF8gMWm0f8GanoEoj05GM=; b=lul876o24OIWAFE/BN3MdQ1MS/x0nuzAuBtQtMLul1AJ1L+V3vmZdJ4ZN2TwkLp8Xx IV61XpHGi/El9LPR08quWVY4MV+QqNU0W1+YC1OZO5JMai5HuqQovwXqYEIhAkqt3leB jCBIHqs5y/ZS0NlxwHXO1/TEAe6PHGXe27W2DE6dnQKoAEi2j9AlCjbNiAN6Gpb5ESgN z72zz8VXcXoQUWsjA/maIXyo+oZic+RHLQ9vIJ8O0yqF6LG7Us652uX1iHow5LWVD8E3 +RbBkVbbYa4MxJDXMsh6F6QsBw5nmF2RO2LGZYqVOp5Ho3knU42zPXCBWRRB3OALRYfE LewA== X-Gm-Message-State: APjAAAWTEiDgtZI+D6EZieNZuN8+U8mvxrbpHN2Yl1hkfbNykOP49qoD /+TQpmDWYWMg9SQ+Zm/hnVPSocBX9eotALQo64zNl3TD X-Google-Smtp-Source: APXvYqzQn1T92sLZH/IMNJdDdT0ZWUda0GwNJy9NXBzmnnLmjyIU2TzjSG4z19TktO5xde2Em9Bgon+a59WYKA0iNFM= X-Received: by 2002:a17:906:f101:: with SMTP id gv1mr4679715ejb.73.1551695895349; Mon, 04 Mar 2019 02:38:15 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Justus Winter Date: Mon, 4 Mar 2019 11:38:04 +0100 Message-ID: To: Derek Atkins Cc: Wiktor Kwapisiewicz , openpgp@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [openpgp] User ID Attribute Subpacket X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 10:38:20 -0000 Sorry, this makes no sense at all. On Wed, Feb 20, 2019 at 5:08 PM Derek Atkins wrote: > 2) The reason for the User ID Attribute subpacket was that we wanted to > have multiple Attribute subpackets included in the certificate in a > primary signature, but this was not possible with 4880. My memory is User Attribute subpackets are not in the signature, but in the User Attribute packet. Your other additions, specifying notation data with keys like "charset" are Signature subpackets, and *are* part of signatures. The only thing that having UserID subpackets for the User Attribute packet is that you can have multiple userids bound by one binding signature. But that is a feature that I dislike, because then we can no longer strip down TPKs so that they only include a subset of the userids, which can enhance the privacy of our users. This is important for pEp, Autocrypt, and Hagrid. > hazy on what the exact issue was, but IIRC you could EITHER have a > UserID packet OR a set of Attribute packets, but not both. Because I > wanted both a UserID *AND* additional attributes in a single > signature, this seemed the best way to do it. Given that you, the person who requested this addition, can no longer make a solid case for it, I request for the UserID subpacket to be removed. From nobody Mon Mar 4 06:38:23 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF43129BBF for ; Mon, 4 Mar 2019 06:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.689 X-Spam-Level: X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ihtfp.com 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 EszYZjhjkmyo for ; Mon, 4 Mar 2019 06:38:21 -0800 (PST) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 604F41200D8 for ; Mon, 4 Mar 2019 06:38:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id B3043E2040; Mon, 4 Mar 2019 09:38:15 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 17051-09; Mon, 4 Mar 2019 09:38:05 -0500 (EST) Received: by mail2.ihtfp.org (Postfix, from userid 48) id CCB04E2045; Mon, 4 Mar 2019 09:38:05 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1551710285; bh=8aAHfGtL2vjLDqNyn1IOQxZvuraAAALbX7pCK1KGy0Y=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=gKkYXR4aGyD909viRbfmHoJsgD8c1d4JJEKOJnTLHuS3oguG8HnSKWOXOFdOuWFsL x9RpUWW87WvOgbY+Iiy6dd4lKt7U26e/2MsF+IFHfYBU7TmC6VNX5wdvCpYaFoUEE9 V75KHokHpky7gW3OvHWP83G+MPVkT0PK7RXY0NDo= Received: from 99.46.190.172 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Mon, 4 Mar 2019 09:38:05 -0500 Message-ID: <546b32d041f2cd0227aaa737f8841b26.squirrel@mail2.ihtfp.org> In-Reply-To: References: Date: Mon, 4 Mar 2019 09:38:05 -0500 From: "Derek Atkins" To: "Justus Winter" Cc: openpgp@ietf.org User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: Re: [openpgp] User ID Attribute Subpacket X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 14:38:23 -0000 Hi, On Mon, March 4, 2019 5:38 am, Justus Winter wrote: > Sorry, this makes no sense at all. > > On Wed, Feb 20, 2019 at 5:08 PM Derek Atkins wrote: >> 2) The reason for the User ID Attribute subpacket was that we wanted to >> have multiple Attribute subpackets included in the certificate in a >> primary signature, but this was not possible with 4880. My memory is > > User Attribute subpackets are not in the signature, but in the User > Attribute > packet. Please re-read what I wrote. Note that when I say "in the signature" I mean "protected by the signature." This could also be read as "included in the hash that is signed." Also, if you read draft-atkins-openpgp-device-certificates (even though it expired), it explains this in gory detail: RFC 4880 section 12.1 defines a v4 Public Key Format as a sequence of packets starting with a Primary Key and then a sequence of packets and subpackets that add Revocations, User IDs, and Signatures. The description in RFC 4880 requires a User ID. Implementors of this specification can loosen that requirement such that an augmented V4 device certificate looks like the following sequence (no longer requiring a User ID packet): Primary-Key [Revocation Self Signature] [Direct Key Signature...] [User ID [Signature ...] ...] [User Attribute [Signature ...] ...] [[Subkey [Binding-Signature-Revocation] Primary-Key-Binding-Signature] ...] The issue at hand was that you cannot make a single signature that covers both a User ID packet and a User Attribute packet. Moreover, the format REQUIRED a User ID packet, which meant that if you wanted to sign a bunch of User Attributes you HAD to have TWO signatures in the certificate. My goal was to reduce that to a SINGLE signature by allowing the User ID to exist as a User Attribute Subpacket. This would let you use the User Attribute signature type and include a User ID (attribute subpacket) along with additional attribute subpackets all protected by a single signature. > The only thing that having UserID subpackets for the User Attribute packet > is that you can have multiple userids bound by one binding signature. But > that is a feature that I dislike, because then we can no longer strip down > TPKs so that they only include a subset of the userids, which can enhance > the privacy of our users. This is important for pEp, Autocrypt, and > Hagrid. It is not the only thing -- see above. It lets you bind a User ID and additional attributes with a single signature, which is the primary goal. Note that you can already have multiple UserIDs on a key. If your main gripe is that you could have multiple User ID Attribute Subpackets bound by the same signature, I am fine if you want to limit that and say that an implementation MUST NOT (or SHOULD NOT) include more than one in a single Attribute packet. >> hazy on what the exact issue was, but IIRC you could EITHER have a >> UserID packet OR a set of Attribute packets, but not both. Because I >> wanted both a UserID *AND* additional attributes in a single >> signature, this seemed the best way to do it. > > Given that you, the person who requested this addition, can no longer make > a solid case for it, I request for the UserID subpacket to be removed. I said I was hazy -- this was proposed FIVE YEARS ago, so it's taken me a while to swap those issues back into my brain. So let me restate the issues as to why I did this and request it: 1) I want to enable a certificate where the primary key cannot sign 2) I want to have a single binding signature that binds a User ID AND additional attributes 3) I want to enable a reduction in space consumption due to a bunch of notations that we use 4) I introduced some additional notation types which we use (and should be useful to others) The User ID Attribute is really part of #2. Thanks for your consideration. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Mar 4 07:03:17 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8647131128 for ; Mon, 4 Mar 2019 07:03:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 OZIue29YOnOT for ; Mon, 4 Mar 2019 07:03:06 -0800 (PST) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 C080E131157 for ; Mon, 4 Mar 2019 07:03:05 -0800 (PST) Received: by mail-ed1-x534.google.com with SMTP id h58so4501809edb.5 for ; Mon, 04 Mar 2019 07:03:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dFJTbotGg8PnrCLCKNvJsScTYNleXRTZrjEtuYLxgoc=; b=KNhCXZxXPV7IwcpHWmMTVb4J377SbpdutKUibKxZ4HjQ2a8IXBnGgzv9xojNX1t0JJ Da60kRSkU0RHJ34Fn1P4k7+ATT+ZUQ5fUy1hdlVYZQ2gTqbRlJXgvNqQKxvpCPfJjXIO 5p3H8Sd9VDvWtSsTzjupEqmXOPOOksUhRUf4uCOP3Mn+TumNFUU+RIhY4etATRPmIMzJ b8wPEMEMMoR8NRlPxNZWwtZQQHZ15c52ibW0IM3m5g4ekBHmcny51o3MOT+dCtsGJro9 N9kOXItfK00u0z14aWMmmw3HJ4cT0dgx39/WgDOARfeG6LeQ6ts10pbofpQNcia92M2I aSFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dFJTbotGg8PnrCLCKNvJsScTYNleXRTZrjEtuYLxgoc=; b=t12gOFktRE/fk1gSia3mlQEJuTKNMRogTQYYepwAShCJACC56mF7FobgshTTAhonAY 3zo5QdL5ffligvLUUpQpNJWOpJkbfj0sJcjz+dcDVyV9bwZY7WZdERDzqjSMIwbT1uKh vQGE7qzu3Qtl4gpXDe82IHyH/cn1o5bpWcrmlOnQc3091qzzIEGubRwwCtYa6PImId3l oBv5Fiw2znoJ0xRdBcWIINVIGiIXnOTfDwbaAyOTphtG8JfnhHpVxkKDN9DyiS56Nz3x DyvQMqNC3n7qW/7FeH9op0CRV7pxfsFL9T5DpfXbJpBPuMWya/BfcCtemA1jEiIIG6kI bt+w== X-Gm-Message-State: APjAAAXP7a8pPSwK+jhvsdWPC+8uo0dqkGZg5VPUaFY24ojlD3L12LLX AyCc3KmZ9/LaolVTttXHGqQQkJQNJElN/rNFRjg= X-Google-Smtp-Source: APXvYqyadaTp8iqeXo1asxWr5vXDGZgX4MTgUYI6CinK23Qh3d1Ii8DEscxvfiCbh5kt1OC3n/NfmrTE05RtTnagOXg= X-Received: by 2002:a50:adc7:: with SMTP id b7mr15960189edd.280.1551711783434; Mon, 04 Mar 2019 07:03:03 -0800 (PST) MIME-Version: 1.0 References: <546b32d041f2cd0227aaa737f8841b26.squirrel@mail2.ihtfp.org> In-Reply-To: <546b32d041f2cd0227aaa737f8841b26.squirrel@mail2.ihtfp.org> From: Justus Winter Date: Mon, 4 Mar 2019 16:02:48 +0100 Message-ID: To: Derek Atkins Cc: openpgp@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [openpgp] User ID Attribute Subpacket X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 15:03:16 -0000 On Mon, Mar 4, 2019 at 3:38 PM Derek Atkins wrote: > On Mon, March 4, 2019 5:38 am, Justus Winter wrote: > > Sorry, this makes no sense at all. > > > > On Wed, Feb 20, 2019 at 5:08 PM Derek Atkins wrote: > >> 2) The reason for the User ID Attribute subpacket was that we wanted to > >> have multiple Attribute subpackets included in the certificate in a > >> primary signature, but this was not possible with 4880. My memory is > > > > User Attribute subpackets are not in the signature, but in the User > > Attribute > > packet. > > Please re-read what I wrote. Note that when I say "in the signature" I > mean "protected by the signature." This could also be read as "included > in the hash that is signed." Given that in OpenPGP, Signatures have Subpackets, and your proposal is also about adding notations, which is stored in said subpackets, "in the signatures" is too ambiguous to discuss the matter. > Also, if you read draft-atkins-openpgp-device-certificates (even though it > expired), it explains this in gory detail: > > RFC 4880 section 12.1 defines a v4 Public Key Format as a sequence of > packets starting with a Primary Key and then a sequence of packets > and subpackets that add Revocations, User IDs, and Signatures. > > The description in RFC 4880 requires a User ID. Implementors of this > specification can loosen that requirement such that an augmented V4 > device certificate looks like the following sequence (no longer > requiring a User ID packet): > > Primary-Key > [Revocation Self Signature] > [Direct Key Signature...] > [User ID [Signature ...] ...] > [User Attribute [Signature ...] ...] > [[Subkey [Binding-Signature-Revocation] > Primary-Key-Binding-Signature] ...] > > The issue at hand was that you cannot make a single signature that covers > both a User ID packet and a User Attribute packet. Moreover, the format > REQUIRED a User ID packet, which meant that if you wanted to sign a bunch > of User Attributes you HAD to have TWO signatures in the certificate. I support dropping the requirement of a UserID or UserAttribute packet. > My goal was to reduce that to a SINGLE signature by allowing the User ID > to exist as a User Attribute Subpacket. This would let you use the User > Attribute signature type and include a User ID (attribute subpacket) along > with additional attribute subpackets all protected by a single signature. > > > The only thing that having UserID subpackets for the User Attribute packet > > is that you can have multiple userids bound by one binding signature. But > > that is a feature that I dislike, because then we can no longer strip down > > TPKs so that they only include a subset of the userids, which can enhance > > the privacy of our users. This is important for pEp, Autocrypt, and > > Hagrid. > > It is not the only thing -- see above. It lets you bind a User ID and > additional attributes with a single signature, which is the primary goal. I'm still confused by what you mean by "additional attributes". Your proposal states: Whereas the User ID Packet only allows a single UTF-8 string content, the User Attribute Packet allows the addition of multiple attributes in subtype packets. Unfortunately RFC 4880 only defined a single Attribute Subpacket, the Image Attribute. This means that you need two signatures if you want to have an ID and an image. So your usecase is to have a UserAttribute packet, with a single UserID subpacket, and one or more Image subpackets, bound by a single signature. Is that correct? > Note that you can already have multiple UserIDs on a key. If your main > gripe is that you could have multiple User ID Attribute Subpackets bound > by the same signature, I am fine if you want to limit that and say that an > implementation MUST NOT (or SHOULD NOT) include more than one in a single > Attribute packet. My gripe is that UserID subpackets seem redundant, therefore needlessly complicating the standard, and neither this discussion, your draft, nor the language that ended up in draft-06 properly motivates the redundancy. > 1) I want to enable a certificate where the primary key cannot sign Fine with me. > 2) I want to have a single binding signature that binds a User ID AND > additional attributes This is what I don't understand. > 3) I want to enable a reduction in space consumption due to a bunch of > notations that we use > 4) I introduced some additional notation types which we use (and should be > useful to others) Fine with me. Thanks, Justus From nobody Mon Mar 4 07:35:44 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 083B712D861 for ; Mon, 4 Mar 2019 07:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.689 X-Spam-Level: X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ihtfp.com 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 CM2vGcCHxWnI for ; Mon, 4 Mar 2019 07:35:41 -0800 (PST) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ED2412D84D for ; Mon, 4 Mar 2019 07:35:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 912F4E2040; Mon, 4 Mar 2019 10:35:38 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 18943-02; Mon, 4 Mar 2019 10:35:37 -0500 (EST) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 97226E2042; Mon, 4 Mar 2019 10:35:37 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1551713737; bh=12tpxo7HVEq4/vwJTEx3xOqHukgg8infhh2vWYwws50=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=g0SsY8T/Oan0/nGkmIN0hHji4oJWOi04DiP/PP+HzQTyARD2m6GCYZIwqLxlFeaqg kSUOeJors/iC3we6faSyf0IhZNuW5BFetz0aW0TQMISzWLAKBCLvonE3UoKkVrL11P HJaoRuO+wOUILqv8Fz87iGVJ+EjYhTA85N2jL170= Received: from 99.46.190.172 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Mon, 4 Mar 2019 10:35:37 -0500 Message-ID: <48eadafb01b3c6e3872380cac3863c98.squirrel@mail2.ihtfp.org> In-Reply-To: References: <546b32d041f2cd0227aaa737f8841b26.squirrel@mail2.ihtfp.org> Date: Mon, 4 Mar 2019 10:35:37 -0500 From: "Derek Atkins" To: "Justus Winter" Cc: openpgp@ietf.org User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: Re: [openpgp] User ID Attribute Subpacket X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 15:35:42 -0000 On Mon, March 4, 2019 10:02 am, Justus Winter wrote: > > Given that in OpenPGP, Signatures have Subpackets, and your proposal > is also about adding notations, which is stored in said subpackets, "in > the > signatures" is too ambiguous to discuss the matter. Fair enough. In my mind (having been involved in PGP since 1992), it's pretty obvious, but I can understand your confusion. I will try to be a bit more concise. > I support dropping the requirement of a UserID or UserAttribute packet. The User Attribute packet was already optional -- it was only the UserID packet that was required. > I'm still confused by what you mean by "additional attributes". Your > proposal > states: > > Whereas the User ID Packet only > allows a single UTF-8 string content, the User Attribute Packet > allows the addition of multiple attributes in subtype packets. > Unfortunately RFC 4880 only defined a single Attribute Subpacket, the > Image Attribute. This means that you need two signatures if you want > to have an ID and an image. > > So your usecase is to have a UserAttribute packet, with a single UserID > subpacket, and one or more Image subpackets, bound by a single signature. > Is that correct? I'm confused by your confusion. What part of "additional attributes" do you not understand? I'm not trying to be a PITA here, but I'm honestly not understanding your confusion about what is meant here by what I said. But to answer your question, yes, I want to have a UserID and an Image with one binding signature -- and possibly additional future attribute subpackets, too. >> Note that you can already have multiple UserIDs on a key. If your main >> gripe is that you could have multiple User ID Attribute Subpackets bound >> by the same signature, I am fine if you want to limit that and say that >> an >> implementation MUST NOT (or SHOULD NOT) include more than one in a >> single >> Attribute packet. > > My gripe is that UserID subpackets seem redundant, therefore needlessly > complicating the standard, and neither this discussion, your draft, nor > the > language that ended up in draft-06 properly motivates the redundancy. It's not redundant, because you cannot, in 4880, have a userid + image bound by a single signature. It only SEEMS redundant to you because they are effectively performing similar operations, but as it currently stands you would have a UserID + signature, and then an Image + signature. So there is no way to do { UserID + Image } + signature using what's available in 4880. Therefore, it is not redundant. I should note that, having implemented this, the additional code to handle this is actually quite small! You can actually reuse a great deal, so really it's just a protocol number and an additional branch. >> 1) I want to enable a certificate where the primary key cannot sign > > Fine with me. > >> 2) I want to have a single binding signature that binds a User ID AND >> additional attributes > > This is what I don't understand. What don't you understand about it? >> 3) I want to enable a reduction in space consumption due to a bunch of >> notations that we use >> 4) I introduced some additional notation types which we use (and should >> be >> useful to others) > > Fine with me. > > Thanks, > Justus -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Mar 4 08:27:02 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6050131065 for ; Mon, 4 Mar 2019 08:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ux_7w887qzEO for ; Mon, 4 Mar 2019 08:26:58 -0800 (PST) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 7C0CB131069 for ; Mon, 4 Mar 2019 08:26:49 -0800 (PST) Received: by mail-ed1-x52b.google.com with SMTP id c55so4758265edb.0 for ; Mon, 04 Mar 2019 08:26:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pnpycuSHRQCztEbRTvCJ4gBe4FOvYHU+OG+6nR5kD40=; b=cYk1Pfeadym1rTMC8sh3uck+e4c8WtdX6q4GJ37V6Va2LmvV7oH1YhG2/fZas4whEx iDmXBRf8xVXEFE93hmD2vvbd2M2pMLEW1h9BA7QN3n31LRQJ3PVCj6q2llPe0f1r6MCY AdGClm5gBEPYztwpwG8EynzSkdmmMywQkMaJ8r8iJNNom+zGkPfNnJgzwcjctBQQAyhE VpfOeDMkl6XY0d9iSoNSZ22Gc8lOuXDYQvzE0HiOeTYP9qmiUGHPmn2UdGHUlUeYu0s6 +UCjXVExzBWbRjuP3i46UZsZnochz8Yb3c2WewgHKpaxYoNpHc8QnS6FPZJoPPnCi+gK lg3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pnpycuSHRQCztEbRTvCJ4gBe4FOvYHU+OG+6nR5kD40=; b=CSZYw53pJ4gKTTCadQ94YaX0U3bDCdpuxxvP/CYAwK5ruDEIwMu6OW15FCoqoNXgJP W7FUXHgusF2ZlUMDsuljccZgUzTc6mRsVQx/ugCpkcjN3jmaMyH6wvQZhjWYUguxkeQh 1TbZtgl+KdoYOWaK43fcof6r+w3kuQO8OZuGfDki7M+AQHJVT7mLOxJsHuxB82nwodON 9ttWXuCFSaR3f8pwUybnQaJ89h8aZv8IwfYAJpmYs1B39pe90zYnhU4qSaA53lF8I3/H jd4CnwAM21TFltgOnnaYUeAru9HmDWkAzmMcZ7YOMCJrTh8VusB7bIaM2M8x6uGBY8i6 /kLQ== X-Gm-Message-State: APjAAAWzJ77mot34RkHFatMKwv5880CwpM3dtUankdm1OZ4K+jempFFr upIimqnavpD55+wyyK21RKUlZ8QlBihdTOUGClk= X-Google-Smtp-Source: APXvYqy+32w4cRHA+SIncMIe6j3JtVPDXx9O61WXJ5Iv40SXtLSd0Q5/XYgiiGPAC1rrbNgCv/AMFtWy8n4ZUSn0zbQ= X-Received: by 2002:a50:eb4a:: with SMTP id z10mr16064850edp.284.1551716807771; Mon, 04 Mar 2019 08:26:47 -0800 (PST) MIME-Version: 1.0 References: <546b32d041f2cd0227aaa737f8841b26.squirrel@mail2.ihtfp.org> <48eadafb01b3c6e3872380cac3863c98.squirrel@mail2.ihtfp.org> In-Reply-To: <48eadafb01b3c6e3872380cac3863c98.squirrel@mail2.ihtfp.org> From: Justus Winter Date: Mon, 4 Mar 2019 17:26:36 +0100 Message-ID: To: Derek Atkins Cc: openpgp@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [openpgp] User ID Attribute Subpacket X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 16:27:01 -0000 On Mon, Mar 4, 2019 at 4:35 PM Derek Atkins wrote: > On Mon, March 4, 2019 10:02 am, Justus Winter wrote: > > So your usecase is to have a UserAttribute packet, with a single UserID > > subpacket, and one or more Image subpackets, bound by a single signature. > > Is that correct? > > I'm confused by your confusion. What part of "additional attributes" do > you not understand? I'm not trying to be a PITA here, but I'm honestly > not understanding your confusion about what is meant here by what I said. > > But to answer your question, yes, I want to have a UserID and an Image > with one binding signature -- and possibly additional future attribute > subpackets, too. Well, your proposal is about adding some notation data, and I did not imagine you wanting to burden your embedded devices (for which a mere URI as the notation data's key is too much) with images. > >> Note that you can already have multiple UserIDs on a key. If your main > >> gripe is that you could have multiple User ID Attribute Subpackets bound > >> by the same signature, I am fine if you want to limit that and say that > >> an > >> implementation MUST NOT (or SHOULD NOT) include more than one in a > >> single > >> Attribute packet. > > > > My gripe is that UserID subpackets seem redundant, therefore needlessly > > complicating the standard, and neither this discussion, your draft, nor > > the > > language that ended up in draft-06 properly motivates the redundancy. > > It's not redundant, because you cannot, in 4880, have a userid + image > bound by a single signature. It only SEEMS redundant to you because they > are effectively performing similar operations, but as it currently stands > you would have a UserID + signature, and then an Image + signature. So > there is no way to do { UserID + Image } + signature using what's > available in 4880. Therefore, it is not redundant. > > I should note that, having implemented this, the additional code to handle > this is actually quite small! You can actually reuse a great deal, so > really it's just a protocol number and an additional branch. Is it though? At this point I need to stress that while such an addition seems trivial, lot's of these trivial details add up and contribute to the complexity of the protocol. Therefore, every addition to it should face scrutiny, even more those that introduce redundancy. And it is not just a matter of implementation, but of semantics. Say you parse a TPK into some data structure, and you have a way to iterate over the user ids and their binding signatures. Now, for consistency, we want to include your user ids. However, the iterator now has to deal with two different ways of representing the same thing, and verification of the corresponding binding signatures is no longer uniform. So from my perspective, adding subpacket-based user ids has a high cost. And now that I understand your use case, I wonder if there isn't an easier way to do what you want, without complicating the standard. For example, you could store the image as notation data in the binding signature of a user id. Seeing that you use notations for other data, implementing this should be straight forward for you. Speaking of implementations, GnuPG does not support the user id attribute. Is there an publicly available implementation that does? Thanks, Justus From nobody Tue Mar 5 00:14:11 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF222130E2B for ; Tue, 5 Mar 2019 00:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 VuwcF5CjH8T3 for ; Tue, 5 Mar 2019 00:14:06 -0800 (PST) Received: from nimbus.fccf.net (nimbus.fccf.net [185.117.82.79]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3BB812958B for ; Tue, 5 Mar 2019 00:14:05 -0800 (PST) Received: from straylight.m.ringlet.net (gw1.storpool.com [46.233.30.128]) by nimbus.fccf.net (Postfix) with ESMTPSA id 1B52D487 for ; Tue, 5 Mar 2019 10:14:01 +0200 (EET) Received: from roam (uid 1000) (envelope-from roam@ringlet.net) id 620003 by straylight.m.ringlet.net (DragonFly Mail Agent v0.11); Tue, 05 Mar 2019 10:14:00 +0200 Date: Tue, 5 Mar 2019 10:14:00 +0200 From: Peter Pentchev To: Justus Winter Cc: Derek Atkins , openpgp@ietf.org Message-ID: <20190305081400.GD18475@straylight.m.ringlet.net> References: <546b32d041f2cd0227aaa737f8841b26.squirrel@mail2.ihtfp.org> <48eadafb01b3c6e3872380cac3863c98.squirrel@mail2.ihtfp.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="T7mxYSe680VjQnyC" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [openpgp] User ID Attribute Subpacket X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 08:14:09 -0000 --T7mxYSe680VjQnyC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 04, 2019 at 05:26:36PM +0100, Justus Winter wrote: > On Mon, Mar 4, 2019 at 4:35 PM Derek Atkins wrote: > > On Mon, March 4, 2019 10:02 am, Justus Winter wrote: > > > So your usecase is to have a UserAttribute packet, with a single User= ID > > > subpacket, and one or more Image subpackets, bound by a single signat= ure. > > > Is that correct? > > > > I'm confused by your confusion. What part of "additional attributes" do > > you not understand? I'm not trying to be a PITA here, but I'm honestly > > not understanding your confusion about what is meant here by what I sai= d. > > > > But to answer your question, yes, I want to have a UserID and an Image > > with one binding signature -- and possibly additional future attribute > > subpackets, too. >=20 > Well, your proposal is about adding some notation data, and I did not ima= gine > you wanting to burden your embedded devices (for which a mere URI as the > notation data's key is too much) with images. I believe that by "additional attributes" Derek also means "additional attribute types" - not just images, but other, not yet defined, types of attributes, in which to keep additional data. This might be what you're missing from his explanations - he wants to have a packet that contains a user ID and *other* attributes, not necessarily images, that might not take too much space. G'luck, Peter --=20 Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} pp@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 --T7mxYSe680VjQnyC Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEELuenpRf8EkzxFcNUZR7vsCUn3xMFAlx+L8IACgkQZR7vsCUn 3xP8pw/+LSSYaeXfjhN9JbfzzgrngiFsWZVaFHNokzk8POpWWA5UnXuhOdIIXFdF hx6p3r3zWaRl4ImoP3thxeaPGcN42R/wvDqpZ2wnBOPa0kQkUjcy/YAuUy8WzNJE D3+mlnC2aGTR9RYotT7bn4sAoh0k9USe6PANuRgQBVK6/XJvmIakpl6pXiFo36bf Raqese+QVuRKMmvH7ou9NM2Hxcx9MLvjFsaEGDMghvnOmTRWtXDANFj0azDHRhKF 14+11ndVJ0g/LnPK/V0zEGjLPjwguWROoS2ojReBvk5l5w+yQgu3xA6mabLLjdLH +3UsfhWTj5dj0QsZjgnpYURd8O2NR34e1y7czd7eDXutyj+vxB6XM7zGcXd8gUw3 BxgIrceP1L7MxpL5IMEltGu5JoEVK3npbAgvSbdu6CFBrqoQTa8daaWVx40+Sq7f 7YZzbA6RU89lkHFiAUXjZHHUZIpg3SEcsVFwHEyqiObdoHOJMeixl2eHql/vsCCx an3Eqxb3Btyzst5m5rumv3XPyQSYA6P3nQwegn82f27xK0tJ1VVkIAvL4TWYWgvu y7F9TqX+5gYVBxpOHpgua0U+de+gxoBAb4XlJF8JZwrQDjZWGxCR6DCYUFcxUUWK YxZUVr+Z2WFjxsQ5z9FCuXHRdOoV9uOpm4Z3f9hU25sAh9xY0pQ= =QeA7 -----END PGP SIGNATURE----- --T7mxYSe680VjQnyC-- From nobody Tue Mar 5 04:56:52 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D729131078 for ; Tue, 5 Mar 2019 04:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 1uldLwlUoB3e for ; Tue, 5 Mar 2019 04:56:48 -0800 (PST) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 38149130F81 for ; Tue, 5 Mar 2019 04:56:48 -0800 (PST) Received: by mail-ed1-x530.google.com with SMTP id c55so7155851edb.0 for ; Tue, 05 Mar 2019 04:56:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UYqwSmWzMRS+mjbvkUpYVf8jmNLCHnsOURdXJBYMNGA=; b=MY/a4e5Dy3F5NHnqsXH2AV+dqxzEjE8rs5H3oTT7tfKeJJByL6R2GfGlu4fNdJUpIW ydmu7vfyAbi/CE+3qH+i2WTPcvKY/YFMKxzP79N1DjQa/kx52lZtfsUS4sDYsvNwm0FM kDVZ1ai6dNRbccGX3Cb8OJzcGiajRwMAuJOBtw/4RSroNS/gXIhQFDlMVN8T37Eeb+73 edWfVu+AsZcpzUOiu/H+s3PUQXoejO7I/WvTXjG6VemL3cBveMDz6eD0QypbsxJ9g5P1 tbSLxCTaMxQCOZyZOX3qx0N2URIi6qjcmyeMHFfu0Wfv6VkL8RtuU4RqMrd7nBky0f9u myAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UYqwSmWzMRS+mjbvkUpYVf8jmNLCHnsOURdXJBYMNGA=; b=d8L8TqoQJRANQMvqxUIbuLPwWv+9YCw9bOFfc3YVTaDbKy2KK5HWusxIU8Q28NIIVw EmdACs5jWG/9ZqrJHS9cEoIcGDCPMoqgMFktOKizhNb5RU2OxAedupsbUd9Xr66f5Cb8 K1kfnRQJi3/ARmfeI4gdbO/J/KcJLg53v4p0rR5ySoPC7MyJgs1siomYWG2y2ii4Pzg4 AiwyPCZiY/co7GECXISHBEdBIx5c2HaAfvFfpe6njVOc9/fieu8ArgTRNRIy5FGvmp74 G/GKe1uRCJIj6mJFkENRi3tywR6LeGgE2pun0G7lhy/mSgFkI5Z3pzXojlt484mKNaHO jcUQ== X-Gm-Message-State: APjAAAX3435F3zIP0a3JtpO4F/32DY7hlAfoo73YEXUC7E+YJ65/cv5f YO1xoiVqnnIrv6vPoIOeu/L3ZSJ/0MPTOg8mUTBH5Bdy X-Google-Smtp-Source: APXvYqytGAhPMymjtOjKh1iMmi+/++VQMB4QdrWslk9KsNULkR9LthpY1GyU6fx70i6t0sHp6vR8M3zeWzN25PFgiEM= X-Received: by 2002:a17:906:6086:: with SMTP id t6mr165392ejj.242.1551790606207; Tue, 05 Mar 2019 04:56:46 -0800 (PST) MIME-Version: 1.0 References: <546b32d041f2cd0227aaa737f8841b26.squirrel@mail2.ihtfp.org> <48eadafb01b3c6e3872380cac3863c98.squirrel@mail2.ihtfp.org> <20190305081400.GD18475@straylight.m.ringlet.net> In-Reply-To: <20190305081400.GD18475@straylight.m.ringlet.net> From: Justus Winter Date: Tue, 5 Mar 2019 13:56:35 +0100 Message-ID: To: Peter Pentchev Cc: Derek Atkins , openpgp@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [openpgp] User ID Attribute Subpacket X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 12:56:51 -0000 On Tue, Mar 5, 2019 at 9:14 AM Peter Pentchev wrote: > I believe that by "additional attributes" Derek also means "additional > attribute types" - not just images, but other, not yet defined, types of > attributes, in which to keep additional data. This might be what you're > missing from his explanations - he wants to have a packet that contains > a user ID and *other* attributes, not necessarily images, that might not > take too much space. If it is not about images, then the case for creating a new UserAttribute subpacket is even weaker, because Derek's proposal already includes some predefined keys for notation data. I don't see why these "additional attributes" can not be included in the Signature packet as notations. From nobody Wed Mar 6 07:34:17 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDE81275E9 for ; Wed, 6 Mar 2019 07:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rmrm.io 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 k1cPeq4PxUKl for ; Wed, 6 Mar 2019 07:34:10 -0800 (PST) Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) (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 9EC7F127287 for ; Wed, 6 Mar 2019 07:34:09 -0800 (PST) Received: by mail-lj1-x242.google.com with SMTP id l5so11287528lje.1 for ; Wed, 06 Mar 2019 07:34:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rmrm.io; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=WPNp53zGXDGXoYol+iwmlIl6N9B28022lhlgc7kVAdA=; b=R2HN/E7/75NdX53Nm8iunOIV4bIAsHhw3KQQaSOXC5DKOXpiPtxCuzhC7G6GgzvciH Y9g+o9c1jm7JhCd/7p3k03p684zHFfm89utdURTOM4kBmSUmW3ASk3mKIqeHdlrZQmNU Ag0lRvJ4o0bdlwy9Ryo0qq375AwQcMXwLTQaPW0a7xYYKjCsFSSGVba6ryya4IzYG/63 sqG6ceh1zXahRc7No9Ur6GOBJGWhAZC/+RSJ3NaePKZve7t2cARyujIYz+xcypfRE/zj LPsjKrc8gtEa5NdUc0DYvylSxsWSca1fQtWvQK30oSR/zvbqnX+uLlwR3fA/5Q3+ggV7 3ztg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=WPNp53zGXDGXoYol+iwmlIl6N9B28022lhlgc7kVAdA=; b=jMwBJPmY4Pa9fKMShrJQAmdU15PIe3SOABlCYMjMhENqpIfKUR+/HRiFRcN0Bxw0tn Ztsn8cKM8oKXYa21gS7qmrSY0PEEr1BcQMrmYqpSc9Ev5Np2SCnJPHcbdtX4/89DI263 QAEAojU7E5k7FCC3/Z8stCR+SEiBF1KuprdelYivjFTGWvFNPJ8WVz6wBqHcEsjd92js N+qZMsmupF4L2kdS+MBLIoVmCnkh+3EZuWgSCdyw9hloJx6hTcU9wFHB1Blseid+NCqQ tkhxYOVmlCbimAa+zoFFf+TYhhHrfd4CNs++IYYCzbJ0UMYj+ngSP9lrJz5NhSaIjdS6 ZMPw== X-Gm-Message-State: APjAAAWvjOzAlG4MiwAhS4fnZB6BMkFg4fuMMw/ZjeZ27oKYuC2uGVNi 4xodCdKxzx0mX5KHiCBIk9PBpcdIzjTREXhrzAQqVg== X-Google-Smtp-Source: APXvYqy1mZhWAYdIzqMmovGRwLzHEnF9+hdF15a75LSybIzsKfu/M/QEja3U/F3I5ENR+/Ei9fOiJ1TfxaaEV9U5okU= X-Received: by 2002:a2e:2ce:: with SMTP id y75mr2749317lje.126.1551886447444; Wed, 06 Mar 2019 07:34:07 -0800 (PST) MIME-Version: 1.0 References: <2c64839f-a46a-2ace-6be5-239eb39b5fbc@theintercept.com> In-Reply-To: From: "R. Miles McCain" Date: Wed, 6 Mar 2019 10:33:56 -0500 Message-ID: To: Micah Lee , openpgp@ietf.org, Nat Welch , keylists@freelists.org Content-Type: multipart/alternative; boundary="0000000000006e9b4105836eb8c0" Archived-At: Subject: Re: [openpgp] comments on draft-mccain-keylist-02 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 15:34:14 -0000 --0000000000006e9b4105836eb8c0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello all, I am writing to announce that we have released a new version of draft-mccain-keylists (draft-mccain-keylists-04) based on the feedback we received from members of this working group=E2=80=94namely, Paul Wouters an= d Wiktor Kwapisiewicz. Thank you for all your help. The changes in this new version can be viewed at https://github.com/firstlookmedia/keylist-rfc/pull/11/files#diff-ecd5aee053= 3eca34044c2ff3f965c68f The draft itself is published at https://datatracker.ietf.org/doc/draft-mccain-keylist We were not able to fully address each comment in this draft, of course, so any and all further feedback is extremely helpful. We do think, however, that our changes in v04 implement most of the suggestions (and alleviate many of the concerns) raised by earlier comments. Regards, Miles On Wed, Feb 13, 2019 at 3:50 PM R. Miles McCain wrote: > Thank you, Micah, for adding me to this email. I would like to just add > here that our freelists.org mailing list has yet to be meaningfully used, > and we would be absolutely willing to move discussion to an appropriate > IETF-managed mailing list. (Because our draft has yet to be assigned > to/adopted by any working group, we didn't have an IETF mailing list we > could use for discussion.) > > That being said, we have made our best efforts to encourage discussion > within the IETF community=E2=80=94including announcing our draft to SecDi= spatch. > > Thank you for the useful comments so far; we will work to incorporate thi= s > feedback in future versions of the draft. > > Miles > > > On Wed, Feb 13, 2019 at 3:31 PM Micah Lee > wrote: > >> Hello, >> >> I'm adding Miles McCain to this email, who is one of the authors you >> left out. And I'm also adding the keylists@freelists.org mailing list. >> >> On 2/12/19 6:32 PM, Paul Wouters wrote: >> > Via twitter I noticed this draft: >> > >> > https://tools.ietf.org/html/draft-mccain-keylist-02 >> >> Note that a new draft has since been published, however the changes are >> minor: https://tools.ietf.org/html/draft-mccain-keylist-03 >> >> > I have some comments on the draft. I've added the authors to the CC: >> > since I'm not sure if they are on this list. >> > >> > First a procedural item. Section 1.3 states: >> > >> > 1.3. Note to Readers >> > >> > RFC Editor: please remove this section prior to publication. >> > >> > Development of this Internet draft takes place on GitHub at Keylist= - >> > RFC [1]. >> > >> > A mailing list is available for discussion at Keylists mailing list >> > [2]. >> > >> > >> > I just wanted to share with the authors that this is not the way one >> > writes RFCs. RFC's and the IETF are covered by rules, such as the Note >> > Well. Please see https://www.ietf.org/about/note-well/ >> > >> > This is important because everyone discussing this draft on this list = is >> > expected to fall under the rules of the Note Well, meaning they cannot >> > go out and get a patent and not mention anything until this document i= s >> > an RFC, and then start charging money. And discussion at an external >> > site as the draft authors suggest, is not protected by this mechanism. >> > >> > Furthermore, IETF carefully archives all mailinglist messages which ca= n >> > later also be used in discovery but also for late-comers to the >> > discussion. If an outside website suddenly vanishes, all this >> > information is lost. Finally, IETF has Chairs and a Sergant-at-arms to >> > guide any on-list discussion. elsewhere, we fall under other possibly >> > arbitrary rules. I'm not saying your suggested locations are (I didn't >> > go there) but as a rule discussions on internet drafts happen on >> > internet lists. Work elsewhere is brought back to the IETF. Eg you can >> > make a pull request on github but you discuss this on an IETF list. >> >> It's good to understand how RFCs are supposed to get discussed and >> written. I, as well as the other two authors, are new to the IETF >> process. However I don't see how the Note Well is especially relevant to >> this draft RFC, as there has been no talk about patents. >> >> We have a mailing list for this project (keylists@freelists.org) though >> admittedly we haven't been using it. Instead we've been using a chat >> room hosted by a third party. >> >> Can you point to a document that describes the policy you're referencing >> about where discussion of the RFC should take place, and also where >> collaboration of writing the actual document should take place? We >> definitely want to be transparent about the whole process. >> >> > Now to the draft itself, >> > >> > >> > Section 2 talks about subscribing to "key lists", where a "key list" i= s >> > defined as an URI to something and a fingerprint of a public key that = is >> > authorative for this list. >> > >> > >> > Section 2.2 talks about regularly updating the key list, and performin= g >> > daily checks at the URI. I think this could be a privacy issue, and on= e >> > could track a traveling journalist based on their key list sync checks= . >> >> It's true that there's a potential privacy issue with regularly fetching >> updates, but it's the same issue that all subscription systems have, >> such as Atom feeds (RFC 4287). It's also the same issue if you configure >> gpg to refresh your keyring on a regularly interval. >> >> This privacy issue is more of a fundamental problem with how networking >> works than with any specific standard that relies on subscribing to a >> regularly-changing document, so I don't think it's in scope for this >> specific RFC to tackle. >> >> However, GPG Sync, software that already implements the draft keylist >> RFC, supports an option mitigate this issue by making it simple to fetch >> updates over Tor: >> >> https://github.com/firstlookmedia/gpgsync/wiki/Using-GPG-Sync-with-Tor >> >> > section 3. >> > >> > The key list is a JSON format that can contain a reference to an >> > external key server. This also sounds a bit dangerous to me. Instead o= f >> > all clients forking out to possibly many key server locations, why isn= 't >> > the "key list" simply an openpgp format public keyring, with trust >> > attributes set properly by the "management key" ? Clients can HEAD the >> > file and if there is an update, GET the file via HTTP and import the >> > updates. I don't understand why there is indirection allowed or requir= ed >> > in this idea. >> > >> > Because no openpg keyring format is used, this "key list" needs to be >> > separately signed by the management pgp key. It adds another level of >> > indirection that could be avoided. If I have sufficient "trust" set >> > in my personal keyring to trust updates from the manager key, then >> > I can get the updated in openpgp format without further new protocols >> > already. >> > >> > The "key list" contains comments such as an signature_uri that allows >> > the key list URI and the signature to be located on different systems? >> > Why would that ever be useful or more secure than doing a cleartext >> > signature on the file itself hosted on the same server as the key >> > list file itself? >> > >> > A key list entry contains a fingerprint, name and email field? So in >> > essence, this becomes a meta key-server. Why give participants all >> > these indirections, instead of just providing the openpgp keyring >> > itself? >> > >> > >> > Why is the key list not optionally (but hopefully) encryped to the >> > participants to avoid a privacy leak to anyone who obtains the key lis= t >> > URI ? >> > >> > A key list entry has concept of a last updated time stamp. Does this >> > mean that every "sync" I go out to all individual key servers to get >> > keys from all participants just in case they might have updated their >> > keys on the keyserver / fileserver of their choice? It seems this >> > process is an ideal process for the centralized manager key to perform= , >> > instead of all participants? >> >> GnuPG keyrings are not defined by an internet standard. They're a custom >> format that GPG developers made up, and have changed over time (for >> example gpg2 keyrings aren't compatible with gpg1). Having keylists rely >> on GPG keyrings would make it unfeasible for non-GPG OpenPGP users to >> subscribe to an organization's keylist. >> >> The relevant standard you're probably thinking of is RFC 4880 which >> defines the OpenPGP message format, basically the "-----BEGIN PGP PUBLIC >> KEY BLOCK-----"-type blocks. But that format isn't appropriate for >> keylist subscriptions. >> >> Keylists don't include full public keys, they only include fingerprints. >> Information in public keys themselves change frequently -- the owner of >> the key might add a UID, update their expiration date, or otherwise >> modify their key. If keylists included actual full public keys, then the >> person maintaining the keylist would have to update it not just when a >> new key is added, but every single time anyone in the the organization >> modifies their key. >> >> One of the main purposes of keylists is to reduce the amount of work >> required to ensure that everyone in an organization (or anyone who >> wishes to communicate with members of that organization) has the correct >> public key for everyone else. >> >> Including full public keys in the keylist would be counterproductive. >> The keylist that my company relies on currently has 228 fingerprints on >> it, and it would add a ridiculous amount of pointless work to maintain >> it if we had to keep track of minor changes in each key (and get copies >> of those changed public keys from their owners), when instead we can >> just keep track of fingerprints. >> >> > Section 4. >> > >> > The "in practise" section is usually called the Impliementation Status >> > section. Please see https://tools.ietf.org/html/rfc7942 on how to writ= e >> > these. (for example, to avoid publishing it in the final RFC) >> >> This is good feedback. >> >> > Section 5. >> > >> > The security considerations usually does not contain the benefits. Tho= se >> > are the features offered and described in the document itself. This >> > section deals more with the concerns or practical issues or general >> > safe practises one has to keep in mind. Usually with a focus on >> > implementors more than endusers. For guidelines on how to write a >> > Security Consideration section, see https://tools.ietf.org/html/rfc355= 2 >> > >> > The three benefits listed do not convey to me why this solution with a >> > level on indirection is better suited that using a openpgp keyring >> > at the location. >> > >> > I would rewrite 5.2 a bit. Yes the security of this system is only as >> > strong as the security of the manager key. But how does one convey thi= s >> > management key? How is this key verified? What to do when the key IDs >> > are different? What to do when the key list can be obtained but not >> > the individual key servers listed for some participants. How often to >> > retry? when to warn the user? How does one recover from a management >> > key loss or compromise? How does the manager / key talk to its users >> > about anything? >> >> Interesting, I'll take a look at the Security Considerations document. >> >> > The biggest problem though is that I see no attempt at providing >> > confidentiality for a key list. Anyone with the URI can get the list >> > of participants. >> >> Keylists are public documents, and anyone can subscribe to them even if >> they're not a member of the organization. >> >> It might be worth considering the case where people wish to have private >> keylists, but it's not something we have considered yet. >> >> > Why not introduce a .well-known location that any organisation can >> > use, so we could try and find key lists for organisations we never >> > talked to before. Perhaps specify a mechanism on how to verify an >> > organisational management key? >> >> We considered introducing a .well-known location, but, as described in >> the draft: >> >> To subscribe to a keylist, the client must be aware of the keylist >> URI (see [RFC3986]), and the fingerprint of the authority key used to >> sign the keylist. >> >> A client must have both the keylist URI and the fingerprint of the >> authority key to subscribe to it -- just the keylist URI is not enough, >> which means a .well-known location would have to also include the >> authority key fingerprint. Doing this would ultimately make the trust of >> the entire system rely on the security of the organization's web server, >> and on HTTPS, as opposed to on the authority key. >> >> And there's a further issue related to domains names which I describe >> below. >> >> > What to do when the email on the key list points to a key lacking that >> > key ID ? >> >> As described in the draft, only the "fingerprint" field of the key is >> required, and all other fields (name, email, comments, and any other >> arbitrary metadata) are optional, and only there for the sake of the >> organization maintaining the keylist. Clients simply fetch the >> fingerprint. >> >> > Why not use https://wiki.gnupg.org/WKD ? >> > >> > Why not use OPENPGPKEY DNS records? >> >> The members of an organization frequently don't have email addresses at >> the same domain name. For example, my organization includes email >> addresses at firstlook.org, firstlook.media, theintercept.com, >> fieldofvision.org, topic.com, among other domains, not to mention we >> frequently add personal email addresses hosted at gmail.com or other >> email services, as well as university email servers, for interns, >> freelancers, or other temporary workers. And some organizational keys >> contain UIDs that don't include email addresses at all. Still, we want >> to include all of these fingerprints on our keylist. >> >> A keylist contains a list of fingerprints for public keys everyone in >> the organization should have. It would add more pointless work to >> maintain this system if we chose to arbitrarily require that they all >> keys contain UIDs with email addresses for the same domain name. >> >> Also, not all organizations even have a domain name of their own (for >> example, a free software project where the code and releases are hosted >> on GitLab.com, and members of the project use personal email addresses). >> >> > While automatic sync is a nice feature, over-syncing is a privacy risk= , >> > especially for people who are trying to remain anonymous. >> >> This is outside the scope of this RFC. Like I described above, Atom >> feeds, and existing automated use of key servers, have always had this >> problem. >> >> (Also, people trying to remain anonymous need to do quite a bit more >> than just not automatically fetch PGP keys. It requires using an >> operating system designed for such a use-case, like Tails, in which case >> subscribing to keylists would be perfect fine, and would not compromise >> anonymity.) >> >> > All in all, this seems like an interesting application, and worth >> > further discussion (on this list). I am not yet convinced this is >> > an protocol issue and not an application issue. >> > >> > Paul >> > >> >> And finally, I'll also reply to Wiktor's feedback. (Quoting in full for >> Miles' sake.) >> >> On 2/13/19 3:10 AM, Wiktor Kwapisiewicz wrote:> Hello, >> > >> > Excellent points and I'm glad that the draft has been published on thi= s >> > ML for a discussion in a wider audience. >> > >> > As far as I understood draft-mccain-keylist-02 its goals can already b= e >> > achieved with a combination of already existing features: >> > >> > 1. Discovering keys for company employees - using "e-mail to key" look= up >> > (e.g. WKD) >> > >> > 2. Trusting that these keys are authentic - by signing an Authority Ke= y >> > and setting ownertrust to full. This can be done only once and it work= s >> > for all future keys. Even with draft-mccain-keylist-02 one needs to do >> > that to know which keys are trusted. There is one variation of this >> > scheme - by using Trust Signatures one can trust Authority Key to keys >> > from the company domain only. >> > >> > 3. Keeping keys up to date - why not just refresh all keys in the loca= l >> > keyring? (e.g. `gpg --refresh-keys` or something similar). (GnuPG will >> > refresh expired keys over WKD if they were fetched with WKD [0]). >> > >> > [0]: https://dev.gnupg.org/T2917 >> > >> > If the problem is that people verify signatures and the keys are not >> > present I think applications have appropriate options to fetch keys >> > automatically (e.g. `gpg --auto-key-retrieve`). >> > >> > I like the point of using .well-known for a keyring of all people but >> > from what I've heard on GitHub the ability to host keylist on a >> > different domain is desired: >> > >> >> There's no reason to trust the server that hosts the keylist file. We >> >> already don't trust it -- FLM hosts our keylist on GitHub. >> > >> > Source: >> > >> >> https://github.com/firstlookmedia/keylist-rfc/issues/8#issuecomment-4268= 46582 >> > >> > >> > Kind regards, >> > Wiktor >> >> I've already addresses some of this, but: >> >> It's important for my company's use-case, and probably that of many >> other organizations, to not tie a keylist to one specific domain name, >> and to allow the keylist to include keys for personal email address >> (e.g. gmail.com) as well as keys with UIDs that don't contain email >> addresses at all. WKD is simply insufficient for this use-case. (It also >> has the problem where if a member of the organization updates their key, >> they can't push their updated key into the WKD like they can to a key >> server.) >> >> It's true that we could bootstrap a system like `gpg --refresh-keys` >> combined with cron (or more realistically launchd on macOS) to keep keys >> up-to-date. But 1) Not all OpenPGP users use gpg and cron, and 2) we >> don't necessarily want to update all keys in every user's keychain, only >> the keys on the keylists they're subscribed to. Only refreshing keys >> listed on a keylist leaks less information to key servers than >> refreshing all keys -- it leaks what keylists you're subscribed to. >> >> But, most importantly, and in fact the reason we developed GPG Sync to >> begin with (which ultimately lead to writing this draft RFC), what isn't >> possible with existing tools is to get everyone in an organization to >> automatically fetch *new* keys that they otherwise wouldn't be aware of. >> >> For example, lets say we hire a new intern, and they generate a PGP key >> for their mit.edu email address. How do we get hundreds of people's >> computers to automatically fetch that key so they can email this intern >> without having to do manually fetch it and verify it first? Or, let's >> say an employee loses their Yubikey, so they publish their revocation >> certificate and generate a new key. How do we get those hundreds of >> computers to fetch the revoked key, as well as the new key, so that the >> next time someone sends an encrypted email to that person, it just works= ? >> > --0000000000006e9b4105836eb8c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,

I am writing to announce that we have released a new version of draft= -mccain-keylists (draft-mccain-keylists-04) based on the feedback we receiv= ed from members of this working group=E2=80=94namely, Paul Wouters and Wikt= or Kwapisiewicz. Thank you for all your help.


The draft its= elf is published at=C2=A0https://datatracker.ietf.org/doc/draft-mccain-keylist

We were not able to fully address each comment in t= his draft, of course, so any and all further feedback is extremely helpful.= We do think, however, that our changes in v04 implement most of the sugges= tions (and alleviate many of the concerns) raised by earlier comments.=C2= =A0

Regards,
Miles
<= /div>


On Wed, Feb 13, 2019 at 3:50 PM R. M= iles McCain <miles@rmrm.io> wrot= e:
Thank you, Micah, for adding me to this email. I would like to just add= here that our freelists= .org mailing list has yet to be meaningfully used, and we would be abso= lutely willing to move discussion to an appropriate IETF-managed mailing li= st. (Because our draft has yet to be assigned to/adopted by any working gro= up, we didn't have an IETF mailing list we could use for discussion.)= =C2=A0

That being said, we have made our best efforts to= encourage discussion within the IETF community=E2=80=94including announcin= g our draft to SecDispatch.

Thank you for the usef= ul comments so far; we will work to incorporate this feedback in future ver= sions of the draft.

Miles


On Wed, Feb 13, 2019 at 3:31 PM Mi= cah Lee <micah.lee@theintercept.com> wrote:
Hello,

I'm adding Miles McCain to this email, who is one of the authors you left out. And I'm also adding the keylists@freelists.org mailing list.

On 2/12/19 6:32 PM, Paul Wouters wrote:
> Via twitter I noticed this draft:
>
> https://tools.ietf.org/html/draft-mccain-key= list-02

Note that a new draft has since been published, however the changes are
minor: https://tools.ietf.org/html/draft-mccain-= keylist-03

> I have some comments on the draft. I've added the authors to the C= C:
> since I'm not sure if they are on this list.
>
> First a procedural item. Section 1.3 states:
>
> =C2=A0=C2=A0 1.3.=C2=A0 Note to Readers
>
> =C2=A0=C2=A0 RFC Editor: please remove this section prior to publicati= on.
>
> =C2=A0=C2=A0 Development of this Internet draft takes place on GitHub = at Keylist-
> =C2=A0=C2=A0 RFC [1].
>
> =C2=A0=C2=A0 A mailing list is available for discussion at Keylists ma= iling list
> =C2=A0=C2=A0 [2].
>
>
> I just wanted to share with the authors that this is not the way one > writes RFCs. RFC's and the IETF are covered by rules, such as the = Note
> Well. Please see https://www.ietf.org/about/note-well/=
>
> This is important because everyone discussing this draft on this list = is
> expected to fall under the rules of the Note Well, meaning they cannot=
> go out and get a patent and not mention anything until this document i= s
> an RFC, and then start charging money. And discussion at an external > site as the draft authors suggest, is not protected by this mechanism.=
>
> Furthermore, IETF carefully archives all mailinglist messages which ca= n
> later also be used in discovery but also for late-comers to the
> discussion. If an outside website suddenly vanishes, all this
> information is lost. Finally, IETF has Chairs and a Sergant-at-arms to=
> guide any on-list discussion. elsewhere, we fall under other possibly<= br> > arbitrary rules. I'm not saying your suggested locations are (I di= dn't
> go there) but as a rule discussions on internet drafts happen on
> internet lists. Work elsewhere is brought back to the IETF. Eg you can=
> make a pull request on github but you discuss this on an IETF list.
It's good to understand how RFCs are supposed to get discussed and
written. I, as well as the other two authors, are new to the IETF
process. However I don't see how the Note Well is especially relevant t= o
this draft RFC, as there has been no talk about patents.

We have a mailing list for this project (keylists@freelists.org) though
admittedly we haven't been using it. Instead we've been using a cha= t
room hosted by a third party.

Can you point to a document that describes the policy you're referencin= g
about where discussion of the RFC should take place, and also where
collaboration of writing the actual document should take place? We
definitely want to be transparent about the whole process.

> Now to the draft itself,
>
>
> Section 2 talks about subscribing to "key lists", where a &q= uot;key list" is
> defined as an URI to something and a fingerprint of a public key that = is
> authorative for this list.
>
>
> Section 2.2 talks about regularly updating the key list, and performin= g
> daily checks at the URI. I think this could be a privacy issue, and on= e
> could track a traveling journalist based on their key list sync checks= .

It's true that there's a potential privacy issue with regularly fet= ching
updates, but it's the same issue that all subscription systems have, such as Atom feeds (RFC 4287). It's also the same issue if you configur= e
gpg to refresh your keyring on a regularly interval.

This privacy issue is more of a fundamental problem with how networking
works than with any specific standard that relies on subscribing to a
regularly-changing document, so I don't think it's in scope for thi= s
specific RFC to tackle.

However, GPG Sync, software that already implements the draft keylist
RFC, supports an option mitigate this issue by making it simple to fetch updates over Tor:

https://github.com/firstlookme= dia/gpgsync/wiki/Using-GPG-Sync-with-Tor

> section 3.
>
> The key list is a JSON format that can contain a reference to an
> external key server. This also sounds a bit dangerous to me. Instead o= f
> all clients forking out to possibly many key server locations, why isn= 't
> the "key list" simply an openpgp format public keyring, with= trust
> attributes set properly by the "management key" ? Clients ca= n HEAD the
> file and if there is an update, GET the file via HTTP and import the > updates. I don't understand why there is indirection allowed or re= quired
> in this idea.
>
> Because no openpg keyring format is used, this "key list" ne= eds to be
> separately signed by the management pgp key. It adds another level of<= br> > indirection that could be avoided. If I have sufficient "trust&qu= ot; set
> in my personal keyring to trust updates from the manager key, then
> I can get the updated in openpgp format without further new protocols<= br> > already.
>
> The "key list" contains comments such as an signature_uri th= at allows
> the key list URI and the signature to be located on different systems?=
> Why would that ever be useful or more secure than doing a cleartext > signature on the file itself hosted on the same server as the key
> list file itself?
>
> A key list entry contains a fingerprint, name and email field? So in > essence, this becomes a meta key-server. Why give participants all
> these indirections, instead of just providing the openpgp keyring
> itself?
>
>
> Why is the key list not optionally (but hopefully) encryped to the
> participants to avoid a privacy leak to anyone who obtains the key lis= t
> URI ?
>
> A key list entry has concept of a last updated time stamp. Does this > mean that every "sync" I go out to all individual key server= s to get
> keys from all participants just in case they might have updated their<= br> > keys on the keyserver / fileserver of their choice? It seems this
> process is an ideal process for the centralized manager key to perform= ,
> instead of all participants?

GnuPG keyrings are not defined by an internet standard. They're a custo= m
format that GPG developers made up, and have changed over time (for
example gpg2 keyrings aren't compatible with gpg1). Having keylists rel= y
on GPG keyrings would make it unfeasible for non-GPG OpenPGP users to
subscribe to an organization's keylist.

The relevant standard you're probably thinking of is RFC 4880 which
defines the OpenPGP message format, basically the "-----BEGIN PGP PUBL= IC
KEY BLOCK-----"-type blocks. But that format isn't appropriate for=
keylist subscriptions.

Keylists don't include full public keys, they only include fingerprints= .
Information in public keys themselves change frequently -- the owner of
the key might add a UID, update their expiration date, or otherwise
modify their key. If keylists included actual full public keys, then the person maintaining the keylist would have to update it not just when a
new key is added, but every single time anyone in the the organization
modifies their key.

One of the main purposes of keylists is to reduce the amount of work
required to ensure that everyone in an organization (or anyone who
wishes to communicate with members of that organization) has the correct public key for everyone else.

Including full public keys in the keylist would be counterproductive.
The keylist that my company relies on currently has 228 fingerprints on
it, and it would add a ridiculous amount of pointless work to maintain
it if we had to keep track of minor changes in each key (and get copies
of those changed public keys from their owners), when instead we can
just keep track of fingerprints.

> Section 4.
>
> The "in practise" section is usually called the Impliementat= ion Status
> section. Please see https://tools.ietf.org/html/rfc7942 = on how to write
> these. (for example, to avoid publishing it in the final RFC)

This is good feedback.

> Section 5.
>
> The security considerations usually does not contain the benefits. Tho= se
> are the features offered and described in the document itself. This > section deals more with the concerns or practical issues or general > safe practises one has to keep in mind. Usually with a focus on
> implementors more than endusers. For guidelines on how to write a
> Security Consideration section, see https://tools.ietf.org/h= tml/rfc3552
>
> The three benefits listed do not convey to me why this solution with a=
> level on indirection is better suited that using a openpgp keyring
> at the location.
>
> I would rewrite 5.2 a bit. Yes the security of this system is only as<= br> > strong as the security of the manager key. But how does one convey thi= s
> management key? How is this key verified? What to do when the key IDs<= br> > are different? What to do when the key list can be obtained but not > the individual key servers listed for some participants. How often to<= br> > retry? when to warn the user? How does one recover from a management > key loss or compromise? How does the manager / key talk to its users > about anything?

Interesting, I'll take a look at the Security Considerations document.<= br>
> The biggest problem though is that I see no attempt at providing
> confidentiality for a key list. Anyone with the URI can get the list > of participants.

Keylists are public documents, and anyone can subscribe to them even if
they're not a member of the organization.

It might be worth considering the case where people wish to have private keylists, but it's not something we have considered yet.

> Why not introduce a .well-known location that any organisation can
> use, so we could try and find key lists for organisations we never
> talked to before. Perhaps specify a mechanism on how to verify an
> organisational management key?

We considered introducing a .well-known location, but, as described in
the draft:

=C2=A0 =C2=A0To subscribe to a keylist, the client must be aware of the key= list
=C2=A0 =C2=A0URI (see [RFC3986]), and the fingerprint of the authority key = used to
=C2=A0 =C2=A0sign the keylist.

A client must have both the keylist URI and the fingerprint of the
authority key to subscribe to it -- just the keylist URI is not enough,
which means a .well-known location would have to also include the
authority key fingerprint. Doing this would ultimately make the trust of the entire system rely on the security of the organization's web server= ,
and on HTTPS, as opposed to on the authority key.

And there's a further issue related to domains names which I describe b= elow.

> What to do when the email on the key list points to a key lacking that=
> key ID ?

As described in the draft, only the "fingerprint" field of the ke= y is
required, and all other fields (name, email, comments, and any other
arbitrary metadata) are optional, and only there for the sake of the
organization maintaining the keylist. Clients simply fetch the fingerprint.=

> Why not use https://wiki.gnupg.org/WKD ?
>
> Why not use OPENPGPKEY DNS records?

The members of an organization frequently don't have email addresses at=
the same domain name. For example, my organization includes email
addresses at firstlook.org, firstlook.media, theintercept.com,
f= ieldofvision.org, topic.com, among other domains, not to mention we
frequently add personal email addresses hosted at gmail.com or other
email services, as well as university email servers, for interns,
freelancers, or other temporary workers. And some organizational keys
contain UIDs that don't include email addresses at all. Still, we want<= br> to include all of these fingerprints on our keylist.

A keylist contains a list of fingerprints for public keys everyone in
the organization should have. It would add more pointless work to
maintain this system if we chose to arbitrarily require that they all
keys contain UIDs with email addresses for the same domain name.

Also, not all organizations even have a domain name of their own (for
example, a free software project where the code and releases are hosted
on GitLab.com, and members of the project use personal email addresses).
> While automatic sync is a nice feature, over-syncing is a privacy risk= ,
> especially for people who are trying to remain anonymous.

This is outside the scope of this RFC. Like I described above, Atom
feeds, and existing automated use of key servers, have always had this
problem.

(Also, people trying to remain anonymous need to do quite a bit more
than just not automatically fetch PGP keys. It requires using an
operating system designed for such a use-case, like Tails, in which case subscribing to keylists would be perfect fine, and would not compromise
anonymity.)

> All in all, this seems like an interesting application, and worth
> further discussion (on this list). I am not yet convinced this is
> an protocol issue and not an application issue.
>
> Paul
>

And finally, I'll also reply to Wiktor's feedback. (Quoting in full= for
Miles' sake.)

On 2/13/19 3:10 AM, Wiktor Kwapisiewicz wrote:> Hello,
>
> Excellent points and I'm glad that the draft has been published on= this
> ML for a discussion in a wider audience.
>
> As far as I understood draft-mccain-keylist-02 its goals can already b= e
> achieved with a combination of already existing features:
>
> 1. Discovering keys for company employees - using "e-mail to key&= quot; lookup
> (e.g. WKD)
>
> 2. Trusting that these keys are authentic - by signing an Authority Ke= y
> and setting ownertrust to full. This can be done only once and it work= s
> for all future keys. Even with draft-mccain-keylist-02 one needs to do=
> that to know which keys are trusted. There is one variation of this > scheme - by using Trust Signatures one can trust Authority Key to keys=
> from the company domain only.
>
> 3. Keeping keys up to date - why not just refresh all keys in the loca= l
> keyring? (e.g. `gpg --refresh-keys` or something similar). (GnuPG will=
> refresh expired keys over WKD if they were fetched with WKD [0]).
>
> [0]: https://dev.gnupg.org/T2917
>
> If the problem is that people verify signatures and the keys are not > present I think applications have appropriate options to fetch keys > automatically (e.g. `gpg --auto-key-retrieve`).
>
> I like the point of using .well-known for a keyring of all people but<= br> > from what I've heard on GitHub the ability to host keylist on a > different domain is desired:
>
>> There's no reason to trust the server that hosts the keylist f= ile. We
>> already don't trust it -- FLM hosts our keylist on GitHub.
>
> Source:
>
https://github.com/firs= tlookmedia/keylist-rfc/issues/8#issuecomment-426846582
>
>
> Kind regards,
> Wiktor

I've already addresses some of this, but:

It's important for my company's use-case, and probably that of many=
other organizations, to not tie a keylist to one specific domain name,
and to allow the keylist to include keys for personal email address
(e.g. gma= il.com) as well as keys with UIDs that don't contain email
addresses at all. WKD is simply insufficient for this use-case. (It also has the problem where if a member of the organization updates their key, they can't push their updated key into the WKD like they can to a key server.)

It's true that we could bootstrap a system like `gpg --refresh-keys` combined with cron (or more realistically launchd on macOS) to keep keys up-to-date. But 1) Not all OpenPGP users use gpg and cron, and 2) we
don't necessarily want to update all keys in every user's keychain,= only
the keys on the keylists they're subscribed to. Only refreshing keys listed on a keylist leaks less information to key servers than
refreshing all keys -- it leaks what keylists you're subscribed to.

But, most importantly, and in fact the reason we developed GPG Sync to
begin with (which ultimately lead to writing this draft RFC), what isn'= t
possible with existing tools is to get everyone in an organization to
automatically fetch *new* keys that they otherwise wouldn't be aware of= .

For example, lets say we hire a new intern, and they generate a PGP key
for their m= it.edu email address. How do we get hundreds of people's
computers to automatically fetch that key so they can email this intern
without having to do manually fetch it and verify it first? Or, let's say an employee loses their Yubikey, so they publish their revocation
certificate and generate a new key. How do we get those hundreds of
computers to fetch the revoked key, as well as the new key, so that the
next time someone sends an encrypted email to that person, it just works?
--0000000000006e9b4105836eb8c0-- From nobody Thu Mar 7 08:11:44 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC642127876 for ; Thu, 7 Mar 2019 08:11:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 6u4Inq90hChW for ; Thu, 7 Mar 2019 08:11:22 -0800 (PST) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 189D7124184 for ; Thu, 7 Mar 2019 08:11:21 -0800 (PST) Received: from p54abd93f.dip0.t-ipconnect.de ([84.171.217.63] helo=chu.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1h1vc7-0007EH-4u for openpgp@ietf.org; Thu, 07 Mar 2019 16:11:19 +0000 Date: Thu, 07 Mar 2019 17:11:18 +0100 Message-ID: <87mum6ekbd.wl-neal@walfield.org> From: "Neal H. Walfield" To: openpgp@ietf.org In-Reply-To: <871s3qd4yg.fsf@wheatstone.g10code.de> References: <87mumh33nc.wl-neal@walfield.org> <871s3qd4yg.fsf@wheatstone.g10code.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 16:11:30 -0000 Hi Werner, Thanks for following up. At Fri, 01 Mar 2019 15:50:15 +0100, Werner Koch wrote: > On Wed, 27 Feb 2019 11:51, neal@walfield.org said: > > Consequently, I propose not only imposing a reasonable ceiling on the > > chunk size that even small embedded devices with a cortex M0 could > > handle, but to simply fix the parameter to 16 KiB. It's not clear to > > Without sufficient storage a smaller chunk size does not help you in any > way. You can still run a truncation attack and by that time the > preceding chunks have already been processed in some way because, well, > there was no way to store the entire message. Without the final chunk > you have an incomplete and thus unauthenticated message because the > sender authenticated the entire message and not certain parts of it. It's true that a smaller chunk size doesn't provide protection against truncation attacks. And, I agree with you that for the receiver to protect itself against truncation attacks, it can only release the plaintext after it has authenticated the whole message, which it can only do if it buffers the whole message. But, I strongly disagree that a smaller chunk size does not help us in any way: even in the face of truncation attacks, AE dramatically increases the security of streaming. AE provides ciphertext integrity [1]. Ciphertext integrity means that the ciphertext has been authenticated. That is, used correctly, AE would stop an attack that modifies the ciphertext, like EFAIL. [1] See for instance Chapter 9 of A Graduate Course in Applied Cryptography by Dan Boneh and Victor Shoup for an explanation: https://crypto.stanford.edu/~dabo/cryptobook/BonehShoup_0_4.pdf Since ciphertext integrity is guaranteed at the chunk granularity, the ability to buffer a single chunk is sufficient to ensure ciphertext integrity. Now, if we admit steaming, and historically, OpenPGP has been streaming friendly, then chunks must be small enough to fit in the receiver's available buffer space. This is essential, because the decryption function must reject chunks that it can't authenticate [2]; releasing unauthenticated plaintext break's AE's security guarantees. [2] RFC 5116, Section 2.2: "[The authenticated decryption operation] has only a single output, either a plaintext value P or a special symbol FAIL that indicates that the inputs are not authentic." https://tools.ietf.org/html/rfc5116#section-2.2 On the other hand, if if we prohibit streaming, well, no, someone is going to do it anyway. So, we should just accommodate it as best we can. Given streaming, for me, the logical consequence is that we need to somehow figure out an appropriate chunk size (or sizes). Since the sender can rarely make a sensible choice, and the chunk size doesn't change AEAD's security properties, I've concluded that the most sensible choice maximizes the number of devices that can decrypt messages, which means making the chunk size as small as possible without adversely impacting performance, e.g., 16 kiB or 256 kiB. (Note: using a small chunk size doesn't mean that an implementation has to release a chunk as soon as it is authenticated. An implementation can frustrate truncation attacks by ensuring that at least, say, 25 MB of data remain buffered as long as it has not encountered the end of the file. FWIW, this is what Sequoia does.) Let's assume that there are cases where we don't care about ciphertext integrity, and a larger chunk size is better for some reason. To accommodate these cases, we could allow implementations to emit unauthenticated data if a large chunk size is used. We can even fix the threshold in the specification so that senders can be sure that messages that need ciphertext integrity are processed in a more secure manner. Unfortunately, some basic testing using a hacked version of Sequoia suggests that an attacker can just take a message with a chunk size < X and change the chunk size to be larger than X, and Sequoia will happily emit the first chunk, because the chunk size parameter is only checked after the first chunk is authenticated! Ouch. But, it's worse. We can further defeat any opportunistic buffering without appending a lot of garbage by wrapping the AEAD packet in a Compression packet that is jammed at the end with a decompression bomb. Thus, the size of the message is only marginally larger than the original message! For me, this means that if we want AEAD's security properties, and I think we do, we can't allow implementations to emit unauthenticated plaintext. Although we can write in the specification that implementations MUST return "EBUYABIGGERCOMPUTER" if the chunk size is too large, implementors will almost certainly ignore this, because security must not get in the way of a user getting her job done. In fact, there is already an OpenPGP implementation that does this. The better way, I think, is to make it hard to do it wrong. And that means using a small, fixed chunk size. If my argumentation and authority are too weak, perhaps Adam Langley can convince you. In his 2015 talk, he addresses exactly this problem and why it is essential to support chunking even though it enables truncation attacks. The relevant discussion starts at 18:20, but the most important bit (quoted below) starts at 22:43: Let's say the attacker does cut here. They can only cut between chunks, because you'll figure that you. But, they cut here. You will know that it is not the correct end, because you never saw this tag on the AD. But, if you are piping it straight into bash, the attacker still managed to truncated things. The only way around this is to buffer the whole thing to disk before you release any plain text. And, now you might think, "well, if I'm doing that, why did I put all this effort into chunking?" And, I'd like to do a quick aside here on what I call Adam's rule of weak crypto. Another common thing that people come up with is---and suggest---is that they've done a careful analysis and they only need n-bit security where n is 80, or, if it is particularly weak, 40, and they have a very carefully argued plan about why what they are protecting is almost meaningless. Like, they almost wouldn't bother with cryptography and they've got very tight bandwidth overheads, like bluetooth LE is a very common one. And, so they are going to do 40-bit security or something similar. And, they're correct. Their argument is perfectly reasonable. They still shouldn't do it. They reason is that the Internet is built out of whatever was laying around. It's like children with lego. Things are never designed, you'll carefully reasoned argument about why this is completely correct will be discarded almost immediately. And in the future, someone you've never met, and may never met, and may never talk to, will pick up your think and go: "oh, it's cryptography, right, this is fine, I'll build on it". And then 10 years down the road, we find we have some massive societal-wide flaw, in some very important system, because they built it out of your weak system, never understanding the basis. So, you should still do [AEAD chunking], because if your argument is that we need to buffer everything, because of truncation attacks, so we're going to buffer everything, so we're going to have one huge chunk, because it doesn't make any difference, someone will come along in the future, they will discard your very carefully reasoned argument, they will go: "oh, I'm running on an embedded system, I don't have enough disk space, my messages are too large", and they will stream it, and it is still your fault, even though they screwed up. So, for the people who are going to stream it, you should do as well as you can, which is [AEAD chunking]. Yahoo Trust Unconference: TLS, Adam Langley (2015) https://finance.yahoo.com/video/yahoo-trust-unconference-tls-adam-223046696.html?guccounter=1 > Let me repeat it again: The chunking was introduced for just one > purpose: To be able to detect rare transmission errors earlier than at > the end of the message. I agree that AEAD helps detect transmission errors earlier. But, AEAD does so much more than that. In particular, it prevents attacks like EFAIL. It seems to me that it's worth adapting to this new threat. Even if everyone accepts that the AEAD packet should only be used for detecting transmission errors early, then in the very least, we need to rename it. AEAD has a specific technical meaning, and as currently realized, 4880bis makes it very hard to meet those expectations. This will come back and bite us in the foot. > For large pipes large chunks are a sensible > choice. I don't understand this argument. The buffer size ought to be independent of the chunk size. AEAD doesn't say that as soon as a chunk is authenticated it must be released; if you want, your implementation can buffer 128 megabytes of data even if AEAD uses 16 kilobyte chunks. I'd like to summarize your concerns as I understand them. Please correct me, add anything that you haven't yet mentioned, or fill in something that I left out. 1. Because AEAD doesn't protect against truncation attacks, streaming is as insecure as it ever was. 2. The sole purpose of AEAD chunking is to detect transmission errors early. 3. Small chunk sizes are bad for IPC. My reactions: 1. Although AEAD doesn't protect against truncation attacks, it does increase protection, because it would protect against ciphertext modifications as done in EFAIL. 2. Perhaps when AEAD was introduced that was the sole reason, but with a small tweak, AEAD can be used to increase security in other settings. 3. You don't have to release chunks as soon as they are authenticated, so you can make your buffer really large, if you like. If you are adverse to changing packet 20, then let's just mark 20 as reserved and create a new packet, 21, which changes the semantics. Thanks, Neal From nobody Thu Mar 7 09:09:38 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9DB129A86 for ; Thu, 7 Mar 2019 09:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 05E9zvDBGkXZ for ; Thu, 7 Mar 2019 09:09:29 -0800 (PST) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 BE730126C7E for ; Thu, 7 Mar 2019 09:09:29 -0800 (PST) Received: from p54abd93f.dip0.t-ipconnect.de ([84.171.217.63] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1h1wWG-0000E4-6v; Thu, 07 Mar 2019 17:09:20 +0000 Date: Thu, 07 Mar 2019 18:09:19 +0100 Message-ID: <878sxqy5kw.wl-neal@walfield.org> From: "Neal H. Walfield" To: Tobias Mueller Cc: Jon Callas , Bart Butler , "openpgp@ietf.org" , Vincent Breitmoser In-Reply-To: <2a014c4a103ba7f52535546f7e77277ea2bdabdf.camel@cryptobitch.de> References: <87mumh33nc.wl-neal@walfield.org> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> <87h8co2t4v.wl-neal@walfield.org> <35C892F7-18A8-401E-828D-5CE180A3A731@icloud.com> <87r2brf0f1.wl-neal@walfield.org> <2a014c4a103ba7f52535546f7e77277ea2bdabdf.camel@cryptobitch.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 17:09:36 -0000 Hi Tobi, On Sun, 03 Mar 2019 19:36:08 +0100, Tobias Mueller wrote: > By fixing a "chunk size" you take away the ability to benefit from AE > for messages bigger than that size. > Implementations could easily collect all chunks and only release the > plaintext once all chunks check out successfully. But that could go > wrong. And depending on implementations to get things right and clients > to use those implementations correctly is exactly what enabled Efail to > become an issue. I think it'd be much nicer if the protocol already > ensures that my emails do indeed enjoy protection against modification > rather than me having to rely too much on clients getting it right. You're afraid of bugs. So am I. Dynamically resizing buffers is error prone. Even computing AEAD's chunk size is hard: #include int chunk_size(int c) { return 2 << (c + 6); } int main(int argc, char *argv[]) { printf("%d\n", chunk_size(32)); } $ gcc -Wall a.c $ ./a.out 128 (Note that gcc doesn't even produce a warning!) But, that's not all. If there is the possibility of failing due to a lack of buffer space, implementors won't bother. And they won't bother for a very good reason: users want to get work done. If a security policy prevents them from getting their work done, they will disable it. Or, an implementation will ignore it. And, because it is only a problem if there is an attack, users will be thankful for the more "powerful" solution. The secure implementation must be easy for both developers and users. And the secure implementation is a small, fixed sized buffer, even if that means the client may have to worry about truncation. > Having said that, I understand the desire for fixing a chunk size to > reduce complexity for implementers. My desire as a user is to have a > strong and resilient protocol. Perhaps you're not a typical user :D. > Is there another way to do real AE? Chunked AE is still real AE: it still has ciphertext integrity; it is just susceptible to truncation attacks. That's not to say that truncation attacks are not a serious issue, but I'd rather have truncation attacks than truncation attacks *and* ciphertext modication attacks. :) Neal P.S. Consider realloc. It is only marginally easier to write this wrong code: p = realloc(p, 2 * size); if (! p) { // Oops, p has been leaked! return ENOMEM; } than this code: void *temp = realloc(p, 2 * size); if (! temp) { free(p); return ENOMEM; } p = temp; but I see lots of instances of the former when reading code. From nobody Fri Mar 8 07:40:15 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A9F130EE7 for ; Fri, 8 Mar 2019 07:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.998 X-Spam-Level: X-Spam-Status: No, score=-6.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org 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 KFS6ZSRhwsMU for ; Fri, 8 Mar 2019 07:40:12 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 229D612865D for ; Fri, 8 Mar 2019 07:40:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:References:Date: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=kI+fWcOPm20tM3zw8Llwv/f5cp+ZefR5POAfLHlU7Lk=; b=NAstpDTBhnl2ICccUKdBMDQXe7 WthxXI6rjE/iIGgD4UmKBfBQOzbWeQUx4Kc07fr3PRDs6yg3litLuIquXjCLNuJp4TAHP6lndhcWq PjW3fOfYCk4D3NE/XffGBxDsLRDdGSVokwZC8wpfSingiynoKwEzvuoBIny08uQybxwo=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1h2HbV-0007Jq-Fq for ; Fri, 08 Mar 2019 16:40:09 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1h2HaV-0005Vh-OE; Fri, 08 Mar 2019 16:39:07 +0100 From: Werner Koch To: "Derek Atkins" Cc: "Justus Winter" , openpgp@ietf.org In-Reply-To: <48eadafb01b3c6e3872380cac3863c98.squirrel@mail2.ihtfp.org> (Derek Atkins's message of "Mon, 4 Mar 2019 10:35:37 -0500") Date: Tue, 05 Mar 2019 11:21:09 +0100 References: <546b32d041f2cd0227aaa737f8841b26.squirrel@mail2.ihtfp.org> <48eadafb01b3c6e3872380cac3863c98.squirrel@mail2.ihtfp.org> User-Agent: Gnus/5.13 (Gnus v5.13) Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: "Derek Atkins" , "Justus Winter" , openpgp@ietf.org Message-ID: <87a7i574v8.fsf@wheatstone.g10code.de> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] User ID Attribute Subpacket X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 15:40:14 -0000 Hi! [The mail got stuck somewhere in the IETF mail system - resending] On Mon, 4 Mar 2019 10:35, derek@ihtfp.com said: > But to answer your question, yes, I want to have a UserID and an Image > with one binding signature -- and possibly additional future attribute > subpackets, too. May I suggest to add a sample of such a packet to appendix A to avoid confusion by future implementation work? > I should note that, having implemented this, the additional code to handle > this is actually quite small! You can actually reuse a great deal, so > really it's just a protocol number and an additional branch. I concur (although I have not yet come around to implement this in gpg). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Fri Mar 8 07:40:23 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3801912865D for ; Fri, 8 Mar 2019 07:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.593 X-Spam-Level: X-Spam-Status: No, score=-3.593 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_96_XX=3.405, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org 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 Fzg1wou-dWIM for ; Fri, 8 Mar 2019 07:40:12 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22DB9129570 for ; Fri, 8 Mar 2019 07:40:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:to:References:Date: In-Reply-To:Subject:From:Sender:Reply-To:Cc:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=1/cPjeCBuoXWW2LxPWZFtlRxDNWVSIrfOqb5dK9P0UU=; b=XlNtj5E5DES6TUeEqzw3ZV4wjA hemKttW6rOqcMoYnsDy1o7u3CW0R6bRgBW3FwleTSYdk2MZOqaiyn2nbL/WpIvDEMQkrSxgxLQ8Tc 6DXZsvFHMVoqmcdnH5b0rxqaVRXeOa+cuT2QtUbOAiEzqMXMpyBNCCR7/r/5RXAciWM4=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1h2HbV-0007Jn-9R for ; Fri, 08 Mar 2019 16:40:09 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1h2HZx-0005VJ-Pn for ; Fri, 08 Mar 2019 16:38:33 +0100 From: Werner Koch In-Reply-To: <87mumh33nc.wl-neal@walfield.org> (Neal H. Walfield's message of "Wed, 27 Feb 2019 11:51:51 +0100") Date: Fri, 01 Mar 2019 15:50:15 +0100 References: <87mumh33nc.wl-neal@walfield.org> User-Agent: Gnus/5.13 (Gnus v5.13) to: openpgp@ietf.org Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: "Neal H. Walfield" , openpgp@ietf.org Message-ID: <87d0n174w6.fsf@wheatstone.g10code.de> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 15:40:15 -0000 Hi! [The mail got stuck somewhere in the IETF mail system - resending] On Wed, 27 Feb 2019 11:51, neal@walfield.org said: > Consequently, I propose not only imposing a reasonable ceiling on the > chunk size that even small embedded devices with a cortex M0 could > handle, but to simply fix the parameter to 16 KiB. It's not clear to Without sufficient storage a smaller chunk size does not help you in any way. You can still run a truncation attack and by that time the preceding chunks have already been processed in some way because, well, there was no way to store the entire message. Without the final chunk you have an incomplete and thus unauthenticated message because the sender authenticated the entire message and not certain parts of it. If you like to adhere in your _implementation_ to some _API_ proposal, go ahead and use it but the API is not a _protocol_ thing. Let me repeat it again: The chunking was introduced for just one purpose: To be able to detect rare transmission errors earlier than at the end of the message. For large pipes large chunks are a sensible choice. Changing the protocol in a way as suggested by you is not an option anymore. We can change recommendations, though. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Mon Mar 11 04:43:56 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E0C131036 for ; Mon, 11 Mar 2019 04:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=my.amazin.horse 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 VXT2myshGfIH for ; Mon, 11 Mar 2019 04:43:54 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E56B0129AA0 for ; Mon, 11 Mar 2019 04:43:53 -0700 (PDT) Received: from localhost (ip5f5abc23.dynamic.kabel-deutschland.de [95.90.188.35]) by mail.mugenguild.com (Postfix) with ESMTPSA id BDF355FA26; Mon, 11 Mar 2019 12:43:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=my.amazin.horse; s=mail; t=1552304631; bh=cNlr1ShGO8R5WXCBxgkabZw3/p3Wk1yJH38MnPG5sY4=; h=Date:From:To:Subject:Autocrypt:From; b=QZgR+5uCy+cRU7BPES8k0cZtN32395ZRt4kKQcfsDejDhHAzO/Tpfya4L+jzPFRhA jdzWO2tb4cH0F9HHDCNziiY+EAFs9f8nDb94iUfLMnurMSQJwsndL/kHwZKUUcB2ph twY/rP5iYvK4hYsgs8+SsBEpdnhgI35N4Z9Ond/Q= Message-Id: <3GFS71V7BTJNZ.29C5TO8OY0O44@my.amazin.horse> In-Reply-To: <87d0n174w6.fsf@wheatstone.g10code.de> References: <87d0n174w6.fsf@wheatstone.g10code.de> <87mumh33nc.wl-neal@walfield.org> Date: Mon, 11 Mar 2019 12:43:49 +0100 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Vincent Breitmoser To: Werner Koch Cc: openpgp@ietf.org Autocrypt: addr=look@my.amazin.horse; keydata=mQINBFAB3UABEADCyB/vbIBA3m1Bwc yjTieEMLySwYgt54EQ2hglOocdtIhqC+b05t6sLSkwx2ukxrU2cegnCBkdyF/FZ/+Et638CUEBbf 4bjplwpt2IPLazQgjkwjMuhz0OcYDpMhwimTvh3mIl+0wzpOts6mEmMw0QZdl3RXvIW+NSynOn7q mz/fAv4Htt6lv2Ka0s6R2voyi+5U7CcIqizPad5qZVn2uxmovcFreTzFt6nk37ZbbTfvA3e5F0bR RQeH3viT5XxpJF4Y76v/Ua+5N3Kd18K0sX85rD1G7cmxR2CZ5gW1X24sDqdYZdDbf10N39UIwjJH PTeuVMQqry792Ap0Etyj135YFCE0loDnZYKvy2Y1i0RuEdTUIonIHrLhe2J0bXQGbQImHIyMgB9/ lva8D+yvy2gyf2vjRhmJEEco7w9FdzP7p3PhKrUiTjRsjHw8iV8LOCFx9njZOq9mism9ZZ16tZpx 9mXOf11HcH1RtVuyyQRS/4ytQPzwshXdSDDW6Btkmo9AbZQKC54/hSyzpp3Br2T2xDH7ecnonDB/ jv8rWuKXSTbX3xWAIrNBNDcTYaNe4jkms4HF7jJE19eRlqsXMMx6Fxvrh4TtKICwJYJ3AUmXrK3X Ti/mjqYfJ1fpBn54rWs8nhSR1fuZPD+aMlcP8BDUPlNKPKtj0DGSh3/VlnnwARAQABtClWaW5jZW 50IEJyZWl0bW9zZXIgPGxvb2tAbXkuYW1hemluLmhvcnNlPokCOAQTAQIAIgUCVTNZmgIbAwYLCQ gHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQe9GDIN6t+hHcVg//aeiijNqsQ3pjbFQn3VvND7hNfJ vrVcLZ+U4kOzXPF818aVdOnDyNXyE17vBDDcvaZ730sCsZIRZJ3KhUJ+nPvdttKjUIGLARmx+pA3 Jl3IIv2uLtOb3I0TMuyfIGJVGF+q10/CeDMKVjKlmyOVrR0opkel+KEoN7VLq3Hf3zPKENO1HBgp LHeP31tlb9cgs+u4o2wLrVe9myHbuFBW7EjWbSvdz2zliwbsFeFVLMNcWrKAU0GkkiH69SgnwmXU RkhGma4L27GLtkHHufsxfbcPqPtmtCttsGZU4EmrghGUqVyDOxnn8ZqybzLrRfpin+OCIX+aHJz5 r2L8qtrP0LorNMX3Gopd26vfhNvq/wq8xk++bW1R5FmkaUhx9h+DhO2ybcg7p/E8JHc8zrWv+bb3 0o9lkrOaU8GxXrgtb1cjtbb+MxFvjm0Elw7MSZDG7sF/APFU6cwuIA9Nai/OGAUCSt/W2ecS8Zox cWWbGSEiDvjtEctkpmHjfVuGoL34966Olm41VdH+NjgoSYUJKx4Mty8DRcZxdyoXll84LvDkEEYK ZqOIACsJf8CDFvUkmhXc+moCj15Yxtj3/RslRVEiOUyrpDwB72zWcZG8YnzoyGxhcRIc/gFejO/y SI8bzCpYngeuTb5NjFG+ChGiInHbQcFeHBlaHtKi2o/B5axIO5Ag0EVDvOgQEQALJby/ztliToGE u1lslvWQUQ6teKZVUQ7hy9bM4N83G0AGLatUBHtY6PkJBe4XkIw3sK7LoFCV2W4GSt4zWp9l+kG3 /J8Ow7EFjN0F7DrCg0M0lMg9dQz9jYSoBR8skaH3BRzCq9AKIVKV94poL/G65289L7zKDHoZnnyF qbBtedYZir0SZx+kiouZ1qnmxRPaYmH2fkuiuvYEAyzLDLYM8F5gQhdZM4YVtuvSICYPet0z4CDi JX/vZmDi3AzzoEVaKeAM/0H9f9Ni547J2+8dZSllgTrA+fq0aMJVScAObIxTAQtEq0DoNBzPpVrm W10b4bmgePrAvNkifqSr5StymSBgwvoeW6GrJiyN4XhoLOadZzwgjqioR1nXw5tXtrr5sYdkZ06b 1WWHkxtu1hFTdLC7RYNxY07ytLNM+C2lplCwCwlWB7RwI9BL1Dhre4kv8uaaX2Gksaq9mDf9MSDW qQ0TJ/RAiwMGmFrzBEYI1J2Oyeshi/dqW4/OiZAukOIlxOnt6u8zU2KL6Qjxqqna0oTbS4Zv3fRd YkuUCL6CDEJdkuRAiW+Gw+lKcMjXqApEqixhaDkoB/kwtu+2gIFTzAxMfwFN1YtNc0kJZWnFkGIW MrrwTcOwAFzlFz7wn/EyMFtg+ERcqMX0+olXDwM8MODI2+BzulPuEDEteCw09hABEBAAGJAh8EGA ECAAkFAlQ7zoECGwwACgkQe9GDIN6t+hFjuQ//UQyg49f8TytUYQaBb8R0UfI+KhQFs1Nsz2z8a3 0CD1MeiHHYWdAcomVvTkg4g5LbnYHVDrj/XagY3FN/AIE97usFbsTG+rsWAOLi7N2dN2ehWZ634k MvrgyC9uTiOdkw31+B8K5MpyySgD8e6SAzRfiu06/bcQOUyJifw8Hudpj9by4uyGhSH+kHu4afrp OduUighbsGFtcuRwwQ/w/oSk68XvPUgiOQWMZh/pVoXdFyFvrt/hgArCi8dfy5UPK58nl7jPnu/I uQXrJ50nNAFIIxPVeo2/B83KAnEZPU+qWZsdba0V+FIIQQVizLtQFMuJJk4/UTAOfJ2tBpQ9PADX 6/scqDE7unXNWdxcHTjK7KmWjXC8CyhGOx8V/rb7Ial4mZo4cTED6SNlO7dV1XYwnSctL2HCYNM3 RUe4eJ7JWuu7/Nbf6yip2eq7BQKZ9hAH/se/OSZNYsEkZ4pxUc8W5U3uAZImUwC6L74SM0jBZIuD mQhOYX6sZZ6urIn/MYlj4/hqSBFS4vTK7nXRLmtr7+5T5U5srVseUiYc+l9pu9/XD8zGIu+M2xEd 41NwP44GDQTQm0bFljRv5fSblwmi56YHPFQUIh2RZNX3kOJgeyQ3enw5uY+7ocKRVP38hpnffliL lJcO6TtHWnElS3pACbTQM0RHJox3zqU3q6K3c= Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 11:43:56 -0000 > The chunking was introduced for just one purpose: To be able to detect rare > transmission errors earlier than at the end of the message. ..really? All this is just to save a few cpu cycles in the rare cases of data corruption that should have been handled by other layers (filesystem / transport layer) in the first place? Why even bother? That said, I don't believe this is the long agreed upon and tiredly repeated fact you phrased it to be. Consistenly specced, chunked AE contributes to better behavior on average in implementations wrt emitting or processing authenticated data. I fully agree with Adam's argument about this that Neal quoted. > Changing the protocol in a way as suggested by you is not an option > anymore. Oh. Why? - V From nobody Tue Mar 12 23:32:22 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62257130E8D for ; Tue, 12 Mar 2019 23:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 nF3Ky9wbAGQs for ; Tue, 12 Mar 2019 23:32:18 -0700 (PDT) Received: from mail.fh-muenster.de (mail.fh-muenster.de [212.201.120.190]) by ietfa.amsl.com (Postfix) with ESMTP id 910FD12008F for ; Tue, 12 Mar 2019 23:32:17 -0700 (PDT) Received: from [192.168.1.80] (x2f4277b.dyn.telefonica.de [2.244.39.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: ss560221) by mail.fh-muenster.de (Postfix) with ESMTPSA id 409082846E8 for ; Wed, 13 Mar 2019 07:32:15 +0100 (CET) From: Sebastian Schinzel To: openpgp@ietf.org References: <87mumh33nc.wl-neal@walfield.org> <87d0n174w6.fsf@wheatstone.g10code.de> Openpgp: preference=signencrypt Autocrypt: addr=schinzel@fh-muenster.de; prefer-encrypt=mutual; keydata= mQINBFOa+aQBEADFp3ZEX5454aNLUNuYBsrD65WKrXRzU5v1KAWCcm14fzqn1wbfjheSe3Rt EfsxQjHdCb9vJWv2A1j4ZIA7AUcfs8GFOYIkCTAeFtJ1XuFbyPJO+gO9jnWk9+Af3Pt5RVAq 4ReOTVF19v+VS02jNe0lEAMxmqhKGuKHWe4yhRigS+QHCnd3davvcWpyPbjFAE4RHfKkbej9 mNXFlC21u/kKyXr/PJ+1HkJ0lMXZ7CM4unJV0mPk+Z0r5meyGZBxOoJpJO9V/bc69u2jgF/3 wVnOIAwGiPJxLn7PFQ+k8Bs14X+ZVGEbk0iRmnRqFQgptkw5J0sRUiPij6CApyqEqUKQfzAk KXH3wEWQjCrm8dcucwIl7bWYFId/PMJDuh3Pj8kXVhxSZd0oTwCJiPnetI2ltAT8BpAO+6XF WTd7k5VH+HaJ3d607UhKsO8x1yt78v3/YrbN2uehG87sEtCk0DTPFzCJR/EI42QGIBDiQIi+ WvhofaEFSyLpwuDWvFJReXdm1Vz78AvOwDB+/HJHnePQYAP+F1owupJtK5ifluJ2A6isbFIj pIZDn8n1xXbuScMrFRsF7wlCnuBbfAlheb5cTucXCD8A18Zqb7q1sYtA3K5GgTbR47jUTM5d E2DxPHrZJ5dcfzercSavWEO5rKJPTpFGi1REA2vUOww6XkUFqQARAQABtCxTZWJhc3RpYW4g U2NoaW56ZWwgPHNjaGluemVsQGZoLW11ZW5zdGVyLmRlPokCPgQTAQoAKAIbAwYLCQgHAwIG FQgCCQoLBBYCAwECHgECF4AFAll/HL8FCQ9KJJsACgkQak2UVL9+7zVtJA//ZUwXrdxsHf0n RXqNaQ3yWN1Bj//KN0OQFyqBv+aVqmvqn6gPGpW8u1xRht3DQxtGCNN7x2QAsI9meUkETPqG 36P4KTjkRDHcXIVmyyxKXKxNCpa0w4hC5fGhR4h9PIHTSgAqPCB7Hi6JSveDHf4AyO0gNkez dQ8OGHT4uwLwH9ELR7An9F3asF8L5Ym7xTqBRrWtfXsQG+UnWO+oJXrLKsaB7k3iQWK6Ms9x LKVNphJh7PWw/l9dvlGN/HpnT/JNI+QoCzgO1Qyq1ixKFwj+wJXF/Tgrrkp4g7lZJc5ldZju gudXltEolN7lGYTtjvm2Qu3ubOAFWqSdMUEHMZRL7mWmff4td0foasuUX5KPa9F1TKip3G9A WyHNOR/nqIxzGCyylMEsjHCaCiwqLScBa1OHs7QTHUEtCw6oaHDvohLuKY9FKypieLkyzTp/ PpQR+NRQfk3JD3W0YAhMO8vDIHthA0JUk9ms+WObDqb/aVuKiHkZ3wiibArP/CR5S/7Z6HTS 2pTGIkGd+/qDKlAfz7+KLmb5mDRiDPmVn1keHPy8v86o9ZaxcalAdZ7wwmJrLu6CBitKRFIL mvY9LjeTYqtYEakS5xl6yTG+7ybGrkUycMLs1mmrrJ8CH9AAlLAVmpTKlGQrEiDusp/6R/fQ EVTUtqCJpb+XugVhvl/+H7e5Ag0EU5r5pAEQANSMW8nfA44amRxmxyfCbN4YFD8knSZN8QOW fR/JV6UTUWnHmdxkg01RHEA43o0Ec0rCJdGFhCj5wtii4UimMLLgLIWIrneKNkNrrU9HnOJw qv81etFvmIny1l6ac7Z6MAVf4jssVXq4ZjI1SLXz3FDGPY09wraafiHvzirQO5FUzfdM6/PA 0TOQ0jkCO7kE/mtMXq1Qbb17NOY+ixzx260Er5TSunFKKVDPCelFS1aAEwnXpb/chLb4luVb Fb67jkpIJTF+rc3it5G4Q2RxFgmky/n/XA+HM3UAMjyteASPSrHi7JkjerOibudK3bZ1OIxc 2MOSTOBJuJc7KZ7a8chr8TiQcABz5KNpYlHEPbR4P/dYdwPcnKtAaZev1Zpm1CfRJFumnsSV RuoQWxeVJgd3L8zkcCib9K8fOIy0iAXb5q1ganOWmxJ26xzFHF/IVvt92IYV635nAAbt5M6V 3Oqj9w6XHTTwNMHtL7D1EaVqdzVxmEd3DXjoYCMiLW8rdmeL28wpS6qONDQcBTfHdNJEmZxa SC9q5lKNjmzUT+TmJYlmAy3q1FvC0feChd+QbOzJkUbYaw+MlHsdn18c+YGER3xTeK4yAxVm VLLDSzKkT+cXiypGZHsoj7ODxAY4H1iRkegZtXw/FyuCzGjewkeAbZ3Ih8FevLK44Dp2PMpj ABEBAAGJAiUEGAEKAA8CGwwFAll/HM4FCQ9KJKoACgkQak2UVL9+7zWenA//ZvwzOE1vosy6 VOTfuIs4fdx/0qxIRKaAyuQzKDEH+OhzgugFs76vBS143mWJ44jk4YvifKEVG0OomPNFs2q/ 2FjDPr1b5QUOGeTV2Cs3HoMr9mOp1OvO748RW3MHWBx5dof1Jlb4jXuatBbxSf9tp6b9JLNd gD9s3tvGog7bLhoGyHRzN9kG8GlHwEwGxuVjevkVcvtROfqdPqf/9Es9W4g4Sru6Z0bfW5fE Yrt8qSMllfis0colsHaXPpO0AmtVwDO5i7bMFfADAUcUzXFWnqsaCkZr0lj8bLrXCOSCPgFe rNcJFnoiH0FgbbFisQfM/T10lan/ZbSuCtQICGmfYmnu4uaiZFq4Y/4rEwSCLesyqrsJ6ps3 P8FO6PagYKZQ/TtSYNREy/LF1wsS6LccmDLU5QOfSx2E3uHRAOKnTARjrEOvPmRz6ILagOXL zDU8yQbjoqyQLbS/Ow2B/i38L/2Xo/xJ1JTF/LwyQ0HNonEC8Y48V3eBtGiw2LFFO8c8Cdgk t3h5BoTQAZsvrCvfSxMG5S307auaEJ+e+JiN2WZk/QUbAg+CpuGhjtz1LpG6KlA1k3pgWDpN zLOPLANGHQ8IQtKY4rnbAykdVavIGOnPj392VL5Pbpk+fqfDiKJ0DjODjoayR+SXdKIL+KFH ymIDIdjRsvAC1KRImp6PDpo= Message-ID: Date: Wed, 13 Mar 2019 07:32:14 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <87d0n174w6.fsf@wheatstone.g10code.de> Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 06:32:20 -0000 Am 01.03.19 um 15:50 schrieb Werner Koch: >> Consequently, I propose not only imposing a reasonable ceiling on the >> chunk size that even small embedded devices with a cortex M0 could >> handle, but to simply fix the parameter to 16 KiB. It's not clear to > > Without sufficient storage a smaller chunk size does not help you in any > way. You can still run a truncation attack and by that time the > preceding chunks have already been processed in some way because, well, > there was no way to store the entire message. Without the final chunk > you have an incomplete and thus unauthenticated message because the > sender authenticated the entire message and not certain parts of it. Chosen ciphertext attacks and truncation attacks are two different attack classes, with different assumptions on the plaintext format and the necessary attacker capabilities. Neal's proposal to mandate a small and fixed chunk size can solve ciphertext malleability for future OpenPGP applications. Waving this proposal off, just because it won't also solve truncation attacks, does not make sense. Best Sebastian From nobody Wed Mar 13 06:14:56 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEA4130DCB for ; Wed, 13 Mar 2019 06:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.089 X-Spam-Level: X-Spam-Status: No, score=-0.089 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com 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 WYx3hs6eZWEF for ; Wed, 13 Mar 2019 06:14:51 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8010124B0C for ; Wed, 13 Mar 2019 06:14:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 966DFE2042; Wed, 13 Mar 2019 09:14:49 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 30247-02; Wed, 13 Mar 2019 09:14:42 -0400 (EDT) Received: from securerf.ihtfp.org (99-46-190-172.lightspeed.tukrga.sbcglobal.net [99.46.190.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 06ABBE2040; Wed, 13 Mar 2019 09:14:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1552482882; bh=HyAb6JUn/6DZ2ONNXvw2uubyXaRZU490WRaMJ39NtrI=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=NtAlZp7OJ9pyO5w+IbWJCkNlS2MF+Hwc16MAW7YiC8roUO5ayRNa/KAEZyPnjOSln iAPn8kUKrpkzKUt3/A9SKFVGu/PaAImGs7dEGsItDoz8waSkM8kwFaIh5CydiJzmJx z4cwvRkGR1VbmCqszqfUhu0D0C098tQSvLHdQWKY= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id x2DDEcrs012459; Wed, 13 Mar 2019 09:14:38 -0400 From: Derek Atkins To: Vincent Breitmoser Cc: Werner Koch , openpgp@ietf.org References: <87d0n174w6.fsf@wheatstone.g10code.de> <87mumh33nc.wl-neal@walfield.org> <3GFS71V7BTJNZ.29C5TO8OY0O44@my.amazin.horse> Date: Wed, 13 Mar 2019 09:14:37 -0400 In-Reply-To: <3GFS71V7BTJNZ.29C5TO8OY0O44@my.amazin.horse> (Vincent Breitmoser's message of "Mon, 11 Mar 2019 12:43:49 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 13:14:54 -0000 Vincent Breitmoser writes: >> The chunking was introduced for just one purpose: To be able to detect rare >> transmission errors earlier than at the end of the message. > > ...really? All this is just to save a few cpu cycles in the rare cases of data > corruption that should have been handled by other layers (filesystem / transport > layer) in the first place? Why even bother? No, it is more than that. Imagine using OpenPGP to encrypt a full filesystem to tape backup. You necessarily want to be able to chunk that as you are saving (and restoring). -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Mar 13 06:27:27 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C8C126DFA for ; Wed, 13 Mar 2019 06:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 4eIcDLlNNJgx for ; Wed, 13 Mar 2019 06:27:22 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 E633B124B0C for ; Wed, 13 Mar 2019 06:27:21 -0700 (PDT) Received: from p54abd93f.dip0.t-ipconnect.de ([84.171.217.63] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1h43uf-0007S9-MD; Wed, 13 Mar 2019 13:27:17 +0000 Date: Wed, 13 Mar 2019 14:27:17 +0100 Message-ID: <87r2bax5u2.wl-neal@walfield.org> From: "Neal H. Walfield" To: Derek Atkins Cc: Vincent Breitmoser , Werner Koch , openpgp@ietf.org In-Reply-To: References: <87d0n174w6.fsf@wheatstone.g10code.de> <87mumh33nc.wl-neal@walfield.org> <3GFS71V7BTJNZ.29C5TO8OY0O44@my.amazin.horse> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 13:27:24 -0000 On Wed, 13 Mar 2019 14:14:37 +0100, Derek Atkins wrote: > Vincent Breitmoser writes: > > >> The chunking was introduced for just one purpose: To be able to detect rare > >> transmission errors earlier than at the end of the message. > > > > ...really? All this is just to save a few cpu cycles in the rare cases of data > > corruption that should have been handled by other layers (filesystem / transport > > layer) in the first place? Why even bother? > > No, it is more than that. Imagine using OpenPGP to encrypt a full > filesystem to tape backup. You necessarily want to be able to chunk > that as you are saving (and restoring). I don't think Vincent is disputing the validity of Werner's use case per se. I think he is saying the marginal utility of that is tiny (it's "just a performance improvement") relative to ciphertext integrity (a security property). From nobody Thu Mar 14 05:36:48 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F190129515 for ; Thu, 14 Mar 2019 05:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com 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 oofARVa4APz8 for ; Thu, 14 Mar 2019 05:36:44 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C46B12008F for ; Thu, 14 Mar 2019 05:36:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id B9B84E2042; Thu, 14 Mar 2019 08:36:41 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 29776-02; Thu, 14 Mar 2019 08:36:40 -0400 (EDT) Received: from securerf.ihtfp.org (99-46-190-172.lightspeed.tukrga.sbcglobal.net [99.46.190.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id AAEA4E2040; Thu, 14 Mar 2019 08:36:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1552567000; bh=+06XbEpoCEq4UAO4/9i5+eGcWJq/vMbvq8dvcB8T5Ro=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=SUr8XyqGRN2pp2QFCYIpZ7MECRxaNO6Ic9qHfrMxo5doqp2H0kd3q5FGPn9jnSeLe muvxFP7B/W7NzmVWuUf8nuX217108rt0eeLFWdRYW8qvF6rfdA54lWLvKFyf1YDAnB wjd89hhF7ZwIsBsM4WJm1/hsRDkWLKbpH8hRZbsg= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id x2ECaZ5d008393; Thu, 14 Mar 2019 08:36:35 -0400 From: Derek Atkins To: "Neal H. Walfield" Cc: Vincent Breitmoser , Werner Koch , openpgp@ietf.org References: <87d0n174w6.fsf@wheatstone.g10code.de> <87mumh33nc.wl-neal@walfield.org> <3GFS71V7BTJNZ.29C5TO8OY0O44@my.amazin.horse> <87r2bax5u2.wl-neal@walfield.org> Date: Thu, 14 Mar 2019 08:36:33 -0400 In-Reply-To: <87r2bax5u2.wl-neal@walfield.org> (Neal H. Walfield's message of "Wed, 13 Mar 2019 14:27:17 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 12:36:47 -0000 Neal, "Neal H. Walfield" writes: >> > ...really? All this is just to save a few cpu cycles in the rare >> > cases of data >> > corruption that should have been handled by other layers >> > (filesystem / transport >> > layer) in the first place? Why even bother? >> >> No, it is more than that. Imagine using OpenPGP to encrypt a full >> filesystem to tape backup. You necessarily want to be able to chunk >> that as you are saving (and restoring). > > I don't think Vincent is disputing the validity of Werner's use case > per se. I think he is saying the marginal utility of that is tiny > (it's "just a performance improvement") relative to ciphertext > integrity (a security property). IMHO it is a bit of both. Again, looking at this historically (having written the original streaming code back in ~1995), the idea was to provide early-notification of cryptographic failure without having to buffer the whole complete message. Granted, this was written before AEAD techniques came into the public eye, but I don't think I would have done it much differently at the time. There were at the time systems with limited RAM and/or temp space, but we still wanted to be able to encrypt & sign LARGE data sets. Again, think of a 'tar -czf - / | pgp ... | ' as the model we were using at the time. If you are on tape, you CAN get "transmission" errors. Think: Bit Rot. It's a real thing. Spinning rust can also have failures, but it's a bit less common. Even RAM can have bit errors -- this is why ECC (error correction, not elliptic curve) RAM is used in servers! Protecting against transmission error, bit rot, etc is just common sense! But the ability to do this in a space that can't "hold" the full data set is exactly why we have streaming capability. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Mar 14 06:47:21 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF61130E11 for ; Thu, 14 Mar 2019 06:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 1a617vhOcLRj for ; Thu, 14 Mar 2019 06:47:17 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 A011C12DD85 for ; Thu, 14 Mar 2019 06:47:17 -0700 (PDT) Received: from p54abd93f.dip0.t-ipconnect.de ([84.171.217.63] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1h4QhX-0004OI-2G; Thu, 14 Mar 2019 13:47:15 +0000 Date: Thu, 14 Mar 2019 14:47:14 +0100 Message-ID: <87pnqtwot9.wl-neal@walfield.org> From: "Neal H. Walfield" To: Derek Atkins Cc: Werner Koch , openpgp@ietf.org, Vincent Breitmoser In-Reply-To: References: <87d0n174w6.fsf@wheatstone.g10code.de> <87mumh33nc.wl-neal@walfield.org> <3GFS71V7BTJNZ.29C5TO8OY0O44@my.amazin.horse> <87r2bax5u2.wl-neal@walfield.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 13:47:20 -0000 On Thu, 14 Mar 2019 13:36:33 +0100, Derek Atkins wrote: > Protecting against transmission error, bit rot, etc is just common > sense! I agree that this is extremely useful. > But the ability to do this in a space that can't "hold" the full data > set is exactly why we have streaming capability. And, I also want to preserve the ability to stream data. AEAD catches not only these errors, but also providers ciphertext integrity. Are you arguing like Werner that catching transmission errors is enough and that we shouldn't bother with ciphertext integrity? From nobody Thu Mar 14 07:10:15 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13383130E6F for ; Thu, 14 Mar 2019 07:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org 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 9CHoHfPo_Tps for ; Thu, 14 Mar 2019 07:10:11 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3800130E6D for ; Thu, 14 Mar 2019 07:10:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Zh/s+p0cR/+YH3lF1TGTsy7+E4NM6KEPCHNt7JGcmSw=; b=KJbAMI5a0nvpK9PSc1t1XeDoyU YhP3XMQCb0Rwfqto7gdiyyM7QmzoTHy6vGRxylZktsONLeVhZIVm2YeKexWvBXVJtH28Kmk7dZ1pa /RBpKv8NonWZYnqbv31oESiymHLUSgF85+w9BWATa0TWDqwtvEhU9hOMdklwwUHRRJIA=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1h4R3h-0000xW-M0 for ; Thu, 14 Mar 2019 15:10:09 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1h4Qzw-0007IE-3P; Thu, 14 Mar 2019 15:06:16 +0100 From: Werner Koch To: "Neal H. Walfield" Cc: Derek Atkins , openpgp@ietf.org, Vincent Breitmoser References: <87d0n174w6.fsf@wheatstone.g10code.de> <87mumh33nc.wl-neal@walfield.org> <3GFS71V7BTJNZ.29C5TO8OY0O44@my.amazin.horse> <87r2bax5u2.wl-neal@walfield.org> <87pnqtwot9.wl-neal@walfield.org> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: "Neal H. Walfield" , Derek Atkins , openpgp@ietf.org, Vincent Breitmoser Date: Thu, 14 Mar 2019 15:06:15 +0100 In-Reply-To: <87pnqtwot9.wl-neal@walfield.org> (Neal H. Walfield's message of "Thu, 14 Mar 2019 14:47:14 +0100") Message-ID: <87y35hy2i0.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=Cyber_security_Human_to_Animal_Disaster_management_Radiation_Disaste"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 14:10:14 -0000 --=Cyber_security_Human_to_Animal_Disaster_management_Radiation_Disaste Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 14 Mar 2019 14:47, neal@walfield.org said: > Are you arguing like Werner that catching transmission errors is > enough and that we shouldn't bother with ciphertext integrity? I never said this. My point was that you are discussing a certain programming pattern on how to implement AEAD modes and I remarked that the OpenPGP standard is about a protocol and not an implementation. BTW, OpenPGP provides ciphertext integrity for more than 15 years. Experience showed that transmission errors are the major cause for false MDC triggered alarms. We want to detect them earlier and not only at the end of the transmission to support real world use cases. The move from CFB+SHA1 to OCB can also be seen in the light of required performance improvements. Salam-Shalom, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=Cyber_security_Human_to_Animal_Disaster_management_Radiation_Disaste Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCXIpf1wAKCRD/gK6dHew1 jSgqAQCar8E71Ye7UZF63RYnno/wid9j5Cmp6JQJhK9em25oiQEAjHe2GLnxEaUm Cyjk/LLiumjDH6WfHZ42d/KE7VmqcAM= =O9bf -----END PGP SIGNATURE----- --=Cyber_security_Human_to_Animal_Disaster_management_Radiation_Disaste-- From nobody Thu Mar 14 07:17:47 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A47B130E82 for ; Thu, 14 Mar 2019 07:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com 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 vqXPtb98GI6x for ; Thu, 14 Mar 2019 07:17:44 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46863130E79 for ; Thu, 14 Mar 2019 07:17:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id D1B2DE2040; Thu, 14 Mar 2019 10:17:42 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 30528-09; Thu, 14 Mar 2019 10:17:41 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 88FB4E2044; Thu, 14 Mar 2019 10:17:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1552573061; bh=fW9RTS3oPogoa2IDdNK1JpMU3ZJob4RJE6fbIu/+qxI=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=kD+9F3BarF4fU2+rGWOMdJ4emdf9npoASGlom68q+Y2WvfHjhPZ4ORdIMwYnJAEeR PthvhQ1dF9rcyVv+s3fgbcELFwBDeT4Fca129PtbSRF2fDgz4XoUvi7LswU21bgiZt 8WY4q89xcn54cOd7y5b1ntwGdzzLzTl9AAYCvTX4= Received: from 99.46.190.172 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Thu, 14 Mar 2019 10:17:41 -0400 Message-ID: <0f7f492bf18145f96e70886ba19ba290.squirrel@mail2.ihtfp.org> In-Reply-To: <87pnqtwot9.wl-neal@walfield.org> References: <87d0n174w6.fsf@wheatstone.g10code.de> <87mumh33nc.wl-neal@walfield.org> <3GFS71V7BTJNZ.29C5TO8OY0O44@my.amazin.horse> <87r2bax5u2.wl-neal@walfield.org> <87pnqtwot9.wl-neal@walfield.org> Date: Thu, 14 Mar 2019 10:17:41 -0400 From: "Derek Atkins" To: "Neal H. Walfield" Cc: "Derek Atkins" , "Werner Koch" , openpgp@ietf.org, "Vincent Breitmoser" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 14:17:46 -0000 On Thu, March 14, 2019 9:47 am, Neal H. Walfield wrote: > > AEAD catches not only these errors, but also providers ciphertext > integrity. > > Are you arguing like Werner that catching transmission errors is > enough and that we shouldn't bother with ciphertext integrity? I don't see how these two are mutually exclusive. Each chunk can provide protection against both a transmission error and ciphertext integrity (per chunk). A simple counter in the chunk header can protect against splicing attacks, so an attacker could not remove a middle chunk or otherwise swap chunk orders. So the only issue is truncation, where an attacker prevents transmission at the end. Obviously the receiver/verifier needs to know how to handle the case of a failure at a chunk or truncation level. What that means, of course, is up to the application. But I don't see how using AEAD per chunk can do anything but help. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Mar 15 04:40:20 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4431F12AF7C for ; Fri, 15 Mar 2019 04:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 H_Z3XzxwNVSY for ; Fri, 15 Mar 2019 04:40:15 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 4B47C128B36 for ; Fri, 15 Mar 2019 04:40:15 -0700 (PDT) Received: from p54abd93f.dip0.t-ipconnect.de ([84.171.217.63] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1h4lC8-0004A3-I5; Fri, 15 Mar 2019 11:40:12 +0000 Date: Fri, 15 Mar 2019 12:40:12 +0100 Message-ID: <87lg1gwelf.wl-neal@walfield.org> From: "Neal H. Walfield" To: "Derek Atkins" Cc: Werner Koch , openpgp@ietf.org, Vincent Breitmoser In-Reply-To: <0f7f492bf18145f96e70886ba19ba290.squirrel@mail2.ihtfp.org> References: <87d0n174w6.fsf@wheatstone.g10code.de> <87mumh33nc.wl-neal@walfield.org> <3GFS71V7BTJNZ.29C5TO8OY0O44@my.amazin.horse> <87r2bax5u2.wl-neal@walfield.org> <87pnqtwot9.wl-neal@walfield.org> <0f7f492bf18145f96e70886ba19ba290.squirrel@mail2.ihtfp.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 11:40:18 -0000 Hi Derek, Thanks for your comments. On Thu, 14 Mar 2019 15:17:41 +0100, Derek Atkins wrote: > On Thu, March 14, 2019 9:47 am, Neal H. Walfield wrote: > > AEAD catches not only these errors, but also providers ciphertext > > integrity. > > > > Are you arguing like Werner that catching transmission errors is > > enough and that we shouldn't bother with ciphertext integrity? > > I don't see how these two are mutually exclusive. These issues aren't mutually exclusive, and I apologize if I gave you the impression that I thought they were. I think everyone agrees that catching transmission errors is desirable. At least, I do :). The sticking point, AFAICT, is that Werner disagrees that the specification should guarantee cipher text integrity when streaming. I'm currently convinced that streaming authenticated plaintext is only possible if we use small chunk sizes. If we allow large chunk sizes (e.g., 4 exabytes, which is what the current draft allows), then there will be cases where an implementation can stream unauthenticated plaintext, but not authenticated data, and, because it can, it will. And this is even though pretty much everyone including the IETF (see RFC 5116 [1]) agrees that AEAD must only emit authenticated plaintext. [1] https://tools.ietf.org/html/rfc5116#section-2.2 Implementations will stream unauthenticated plaintext for interoperability purposes. Failing to decrypt, because the device doesn't have enough resources, will prevent users from getting their work done. And, if security prevents users from getting their work done, then the security mechanism will be worked around. Implementations will stream unauthenticated plaintext to keep their code simple. If we allow implementations to stream unauthenticated plaintext, then streaming authenticated data becomes a special case. And, no one likes to maintain two code paths. Will this happen in practice? IT'S ALREADY HAPPENED. There is already an OpenPGP implementation written by one of 4880bis's editors that emits unauthenticated plaintext. Now, this puts pressure on other implementations to follow suit, because users will inevitably ask why FooGP can decrypt some messages that BarGP can't. I think the only way to prevent this is to ensure that unauthenticated streaming provides as few advantages over authenticated streaming as possible. This means ensuring that the amount of data to be buffered is small, and making the implementation work as simple as possible by using a fixed chunk size. When I originally thought about this problem, I thought that introducing a soft threshold could be an option. But, I've since concluded that this doesn't help. Although a sender could use a small chunk size to ensure that a compliant receiver doesn't emit unauthenticated data, an attacker can change the chunk size in the intercepted message, and successfully conduct an EFAIL-style attack. (See [2].) [2] https://mailarchive.ietf.org/arch/msg/openpgp/WvaisWDd9WzoKXL1FyHDeZNtZ2U Derek, I hope this clarifies my position. Do you now also agree that ensuring cipther text integrity when streaming is desirable? If not, what concerns do you have? Thanks! :) Neal From nobody Fri Mar 15 04:48:25 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A5A128CB7 for ; Fri, 15 Mar 2019 04:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 9lGZxINtBTdh for ; Fri, 15 Mar 2019 04:48:22 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 2D27F128B36 for ; Fri, 15 Mar 2019 04:48:22 -0700 (PDT) Received: from p54abd93f.dip0.t-ipconnect.de ([84.171.217.63] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1h4lJz-0004EI-NQ; Fri, 15 Mar 2019 11:48:19 +0000 Date: Fri, 15 Mar 2019 12:48:19 +0100 Message-ID: <87k1h0we7w.wl-neal@walfield.org> From: "Neal H. Walfield" To: "Neal H. Walfield" , Derek Atkins , openpgp@ietf.org, Vincent Breitmoser In-Reply-To: <87y35hy2i0.fsf@wheatstone.g10code.de> References: <87d0n174w6.fsf@wheatstone.g10code.de> <87mumh33nc.wl-neal@walfield.org> <3GFS71V7BTJNZ.29C5TO8OY0O44@my.amazin.horse> <87r2bax5u2.wl-neal@walfield.org> <87pnqtwot9.wl-neal@walfield.org> <87y35hy2i0.fsf@wheatstone.g10code.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 11:48:24 -0000 On Thu, 14 Mar 2019 15:06:15 +0100, Werner Koch wrote: > On Thu, 14 Mar 2019 14:47, neal@walfield.org said: > > > Are you arguing like Werner that catching transmission errors is > > enough and that we shouldn't bother with ciphertext integrity? > > I never said this. I was referring to this: On Fri, 01 Mar 2019 15:50:15 +0100, Werner Koch wrote: > Let me repeat it again: The chunking was introduced for just one > purpose: To be able to detect rare transmission errors earlier than at > the end of the message. > My point was that you are discussing a certain > programming pattern on how to implement AEAD modes and I remarked that > the OpenPGP standard is about a protocol and not an implementation. I agree that the OpenPGP standard is about a protocol. My suggestions are about fixing a security hole in the proposed protocol. > BTW, OpenPGP provides ciphertext integrity for more than 15 years. But not for streaming, which is what this discussion is about. > Experience showed that transmission errors are the major cause for false > MDC triggered alarms. We want to detect them earlier and not only at > the end of the transmission to support real world use cases. The move > from CFB+SHA1 to OCB can also be seen in the light of required > performance improvements. Performance concerns are secondary to security concerns. But anyway, your argument that large chunks are a sensible choice for large pipes makes no sense, because the protocol doesn't require the implementation to release chunks as soon as they are authenticated; they can be buffered. From nobody Sun Mar 17 12:33:18 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E64C12D829 for ; Sun, 17 Mar 2019 12:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 Tc1TTMMZcW34 for ; Sun, 17 Mar 2019 12:33:14 -0700 (PDT) Received: from bitbox.cryptobit.ch (cryptobit.ch [188.40.138.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8487812B001 for ; Sun, 17 Mar 2019 12:33:14 -0700 (PDT) Received: from unibox (p5B0F5932.dip0.t-ipconnect.de [91.15.89.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.cryptobit.ch (Postfix) with ESMTPSA id 44MqGw08gnz13BZY; Sun, 17 Mar 2019 20:33:11 +0100 (CET) Message-ID: <1f19ab4087fbcd92d085730e38617ab06f0e9954.camel@cryptobitch.de> From: Tobias Mueller To: Sebastian Schinzel , openpgp@ietf.org Date: Sun, 17 Mar 2019 20:33:11 +0100 In-Reply-To: References: <87mumh33nc.wl-neal@walfield.org> <87d0n174w6.fsf@wheatstone.g10code.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2019 19:33:17 -0000 Hi, On Wed, 2019-03-13 at 07:32 +0100, Sebastian Schinzel wrote: > > Without sufficient storage a smaller chunk size does not help you in > > any > > way. You can still run a truncation attack and by that time the > > preceding chunks have already been processed in some way because, > > well, > > there was no way to store the entire message. Without the final > > chunk > > you have an incomplete and thus unauthenticated message because the > > sender authenticated the entire message and not certain parts of it. > > Chosen ciphertext attacks and truncation attacks are two different > attack classes, with different assumptions on the plaintext format and > the necessary attacker capabilities. > > Neal's proposal to mandate a small and fixed chunk size can solve > ciphertext malleability for future OpenPGP applications. Waving this > proposal off, just because it won't also solve truncation attacks, > does not make sense. I don't understand why you bring up malleability. As far as I understand Werner, he is concerned with the proposal still forcing clients to buffer the whole message if the implementation wants to release authenticated data only. Which is how AE is defined. So fixing any chunk size does not work. But I may stand corrected. Cheers, Tobi From nobody Sun Mar 17 12:34:06 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E584412D829 for ; Sun, 17 Mar 2019 12:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 4ERLQDGZ3VIq for ; Sun, 17 Mar 2019 12:34:02 -0700 (PDT) Received: from bitbox.cryptobit.ch (cryptobit.ch [188.40.138.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82A1512B001 for ; Sun, 17 Mar 2019 12:34:02 -0700 (PDT) Received: from unibox.fritz.box (p5B0F5932.dip0.t-ipconnect.de [91.15.89.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.cryptobit.ch (Postfix) with ESMTPSA id 44MqHr2bMPz13BZc; Sun, 17 Mar 2019 20:34:00 +0100 (CET) Message-ID: <1f06f1b747347f49286122d7f26b08b2c48324d1.camel@cryptobitch.de> From: Tobias Mueller To: "Neal H. Walfield" , Derek Atkins Cc: Werner Koch , openpgp@ietf.org, Vincent Breitmoser Date: Sun, 17 Mar 2019 20:33:59 +0100 In-Reply-To: <87pnqtwot9.wl-neal@walfield.org> References: <87d0n174w6.fsf@wheatstone.g10code.de> <87mumh33nc.wl-neal@walfield.org> <3GFS71V7BTJNZ.29C5TO8OY0O44@my.amazin.horse> <87r2bax5u2.wl-neal@walfield.org> <87pnqtwot9.wl-neal@walfield.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2019 19:34:04 -0000 Hi, On Thu, 2019-03-14 at 14:47 +0100, Neal H. Walfield wrote: > And, I also want to preserve the ability to stream data. but the proposal does not add to that ability but removes the ability to use one chunk, only. Cheers, Tobi From nobody Sun Mar 17 12:35:25 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0AF12E036 for ; Sun, 17 Mar 2019 12:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 v-TjL4xXoLWc for ; Sun, 17 Mar 2019 12:35:22 -0700 (PDT) Received: from bitbox.cryptobit.ch (cryptobit.ch [188.40.138.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1C4112B001 for ; Sun, 17 Mar 2019 12:35:21 -0700 (PDT) Received: from unibox.fritz.box (p5B0F5932.dip0.t-ipconnect.de [91.15.89.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.cryptobit.ch (Postfix) with ESMTPSA id 44MqKN160cz13BZg; Sun, 17 Mar 2019 20:35:20 +0100 (CET) Message-ID: From: Tobias Mueller To: Sebastian Schinzel , openpgp@ietf.org Date: Sun, 17 Mar 2019 20:35:19 +0100 In-Reply-To: <90a28b7c-1b02-abbb-eb8d-bec5263a9f89@fh-muenster.de> References: <87mumh33nc.wl-neal@walfield.org> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> <87h8co2t4v.wl-neal@walfield.org> <35C892F7-18A8-401E-828D-5CE180A3A731@icloud.com> <87r2brf0f1.wl-neal@walfield.org> <2a014c4a103ba7f52535546f7e77277ea2bdabdf.camel@cryptobitch.de> <90a28b7c-1b02-abbb-eb8d-bec5263a9f89@fh-muenster.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2019 19:35:23 -0000 Hi Sebastian, On Mon, 2019-03-04 at 09:49 +0100, Sebastian Schinzel wrote: > Your reasoning regarding proper AE is correct, but you are drawing the > wrong conclusions. You want small chunks to do proper AE! Can you mention what definition of AE you are referring to? I guess you meant to add that you will need to come up with a secure scheme to identify the last chunk and implement that properly. And that you then you will need to buffer all the plaintext until the final chunk has successfully checked out. Because otherwise you wouldn't get "proper" AE as in either releasing plaintext or an error. > The advantage of smaller > chunks is that the plaintext can be cached until the chunk's auth tag > is validated. That's to guarantee that no unauthenticated plaintext is > released. (Leaving truncation aside.) Two things: Firstly, you write "can be cached" rather than "must be cached". Unless you relax the security goals of the AEAD protected message. Secondly, you can release unauthenticated plaintext of an AEAD protected message of arbitrary size if you don't want to hold all the plaintext of a decrypted ciphertext. Regardless of the size of the message or chunk. Hence, there is no advantage of using a small chunk size if you want to have an AEAD protected message. As in, if you intend to have proper AE which only releases the full plaintext or an error. Unless you need the concept of partially authenticated plaintext, the only reason for using chunks is to detect failures early in the decryption process rather than at the end. Again, if don't you want your full message to enjoy the protections AE gives you, then you may be able to afford partially authenticated messages. I haven't seen anybody presenting a use-case for those. And even then it seems far fetched to impose that concept onto each and every OpenPGP user as the current proposal does. Cheers, Tobi From nobody Sun Mar 17 13:00:58 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 439D51311E2 for ; Sun, 17 Mar 2019 13:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 cLlDDwCKvsAe for ; Sun, 17 Mar 2019 13:00:54 -0700 (PDT) Received: from bitbox.cryptobit.ch (cryptobit.ch [188.40.138.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F9611311E1 for ; Sun, 17 Mar 2019 13:00:54 -0700 (PDT) Received: from unibox.fritz.box (p5B0F5932.dip0.t-ipconnect.de [91.15.89.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.cryptobit.ch (Postfix) with ESMTPSA id 44Mqtr007Vz13Bb0; Sun, 17 Mar 2019 21:00:51 +0100 (CET) Message-ID: <61e3fb9d194d0b47f21be8e176daa0b9b6c5d0a5.camel@cryptobitch.de> From: Tobias Mueller To: "Neal H. Walfield" , Derek Atkins Cc: Werner Koch , openpgp@ietf.org, Vincent Breitmoser Date: Sun, 17 Mar 2019 21:00:51 +0100 In-Reply-To: <87lg1gwelf.wl-neal@walfield.org> References: <87d0n174w6.fsf@wheatstone.g10code.de> <87mumh33nc.wl-neal@walfield.org> <3GFS71V7BTJNZ.29C5TO8OY0O44@my.amazin.horse> <87r2bax5u2.wl-neal@walfield.org> <87pnqtwot9.wl-neal@walfield.org> <0f7f492bf18145f96e70886ba19ba290.squirrel@mail2.ihtfp.org> <87lg1gwelf.wl-neal@walfield.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2019 20:00:56 -0000 Hi, On Fri, 2019-03-15 at 12:40 +0100, Neal H. Walfield wrote: > I'm currently convinced that streaming authenticated plaintext is only > possible if we use small chunk sizes. If we allow large chunk sizes > (e.g., 4 exabytes, which is what the current draft allows), then there > will be cases where an implementation can stream unauthenticated > plaintext, but not authenticated data, and, because it can, it will. > And this is even though pretty much everyone including the IETF (see > RFC 5116 [1]) agrees that AEAD must only emit authenticated plaintext. > > [1] https://tools.ietf.org/html/rfc5116#section-2.2 Maybe we're hitting a terminology issue here. For me, a plaintext is authenticated if the whole ciphertext could be successfully authenticated. Which seems to be very well in line with the definition you've linked to. Now, if you modify a (long) ciphertext that has been broken into chunks near the end and a decryption routine reveals the first parts of the decrypted ciphertext, would you agree that revealing those parts of the plaintext does not meet the definition that you've linked to? And do you further agree that you would need to find a way to prevent any plaintext to be revealed unless the full message has been authenticated correctly in order to match the definition that you've mentioned? Cheers, Tobi From nobody Sun Mar 17 13:01:38 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD4271311E1 for ; Sun, 17 Mar 2019 13:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 KfOC2IyEu40J for ; Sun, 17 Mar 2019 13:01:34 -0700 (PDT) Received: from bitbox.cryptobit.ch (cryptobit.ch [188.40.138.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 756A81311DF for ; Sun, 17 Mar 2019 13:01:34 -0700 (PDT) Received: from unibox.fritz.box (p5B0F5932.dip0.t-ipconnect.de [91.15.89.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.cryptobit.ch (Postfix) with ESMTPSA id 44Mqvc3d5qz13Bb4; Sun, 17 Mar 2019 21:01:32 +0100 (CET) Message-ID: <734216a3ee1c0e252ecf0ad297be2cfdcb049c2e.camel@cryptobitch.de> From: Tobias Mueller To: "Neal H. Walfield" Cc: Jon Callas , Bart Butler , "openpgp@ietf.org" , Vincent Breitmoser Date: Sun, 17 Mar 2019 21:01:32 +0100 In-Reply-To: <878sxqy5kw.wl-neal@walfield.org> References: <87mumh33nc.wl-neal@walfield.org> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> <87h8co2t4v.wl-neal@walfield.org> <35C892F7-18A8-401E-828D-5CE180A3A731@icloud.com> <87r2brf0f1.wl-neal@walfield.org> <2a014c4a103ba7f52535546f7e77277ea2bdabdf.camel@cryptobitch.de> <878sxqy5kw.wl-neal@walfield.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2019 20:01:37 -0000 Hi Neal, On Thu, 2019-03-07 at 18:09 +0100, Neal H. Walfield wrote: > On Sun, 03 Mar 2019 19:36:08 +0100, > Tobias Mueller wrote: > > By fixing a "chunk size" you take away the ability to benefit from > > AE > > for messages bigger than that size. > > Implementations could easily collect all chunks and only release the > > plaintext once all chunks check out successfully. But that could go > > wrong. And depending on implementations to get things right and > > clients > > to use those implementations correctly is exactly what enabled Efail > > to > > become an issue. I think it'd be much nicer if the protocol already > > ensures that my emails do indeed enjoy protection against > > modification > > rather than me having to rely too much on clients getting it right. > > You're afraid of bugs. So am I. Dynamically resizing buffers is > error prone. Even computing AEAD's chunk size is hard: point taken. Programming is hard. Programming C is even harder. Tooling could be improved. We ought to write a spec that achieves a security goal while making it less likely that people implement the spec wrongly. You've made a point but you haven't really taken a stance on the point that I raised. Which boils down to your proposal forcing everybody to use chunking which in turn can be implemented wrongly while providing no benefit in return. For the sake of the argument, let's assume a safe aead_decrypt oracle. I think that any CAESAR candidate provides such a function that is sufficiently well suited. I believe that the potential for releasing plaintext although the ciphertext has not been authenticated is higher if I need to call that oracle multiple times, invent a secure scheme for detecting truncation, and implement that scheme correctly. Your proposal removes the option for the message producer to decide whether it wants to have the recipient (which may very well be the same entity) rely on an implementation which gets all that right. Because with the status quo, one can opt for producing one chunk which is trivially protected against truncation and other attacks. Which is probably what I expect when I opted for protecting my message with AE. And as far as I understand the current spec, it would not be directly illegal for an implementation to release plaintext of a chunk early. So my only chance as a message producer to not rely on implementations to not release plaintext early is to use one chunk. (uff. so many negations. Sorry about that). Unless I understand your proposal wrong. But then my question is, how would I encode a message that is not susceptible to (at least) truncation attacks? Again, assuming the above mentioned oracle. I don't fully understand why you are mentioning dynamically resizing buffers. Strictly speaking, you need space for a single digit number of blocks (!) to decrypt an EAX or OCB message. And you are free to release unauthenticated plaintext as much as you want, much like your current proposal. If you want to process the message in 16kB pieces only, I don't see why you couldn't. Even with a 5 exabyte message (or chunk). If you don't want to reveal the plaintext, you could even mask the output and only offer to remove the mask after the last chunk has successfully checked out. I can understand that the concerns around relying on correct chunking can be dismissed, because several protocols exist that have successfully (for all we know so far) done such a thing, so implementations can copy and paste existing solutions. I think, though, that it has not been appreciated enough that chunking carries risks, because it relies on the implementation to not release plaintext early. And, as we all know, releasing unauthenticated plaintext has lead to EFail. If using proper AEAD is the response to EFail then your proposal to remove the option of not having to rely on clients not releasing early plaintext is not helping implementations to do the right thing, i.e. not release unauthenticated plaintext. > > #include > > int chunk_size(int c) { > return 2 << (c + 6); > } > > int > main(int argc, char *argv[]) { > printf("%d\n", chunk_size(32)); > } > > $ gcc -Wall a.c > $ ./a.out > 128 > > (Note that gcc doesn't even produce a warning!) > > But, that's not all. If there is the possibility of failing due to a > lack of buffer space, implementors won't bother. And they won't > bother for a very good reason: users want to get work done. If a > security policy prevents them from getting their work done, they will > disable it. Or, an implementation will ignore it. And, because it is > only a problem if there is an attack, users will be thankful for the > more "powerful" solution. Right. One way of addressing your concern is to simply not allow chunking. Then there wouldn't be a more "powerful" solution. As such I like your proposal, but I would amend it and state that the chunk size is the size of the packet minus the overhead. We're not discussing that, though. Instead, your proposal is about *removing* the option for creating one chunk and *forcing* everybody to use multiple chunks and thus bear the risks of an implementation to get the chunking wrong. Additionally, one could argue that because you force the concept of partially authenticated plaintext onto every consumer, implementations might see no problem with releasing that plaintext early. That, in turn, can be considered worse than not releasing it, because it prevents living up to the semantics of true AE which is to not release any plaintext if the ciphertext has been modified. > > The secure implementation must be easy for both developers and users. > And the secure implementation is a small, fixed sized buffer, even if > that means the client may have to worry about truncation. Fair enough. Although I don't understand why you say "may" rather than "must". In my view, typical applications for OpenPGP do not have application level protection against truncation. I'm thinking Email and Backups. Neither of these can reliably detect that the message has been truncated. And the application can't use the partial output either. Are partially authenticated plaintexts important to you? What's your use-case for those? Could you realise your use-case with producing multiple OpenPGP messages instead? Anyway, that tradeoff which you mention, has not been part of your proposal. With one chunk, the ciphertext is trivially protected against truncation. With multiple chunks, you need to come up with a secure scheme and implement that correctly. This is far from trivial. The change you've proposed does not indicate that the potential for getting this wrongly has been considered. And it does not alert consumers that they should use the OpenPGP message format only for an application that can deal with truncated messages. Note that I don't believe the currently described chunking mechanism is broken. But the risk of implementing that wrongly is non-zero. I wonder whether it makes sense to encourage not releasing any plaintext if the ciphertext has been modified more strongly. > > > Having said that, I understand the desire for fixing a chunk size to > > reduce complexity for implementers. My desire as a user is to have > > a > > strong and resilient protocol. > > Perhaps you're not a typical user :D. Interesting point. That may be true. But I guess it's reasonable to expect a protection of the encrypted message to be as close to AE as possible when I'm using an AE cipher. As such, I expect to either get (the full) plaintext or an error. What do you think does the typical user expect when using an AE cipher? Do you think that the typical user has use for partially authenticated plaintexts? And if so, why would they not produce separate messages rather than one? > > > Is there another way to do real AE? > > Chunked AE is still real AE: it still has ciphertext integrity; it is > just susceptible to truncation attacks. First of all, you'd still need to collect all plaintexts before releasing them to get "real AE". Simply because you must either return plaintext or an error. I am not aware of a definition of AE that includes partial plaintexts. I bet that we haven't yet exhausted all possible ways which could lead to an attack. For example, I wonder whether certain applications will suffer from a timing attack because the attacker can determine which chunk they were able to tamper with. Of course, fantasizing about yet unknown attacks quickly yields esoteric scenarios and we better spend our time on currently known problems. And again, we know that it's hard to not release plaintext although the ciphertext has been modified. By using one chunk I can choose to not rely on my recipient's implementation to get the chunking right, simply because there is no chunking involved. Your proposal takes that option away and forces me to rely on the spec and the implementation having gotten the chunking right. As I've already mentioned, chunking is relatively easy and there are other things that implementations can screw up more easily instead. So it's fair to dismiss that concern. But it still feels weird to not have a way to express a truly AE protected message. That makes me concerned that users would turn to S/MIME instead. To move forward, let me ask you: Do you agree that calling something "authenticated encryption" raises the expectation of getting either the full plaintext or an error rather than partial plaintexts and an error? Do you appreciate the need for a one chunk ciphertext (this question is intentionally generic, i.e. regardless of difficulties implementing that)? Do you think we should encourage implementations to not release plaintext unless the whole ciphertext has been authenticated? Do you have use-cases for partially authenticated plaintexts? Would separating the AEAD modes into non-chunked and chunked help you? > That's not to say that > truncation attacks are not a serious issue, but I'd rather have > truncation attacks than truncation attacks *and* ciphertext modication > attacks. Are you saying that leaving the option to do one-chunk AE, as it currently exists, enables both truncation and ciphertext modification attacks? I don't understand why it would. > P.S. Consider realloc. It is only marginally easier to write this > wrong code: > > p = realloc(p, 2 * size); > if (! p) { > // Oops, p has been leaked! > return ENOMEM; > } > > than this code: > > void *temp = realloc(p, 2 * size); > if (! temp) { > free(p); > return ENOMEM; > } > p = temp; > > but I see lots of instances of the former when reading code. I hope you've filed the relevant bugs ;-) Just in case someone is finding this in the archives: GCC has __attribute__((cleanup)) and GLib has some convenience macros around it. Cheers, Tobi From nobody Sun Mar 17 23:55:17 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3FD3124B16 for ; Sun, 17 Mar 2019 23:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org 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 sA7YD86zDQXy for ; Sun, 17 Mar 2019 23:55:12 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04E831310E5 for ; Sun, 17 Mar 2019 23:55:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=zqInZyMgBlX3bUGXhqKijIAKo8u8qr4HS/WoKNxYX1c=; b=Z3umBEMOE8S0ELdJ7WSTxeElrq VR2hsCifnaQQ2BqEVlGrFlc+FKf9wIzZMbbtnfPAy1ZeifRYiuaBe15l5aHrZTdIfIkwU9G+4twOJ YIFCl+W2M45I0tFglM+bR1LafPAZBvHqq3LgwWsff5mNY7AJ7gddzIlvJ+hovYfE8vUM=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1h5mAv-000705-CL for ; Mon, 18 Mar 2019 07:55:09 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1h5m6I-00045I-HN; Mon, 18 Mar 2019 07:50:22 +0100 From: Werner Koch To: "Neal H. Walfield" Cc: Derek Atkins , openpgp@ietf.org, Vincent Breitmoser References: <87d0n174w6.fsf@wheatstone.g10code.de> <87mumh33nc.wl-neal@walfield.org> <3GFS71V7BTJNZ.29C5TO8OY0O44@my.amazin.horse> <87r2bax5u2.wl-neal@walfield.org> <87pnqtwot9.wl-neal@walfield.org> <87y35hy2i0.fsf@wheatstone.g10code.de> <87k1h0we7w.wl-neal@walfield.org> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: "Neal H. Walfield" , Derek Atkins , openpgp@ietf.org, Vincent Breitmoser Date: Mon, 18 Mar 2019 07:50:22 +0100 In-Reply-To: <87k1h0we7w.wl-neal@walfield.org> (Neal H. Walfield's message of "Fri, 15 Mar 2019 12:48:19 +0100") Message-ID: <87va0g65ht.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=Belknap_SABC_Aid_JFK_Border_Patrol_LLNL_Virii_George_W._Bush_Facilit"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 06:55:16 -0000 --=Belknap_SABC_Aid_JFK_Border_Patrol_LLNL_Virii_George_W._Bush_Facilit Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 15 Mar 2019 12:48, neal@walfield.org said: >> > Are you arguing like Werner that catching transmission errors is >> > enough and that we shouldn't bother with ciphertext integrity? >>=20 >> I never said this. > > I was referring to this: > > On Fri, 01 Mar 2019 15:50:15 +0100, > Werner Koch wrote: > > Let me repeat it again: The chunking was introduced for just one > > purpose: To be able to detect rare transmission errors earlier than at > > the end of the message. Sorry, can you please explain how you can read out of this that I=20 said: "we shouldn't bother with ciphertext integrity". Shalom-Salam, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=Belknap_SABC_Aid_JFK_Border_Patrol_LLNL_Virii_George_W._Bush_Facilit Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCXI8/rgAKCRD/gK6dHew1 jcc7AP0WczeZ8YiCJWqyLFJnl5MdAqske+q/GxROEjEVLTWgiQD9FYilUoVb8wUv k0iHvoVDLlyEKMNrhMCqqD3gBBUKzwM= =OCro -----END PGP SIGNATURE----- --=Belknap_SABC_Aid_JFK_Border_Patrol_LLNL_Virii_George_W._Bush_Facilit-- From nobody Mon Mar 18 01:23:45 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C8F128B77 for ; Mon, 18 Mar 2019 01:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 POPjPyiB0fv0 for ; Mon, 18 Mar 2019 01:23:41 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 8F2E112796D for ; Mon, 18 Mar 2019 01:23:41 -0700 (PDT) Received: from p57b22663.dip0.t-ipconnect.de ([87.178.38.99] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1h5nYY-0002Lf-K3; Mon, 18 Mar 2019 08:23:38 +0000 Date: Mon, 18 Mar 2019 09:23:37 +0100 Message-ID: <87va0gioae.wl-neal@walfield.org> From: "Neal H. Walfield" To: "Neal H. Walfield" , Derek Atkins , openpgp@ietf.org, Vincent Breitmoser In-Reply-To: <87va0g65ht.fsf@wheatstone.g10code.de> References: <87d0n174w6.fsf@wheatstone.g10code.de> <87mumh33nc.wl-neal@walfield.org> <3GFS71V7BTJNZ.29C5TO8OY0O44@my.amazin.horse> <87r2bax5u2.wl-neal@walfield.org> <87pnqtwot9.wl-neal@walfield.org> <87y35hy2i0.fsf@wheatstone.g10code.de> <87k1h0we7w.wl-neal@walfield.org> <87va0g65ht.fsf@wheatstone.g10code.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 08:23:44 -0000 Hi Werner, On Mon, 18 Mar 2019 07:50:22 +0100, Werner Koch wrote: > On Fri, 15 Mar 2019 12:48, neal@walfield.org said: > >> > Are you arguing like Werner that catching transmission errors is > >> > enough and that we shouldn't bother with ciphertext integrity? > >> > >> I never said this. > > > > I was referring to this: > > > > On Fri, 01 Mar 2019 15:50:15 +0100, > > Werner Koch wrote: > > > Let me repeat it again: The chunking was introduced for just one > > > purpose: To be able to detect rare transmission errors earlier than at > > > the end of the message. > > Sorry, can you please explain how you can read out of this that I > said: "we shouldn't bother with ciphertext integrity". I'm extremely happy to hear that I've misunderstood your position, and that our goals are actually aligned. Can you please explain how to get ciphertext integrity when streaming? To be clear: for me, truncation is an orthogonal issue; my primary concern is how to ensure that no implementations ever release plaintext derived from modified ciphertext. If you think that the current proposal achieves this, I've presented a few critiques in <87mum6ekbd.wl-neal@walfield.org> (https://mailarchive.ietf.org/arch/msg/openpgp/WvaisWDd9WzoKXL1FyHDeZNtZ2U): 1. If messages can't be decrypted, because a chunk won't fit in memory, but unauthenticated streaming would otherwise "work," implementors will do the latter, because security must not get in the way of a user getting her job done. 2. If unauthenticated streaming is allowed or tacitly encouraged, it will be done first, because the set of messages that unauthenticated streaming can decrypt is a superset of those that authenticated decryption can handle, and it will perhaps be done exclusively because introducing a second code path that, modulo security concerns, is functionally equivalent to the code path for unauthenticated streaming is extra work, and extra complexity, which developers will try to avoid. 3. If implementations revert to unauthenticated streaming for large chunk sizes, an attacker can conduct an EFAIL-style attack by changing the chunk size. Thanks! :) Neal From nobody Mon Mar 18 01:51:54 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6BFC1310F1 for ; Mon, 18 Mar 2019 01:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 CUVrEFM8BnWy for ; Mon, 18 Mar 2019 01:51:51 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 5344F1295EC for ; Mon, 18 Mar 2019 01:51:51 -0700 (PDT) Received: from p57b22663.dip0.t-ipconnect.de ([87.178.38.99] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1h5nzo-0002d5-7a; Mon, 18 Mar 2019 08:51:48 +0000 Date: Mon, 18 Mar 2019 09:51:47 +0100 Message-ID: <87tvg0imzg.wl-neal@walfield.org> From: "Neal H. Walfield" To: Tobias Mueller Cc: Sebastian Schinzel , openpgp@ietf.org In-Reply-To: References: <87mumh33nc.wl-neal@walfield.org> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> <87h8co2t4v.wl-neal@walfield.org> <35C892F7-18A8-401E-828D-5CE180A3A731@icloud.com> <87r2brf0f1.wl-neal@walfield.org> <2a014c4a103ba7f52535546f7e77277ea2bdabdf.camel@cryptobitch.de> <90a28b7c-1b02-abbb-eb8d-bec5263a9f89@fh-muenster.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 08:51:53 -0000 On Sun, 17 Mar 2019 20:35:19 +0100, Tobias Mueller wrote: > > The advantage of smaller > > chunks is that the plaintext can be cached until the chunk's auth tag > > is validated. That's to guarantee that no unauthenticated plaintext is > > released. (Leaving truncation aside.) > > Two things: Firstly, you write "can be cached" rather than "must be > cached". I think Sebastian is using "can" to mean "it is possible", not "may". That is, The advantage of smaller chunks is that *it is possible* to cache the plaintext until the chunk's auth tag is validated *whereas it is not necessarily possible to cache the plaintext with larger chunks*. Neal From nobody Mon Mar 18 02:49:30 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14527128CE4 for ; Mon, 18 Mar 2019 02:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 WD6m5NxJ2vYU for ; Mon, 18 Mar 2019 02:49:27 -0700 (PDT) Received: from bitbox.cryptobit.ch (cryptobit.ch [188.40.138.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13571128B33 for ; Mon, 18 Mar 2019 02:49:26 -0700 (PDT) Received: from unibox.fritz.box (p5B0F5932.dip0.t-ipconnect.de [91.15.89.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.cryptobit.ch (Postfix) with ESMTPSA id 44NBGq14TTz13C3b; Mon, 18 Mar 2019 10:49:23 +0100 (CET) Message-ID: <13a5e06b512120ebf2d04b9a018f5eb6a0457d42.camel@cryptobitch.de> From: Tobias Mueller To: "Neal H. Walfield" , openpgp@ietf.org Date: Mon, 18 Mar 2019 10:49:22 +0100 In-Reply-To: <87mum6ekbd.wl-neal@walfield.org> References: <87mumh33nc.wl-neal@walfield.org> <871s3qd4yg.fsf@wheatstone.g10code.de> <87mum6ekbd.wl-neal@walfield.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 09:49:29 -0000 Hi, On Thu, 2019-03-07 at 17:11 +0100, Neal H. Walfield wrote: > > Let me repeat it again: The chunking was introduced for just one > > purpose: To be able to detect rare transmission errors earlier than > > at > > the end of the message. > > I agree that AEAD helps detect transmission errors earlier. But, AEAD > does so much more than that. In particular, it prevents attacks like > EFAIL. It seems to me that it's worth adapting to this new threat. I have the feeling that this is the spot where we are close to hitting the underlying misunderstanding. AFAICS, Werner is talking about chunking. You are talking about AEAD. I have the feeling that it's helpful for the discussion to carefully distinguish those. You seem to imply that any chunked scheme is proper AEAD. But that's not true. It's not difficult to make a scheme with chunks, and the spec probably has already done so, but it's not trivial. Cheers, Tobi From nobody Mon Mar 18 02:49:59 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633E613110A for ; Mon, 18 Mar 2019 02:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 unktYo6lSUKF for ; Mon, 18 Mar 2019 02:49:53 -0700 (PDT) Received: from bitbox.cryptobit.ch (cryptobit.ch [188.40.138.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08C8F13110D for ; Mon, 18 Mar 2019 02:49:53 -0700 (PDT) Received: from unibox.fritz.box (p5B0F5932.dip0.t-ipconnect.de [91.15.89.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.cryptobit.ch (Postfix) with ESMTPSA id 44NBHM3XTNz13C3d; Mon, 18 Mar 2019 10:49:51 +0100 (CET) Message-ID: From: Tobias Mueller To: "Neal H. Walfield" Cc: openpgp@ietf.org Date: Mon, 18 Mar 2019 10:49:51 +0100 In-Reply-To: <87tvg0imzg.wl-neal@walfield.org> References: <87mumh33nc.wl-neal@walfield.org> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> <87h8co2t4v.wl-neal@walfield.org> <35C892F7-18A8-401E-828D-5CE180A3A731@icloud.com> <87r2brf0f1.wl-neal@walfield.org> <2a014c4a103ba7f52535546f7e77277ea2bdabdf.camel@cryptobitch.de> <90a28b7c-1b02-abbb-eb8d-bec5263a9f89@fh-muenster.de> <87tvg0imzg.wl-neal@walfield.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 09:49:58 -0000 Hi Neal, On Mon, 2019-03-18 at 09:51 +0100, Neal H. Walfield wrote: > I think Sebastian is using "can" to mean "it is possible", not "may". > > That is, > > The advantage of smaller > chunks is that *it is possible* to cache the plaintext until the > chunk's auth tag > is validated *whereas it is not necessarily possible to cache the > plaintext with larger chunks*. I think I see what you mean. But assuming that partial plaintexts are of little to no value, because you have used an AEAD cipher after all, then you can achieve the very same thing even today, with a message of arbitrary size, because you can stream out partial plaintext. Now you seem to find some value in partially authenticated plaintexts. But I haven't understood why you find them so appealing that you want to force them onto each and every user. Cheers, Tobi From nobody Mon Mar 18 03:53:22 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69BDD131101 for ; Mon, 18 Mar 2019 03:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 i3t2NGyMBZ9b for ; Mon, 18 Mar 2019 03:53:19 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 DAEA3127963 for ; Mon, 18 Mar 2019 03:53:18 -0700 (PDT) Received: from p57b22663.dip0.t-ipconnect.de ([87.178.38.99] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1h5ptL-0003tG-Fr; Mon, 18 Mar 2019 10:53:15 +0000 Date: Mon, 18 Mar 2019 11:53:14 +0100 Message-ID: <87sgvkihd1.wl-neal@walfield.org> From: "Neal H. Walfield" To: Tobias Mueller Cc: Derek Atkins , Werner Koch , openpgp@ietf.org, Vincent Breitmoser In-Reply-To: <61e3fb9d194d0b47f21be8e176daa0b9b6c5d0a5.camel@cryptobitch.de> References: <87d0n174w6.fsf@wheatstone.g10code.de> <87mumh33nc.wl-neal@walfield.org> <3GFS71V7BTJNZ.29C5TO8OY0O44@my.amazin.horse> <87r2bax5u2.wl-neal@walfield.org> <87pnqtwot9.wl-neal@walfield.org> <0f7f492bf18145f96e70886ba19ba290.squirrel@mail2.ihtfp.org> <87lg1gwelf.wl-neal@walfield.org> <61e3fb9d194d0b47f21be8e176daa0b9b6c5d0a5.camel@cryptobitch.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 10:53:22 -0000 Hi Tobias, On Sun, 17 Mar 2019 21:00:51 +0100, Tobias Mueller wrote: > On Fri, 2019-03-15 at 12:40 +0100, Neal H. Walfield wrote: > > I'm currently convinced that streaming authenticated plaintext is only > > possible if we use small chunk sizes. If we allow large chunk sizes > > (e.g., 4 exabytes, which is what the current draft allows), then there > > will be cases where an implementation can stream unauthenticated > > plaintext, but not authenticated data, and, because it can, it will. > > And this is even though pretty much everyone including the IETF (see > > RFC 5116 [1]) agrees that AEAD must only emit authenticated plaintext. > > > > [1] https://tools.ietf.org/html/rfc5116#section-2.2 > Maybe we're hitting a terminology issue here. I think we do. > For me, a plaintext is authenticated if the whole ciphertext could be > successfully authenticated. Which seems to be very well in line with the > definition you've linked to. 4880bis defines a chunking mechanism based on AEAD: the message is split into multiple chunks. In 4880bis, AEAD operates on a per-chunk basis. The chunking algorithm provides mechanisms for ensuring chunks can't be reordered, detecting the end of the message, etc. Using AEAD to decrypt a chunk authenticates that chunk's ciphertext; for a given chunk, the decryption operation will either return the correct plaintext, or it will return an error. This is exactly what RFC 5116 requires. RFC 5116 doesn't discuss chunking; chunking is not AEAD. The chunking mechanism in 4880bis (assuming implementors follow RFC 5116 with respect to AEAD on chunks) ensures that plaintext is only released from authenticated ciphertext. It does not protect against truncation attacks. Since OpenPGP decided to support streaming in RFC 2440 (which introduced One Pass Signature packets), this is inline with OpenPGP's philosophy. I don't think removing support for streaming is useful. You seem to think that AEAD's guarantees must apply to the whole message. I disagree. I agree it is useful, but it is not possible when streaming. I think that even if we add a bit that says: "don't stream", implementations will ignore it. Moreover an attacker can just clear it, and then the receiver streams it anyways. > Now, if you modify a (long) ciphertext that has been broken into chunks > near the end and a decryption routine reveals the first parts of the > decrypted ciphertext, would you agree that revealing those parts of the > plaintext does not meet the definition that you've linked to? No. AEAD is applied to chunks. > And do you further agree that you would need to find a way to prevent > any plaintext to be revealed unless the full message has been > authenticated correctly in order to match the definition that you've > mentioned? No. AEAD is applied to chunks. When a chunk is decrypted, it either returns authenticated plaintext, or an error. Referring to <734216a3ee1c0e252ecf0ad297be2cfdcb049c2e.camel@cryptobitch.de> On Sun, 17 Mar 2019 21:01:32 +0100, Tobias Mueller wrote: > On Thu, 2019-03-07 at 18:09 +0100, Neal H. Walfield wrote: > > You're afraid of bugs. So am I. Dynamically resizing buffers is > > error prone. Even computing AEAD's chunk size is hard: > point taken. Programming is hard. Programming C is even harder. Tooling > could be improved. We ought to write a spec that achieves a security > goal while making it less likely that people implement the spec wrongly. I agree. Less flexibility in the spec is better, which is what I want. You rightly argue, I think, that AEAD without chunking is easier to implement. But, OpenPGP supports streaming, which is incompatible with AEAD without chunking. Consequently, streaming using AEAD without chunking means releasing unauthenticated (as I have defined it above) plaintext. Releasing unauthenticated plaintext is much worse than releasing only an authenticated prefix. Releasing unauthenticated plaintext allows for an EFAIL style attack; releasing an authenticated prefix does not. Releasing an authenticated prefix prevents ciphertext malleability. > You've made a point but you haven't really taken a stance on the point > that I raised. Which boils down to your proposal forcing everybody to > use chunking which in turn can be implemented wrongly while providing no > benefit in return. Only releasing plaintext from authenticated chunks prevents EFAIL-style attacks. That is not no benefit, that is not a little benefit, that is a huge benefit. > I believe that the potential for releasing plaintext although the > ciphertext has not been authenticated is higher if I need to call that > oracle multiple times, invent a secure scheme for detecting truncation, > and implement that scheme correctly. I agree that the added complexity that chunking imposes is not worth it *if* the only reason to introduce chunking is to detect transmission errors early. But, it is not. It prevents modifications to the ciphertext. > Your proposal removes the option for the message producer to decide > whether it wants to have the recipient (which may very well be the same > entity) rely on an implementation which gets all that right. Because > with the status quo, one can opt for producing one chunk which is > trivially protected against truncation and other attacks. You say that it is trivially protected, but this is not the case, because exactly in those cases implementors will just stream unauthenticated data. They should only be able to stream data from authenticated chunks. > Unless I understand your proposal wrong. But then my question is, how > would I encode a message that is not susceptible to (at least) > truncation attacks? Again, assuming the above mentioned oracle. OpenPGP allows streaming. The implementation doesn't provide a mechanism to prevent streaming. I'm not sure it would be a good idea to provide one, as I don't think there is a sensible way for the sender to decide when to set that bit. > I don't fully understand why you are mentioning dynamically resizing > buffers. Strictly speaking, you need space for a single digit number of > blocks (!) to decrypt an EAX or OCB message. The size of the message is not known apriori if partial body length encoding is used. Even an upper bound is not known if compression is used. From nobody Mon Mar 18 05:07:29 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8993A12782C for ; Mon, 18 Mar 2019 05:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 h14Z9snmr-oW for ; Mon, 18 Mar 2019 05:07:26 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 9E93F127963 for ; Mon, 18 Mar 2019 05:07:25 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id f65so12732885wma.2 for ; Mon, 18 Mar 2019 05:07:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=eqh+kz5BxhPjyC7NXbFLaX+X70GHjNbZh6K+sA6a/Lc=; b=aUTobpIbRXoX5ES6tfkNqXHgry7MJ2gQgKbmZXv/l2DClvhcdFedilOD5IM7OSKGA+ Z8NtknZe4Hh04UOHH4+94geeiDlSYB4MD/2q/ODwTu+2+65LLByh1tlEhCUwvIWCkSHW HqSaCHIiUHoKeVFeFzm2oNMWPQdAAMjcObwuujEC4ZuZ4p6OI3T/jLXkd8+1zFJG/9AE dTFFvP4ufqLkZYjxVpu65Ne9J0FxiBPUS5/WcCQAACyIN9VyRZabxk9j9JFccLH4QlFP 9b0e86MmfYjdOvmdS4vcJFtkPQe+A1Z5W1ZvgHtdjhGwd4H5Z1K96Wh8CiDf/sSVj0ro ll5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=eqh+kz5BxhPjyC7NXbFLaX+X70GHjNbZh6K+sA6a/Lc=; b=n61kugCJ3hXgZkRXS00JTD7l8R677Qm8ZpBYEpI2kbrhVhiG1Mk9YgwCK76anlsta1 BAwF3FBYWs/NcJ/173n3rK/kSoHLi3vpko8KGkTxFtFR64qM7XTb/Mrl7PYpSVSajeOh tv/GZZ7mP304mH8oXItJlsdDSb7CGuoI9TV9Hsgs52wlutdtVom9YWQUFhVY7JELmsSC o1WNAI9k2J95LdDY/ae7BcKI0vGzpNK+JtjtAqOWcy3SdAg9kJoksaxF+dSeElLBOApJ eeIGGBN4vq2ZakUUwvxxhGoP3BFTchWPHujuCDHNm1m/aAjBTIThxS+ryAeLywzd097f noig== X-Gm-Message-State: APjAAAWvWDcc5tj1/Ng6ak+3nev4bRHRQ8yPg69dp2NIBsgSG4PwgyEI Y++fjkwkXZB7qnjxJa13bHnjLz9/ X-Google-Smtp-Source: APXvYqwNzNL88llVvU4lTfL0frSEZYu5Bw2ZBY+SqkbCjKXwVe2h050wvbEW7bpkvpyDLaK8B3kYUg== X-Received: by 2002:a7b:c34d:: with SMTP id l13mr10518778wmj.37.1552910843960; Mon, 18 Mar 2019 05:07:23 -0700 (PDT) Received: from localhost (port-92-193-68-206.dynamic.qsc.de. [92.193.68.206]) by smtp.gmail.com with ESMTPSA id l3sm5583409wrr.25.2019.03.18.05.07.22 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 18 Mar 2019 05:07:23 -0700 (PDT) From: Justus Winter To: openpgp@ietf.org Date: Mon, 18 Mar 2019 13:07:21 +0100 Message-ID: <871s3475dy.fsf@europa.jade-hamburg.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 12:07:27 -0000 --=-=-= Content-Type: text/plain Hello, I propose to deprecate compression support in OpenPGP. The reasons for this are: - Compression makes it impossible to reason about the size of a decrypted message, requiring the use of a streaming interface even for seemingly small messages, e.g. emails. Experience has shown that downstream users struggle with the correct use of streaming interfaces. - Compression allows the construction of quines. - Compression interacts badly with encryption, see e.g. CRIME, BREACH, and hiding of EFAIL-style CFB gadgets [0]. - The downstream application is in a better position to decide whether and how to compress data that is then encrypted using OpenPGP. - Compression make the standard more complex, and enlarges the trusted computing base of implementations. I realize that we cannot suddenly drop decompression support, but I would suggest to stop emitting compressed data packets. If this proposal gathers traction, I would be happy to suggest a change to the standard. Cheers, Justus 0: Section 5.3 of https://efail.de/efail-attack-paper.pdf --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEJWpOVeSnLZetJGjniNx+MzhfeR0FAlyPifkACgkQiNx+Mzhf eR02uwgApD3H9Z/5B1DQZ4wlsMr/KecSPevH+WTTlLE5t4ifXHXYBY5EZ3+fOK97 gNpXRvkKJJXp8GxkKXA3+I7d3J+eJRe7kijiJ6eX5YghDW5l0CouHxai2BVURxMp b9eCHIh6nJIfvB7gds50pEPwW09KOTGFEYA3JKrT8xTA+him4CtA8cKofW2THWrB 2iSXU13l5+EviVSDISDjREN8DH9pZmdVF6EYoEcUnPo2tkHrfjsrhL3k9MviYWy6 Szy1TGASAYu28kFsBfFNNJonHRvsLCCKmKQWdWthwl6+q/BN6gO0gsFTE7eB8jfk 7QIEdXXnPNoELUJbn42HIuKKgZn2dg== =jk5K -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 18 05:23:17 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7A212797D for ; Mon, 18 Mar 2019 05:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=my.amazin.horse 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 IikmRdc_492g for ; Mon, 18 Mar 2019 05:23:13 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F013B127963 for ; Mon, 18 Mar 2019 05:23:12 -0700 (PDT) Received: from localhost (dhcp229-087.wlan.rz.tu-bs.de [134.169.229.87]) by mail.mugenguild.com (Postfix) with ESMTPSA id 8CE425FAFF; Mon, 18 Mar 2019 13:23:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=my.amazin.horse; s=mail; t=1552911790; bh=vixvCDX0G7o1INJHlSxig/M9rSCs36FHKbm36euuido=; h=Date:From:To:Subject:Autocrypt:From; b=NxHnu/APtw/IXmk4LF6zSeb4g3+zQNoBQYaKmX36PrxM5DQhqwYQ8xxsaHYFaFEnV SeG2YFiqAGsq1X2ChQJYyzXXpQtaVX0RSlSMC3Xs3rU2FqM30ANstzI6sFiqdb6SC2 k2xpppqWh2b9UfP+K2HLl3sLjpnKeOjNmzl7gVnQ= Message-Id: <2HK22F68FITOF.35CB8RFLBNB8W@my.amazin.horse> In-Reply-To: References: <87mumh33nc.wl-neal@walfield.org> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> <87h8co2t4v.wl-neal@walfield.org> <35C892F7-18A8-401E-828D-5CE180A3A731@icloud.com> <87r2brf0f1.wl-neal@walfield.org> <2a014c4a103ba7f52535546f7e77277ea2bdabdf.camel@cryptobitch.de> <90a28b7c-1b02-abbb-eb8d-bec5263a9f89@fh-muenster.de> Date: Mon, 18 Mar 2019 13:23:07 +0100 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Vincent Breitmoser To: Tobias Mueller Cc: Sebastian Schinzel , openpgp@ietf.org Autocrypt: addr=look@my.amazin.horse; keydata=mQINBFAB3UABEADCyB/vbIBA3m1Bwc yjTieEMLySwYgt54EQ2hglOocdtIhqC+b05t6sLSkwx2ukxrU2cegnCBkdyF/FZ/+Et638CUEBbf 4bjplwpt2IPLazQgjkwjMuhz0OcYDpMhwimTvh3mIl+0wzpOts6mEmMw0QZdl3RXvIW+NSynOn7q mz/fAv4Htt6lv2Ka0s6R2voyi+5U7CcIqizPad5qZVn2uxmovcFreTzFt6nk37ZbbTfvA3e5F0bR RQeH3viT5XxpJF4Y76v/Ua+5N3Kd18K0sX85rD1G7cmxR2CZ5gW1X24sDqdYZdDbf10N39UIwjJH PTeuVMQqry792Ap0Etyj135YFCE0loDnZYKvy2Y1i0RuEdTUIonIHrLhe2J0bXQGbQImHIyMgB9/ lva8D+yvy2gyf2vjRhmJEEco7w9FdzP7p3PhKrUiTjRsjHw8iV8LOCFx9njZOq9mism9ZZ16tZpx 9mXOf11HcH1RtVuyyQRS/4ytQPzwshXdSDDW6Btkmo9AbZQKC54/hSyzpp3Br2T2xDH7ecnonDB/ jv8rWuKXSTbX3xWAIrNBNDcTYaNe4jkms4HF7jJE19eRlqsXMMx6Fxvrh4TtKICwJYJ3AUmXrK3X Ti/mjqYfJ1fpBn54rWs8nhSR1fuZPD+aMlcP8BDUPlNKPKtj0DGSh3/VlnnwARAQABtClWaW5jZW 50IEJyZWl0bW9zZXIgPGxvb2tAbXkuYW1hemluLmhvcnNlPokCOAQTAQIAIgUCVTNZmgIbAwYLCQ gHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQe9GDIN6t+hHcVg//aeiijNqsQ3pjbFQn3VvND7hNfJ vrVcLZ+U4kOzXPF818aVdOnDyNXyE17vBDDcvaZ730sCsZIRZJ3KhUJ+nPvdttKjUIGLARmx+pA3 Jl3IIv2uLtOb3I0TMuyfIGJVGF+q10/CeDMKVjKlmyOVrR0opkel+KEoN7VLq3Hf3zPKENO1HBgp LHeP31tlb9cgs+u4o2wLrVe9myHbuFBW7EjWbSvdz2zliwbsFeFVLMNcWrKAU0GkkiH69SgnwmXU RkhGma4L27GLtkHHufsxfbcPqPtmtCttsGZU4EmrghGUqVyDOxnn8ZqybzLrRfpin+OCIX+aHJz5 r2L8qtrP0LorNMX3Gopd26vfhNvq/wq8xk++bW1R5FmkaUhx9h+DhO2ybcg7p/E8JHc8zrWv+bb3 0o9lkrOaU8GxXrgtb1cjtbb+MxFvjm0Elw7MSZDG7sF/APFU6cwuIA9Nai/OGAUCSt/W2ecS8Zox cWWbGSEiDvjtEctkpmHjfVuGoL34966Olm41VdH+NjgoSYUJKx4Mty8DRcZxdyoXll84LvDkEEYK ZqOIACsJf8CDFvUkmhXc+moCj15Yxtj3/RslRVEiOUyrpDwB72zWcZG8YnzoyGxhcRIc/gFejO/y SI8bzCpYngeuTb5NjFG+ChGiInHbQcFeHBlaHtKi2o/B5axIO5Ag0EVDvOgQEQALJby/ztliToGE u1lslvWQUQ6teKZVUQ7hy9bM4N83G0AGLatUBHtY6PkJBe4XkIw3sK7LoFCV2W4GSt4zWp9l+kG3 /J8Ow7EFjN0F7DrCg0M0lMg9dQz9jYSoBR8skaH3BRzCq9AKIVKV94poL/G65289L7zKDHoZnnyF qbBtedYZir0SZx+kiouZ1qnmxRPaYmH2fkuiuvYEAyzLDLYM8F5gQhdZM4YVtuvSICYPet0z4CDi JX/vZmDi3AzzoEVaKeAM/0H9f9Ni547J2+8dZSllgTrA+fq0aMJVScAObIxTAQtEq0DoNBzPpVrm W10b4bmgePrAvNkifqSr5StymSBgwvoeW6GrJiyN4XhoLOadZzwgjqioR1nXw5tXtrr5sYdkZ06b 1WWHkxtu1hFTdLC7RYNxY07ytLNM+C2lplCwCwlWB7RwI9BL1Dhre4kv8uaaX2Gksaq9mDf9MSDW qQ0TJ/RAiwMGmFrzBEYI1J2Oyeshi/dqW4/OiZAukOIlxOnt6u8zU2KL6Qjxqqna0oTbS4Zv3fRd YkuUCL6CDEJdkuRAiW+Gw+lKcMjXqApEqixhaDkoB/kwtu+2gIFTzAxMfwFN1YtNc0kJZWnFkGIW MrrwTcOwAFzlFz7wn/EyMFtg+ERcqMX0+olXDwM8MODI2+BzulPuEDEteCw09hABEBAAGJAh8EGA ECAAkFAlQ7zoECGwwACgkQe9GDIN6t+hFjuQ//UQyg49f8TytUYQaBb8R0UfI+KhQFs1Nsz2z8a3 0CD1MeiHHYWdAcomVvTkg4g5LbnYHVDrj/XagY3FN/AIE97usFbsTG+rsWAOLi7N2dN2ehWZ634k MvrgyC9uTiOdkw31+B8K5MpyySgD8e6SAzRfiu06/bcQOUyJifw8Hudpj9by4uyGhSH+kHu4afrp OduUighbsGFtcuRwwQ/w/oSk68XvPUgiOQWMZh/pVoXdFyFvrt/hgArCi8dfy5UPK58nl7jPnu/I uQXrJ50nNAFIIxPVeo2/B83KAnEZPU+qWZsdba0V+FIIQQVizLtQFMuJJk4/UTAOfJ2tBpQ9PADX 6/scqDE7unXNWdxcHTjK7KmWjXC8CyhGOx8V/rb7Ial4mZo4cTED6SNlO7dV1XYwnSctL2HCYNM3 RUe4eJ7JWuu7/Nbf6yip2eq7BQKZ9hAH/se/OSZNYsEkZ4pxUc8W5U3uAZImUwC6L74SM0jBZIuD mQhOYX6sZZ6urIn/MYlj4/hqSBFS4vTK7nXRLmtr7+5T5U5srVseUiYc+l9pu9/XD8zGIu+M2xEd 41NwP44GDQTQm0bFljRv5fSblwmi56YHPFQUIh2RZNX3kOJgeyQ3enw5uY+7ocKRVP38hpnffliL lJcO6TtHWnElS3pACbTQM0RHJox3zqU3q6K3c= Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 12:23:15 -0000 Hi, a lot that Tobias is bringing up here resonates with me, I feel like we should be thinking more about the fully vs partially authenticated use cases, not just chunking on its own. (As an aside, I'm not convinced the early integrity check should have much bearing on this discussion. Transmission errors are (and should be) handled on other layers in mostly all cases, and noticing errors earlier than at the end of data that was going to be buffered anyways is not that big of a gain. In cases where this is a concern (like uh, tape drives?), a tool should be used that is actually meant for the job, e.g. par2) Ideally, a receiver won't ever output unauthenticated plaintext, hence ideally all of the chunking discussions would be moot. What chunking brings to the table is to give the *sender* of a message the option to *allow* the *receiver* to emit partially authenticated plaintext, trading a truncation vulnerability for the ability to process data on a smaller buffer size than the entire plaintext. This is useful for $large amounts of data, or streamed workflows with unknown data sizes. While following the discussion I've gone back and forth a couple of times between favoring the case for fully authenticated plaintext, or for supporting streamed workflows with fixed-size chunks (while sacrificing truncation). Both seem equally valid to me. However, I can't see a good use case for variable size chunking: it adds complexity to spec and implementations in particular on the receiving side, and pushes the onus on reasoning about chunk sizes to the implementations, which is basically impossible in the face of interoperability concerns. I'd like to bring up a new proposal then: Support either no chunking, or fixed-size chunking. The advantage would be that the sender's position on authentication is made more explicit: If they don't do chunking, they expect the receiver to fully buffer and authenticate before processing, which could currently only be achieved implicitly via a large chunk size. If they use the fixed-size chunking, they explicitly offer the option to emit partially authenticated plaintext. - V From nobody Mon Mar 18 05:25:28 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D05712797D for ; Mon, 18 Mar 2019 05:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=my.amazin.horse 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 a1vi8v0JWVif for ; Mon, 18 Mar 2019 05:25:26 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF7DD127963 for ; Mon, 18 Mar 2019 05:25:25 -0700 (PDT) Received: from localhost (dhcp229-087.wlan.rz.tu-bs.de [134.169.229.87]) by mail.mugenguild.com (Postfix) with ESMTPSA id 51E2D5FC27; Mon, 18 Mar 2019 13:25:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=my.amazin.horse; s=mail; t=1552911924; bh=Hwv+2CmauctJaT70jb3PdjQ+ZphtXAaMriRlN2FHH6E=; h=Date:From:To:Subject:Autocrypt:From; b=HEbqgoPVJYziTRZNw9Y61n3Y1l8yRPrTMM7yEVvr5xKWDRde/XN4hB2N4U2u/JY6N Oy5YGyWYuCc+3dNY3Y17/ir9Ze8n5Wj6S8SfRnu/PU1hDdccoR1ylZM8Xupbe9FTz1 xP6q0/cArDxed+OOrpSqwJhK9MnmFCLkod7CdMzU= Message-Id: <2SC4JI7Z1P6JM.3QBD2AGJF3BHF@my.amazin.horse> In-Reply-To: <871s3475dy.fsf@europa.jade-hamburg.de> References: <871s3475dy.fsf@europa.jade-hamburg.de> Date: Mon, 18 Mar 2019 13:25:23 +0100 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Vincent Breitmoser To: Justus Winter Cc: openpgp@ietf.org Autocrypt: addr=look@my.amazin.horse; keydata=mQINBFAB3UABEADCyB/vbIBA3m1Bwc yjTieEMLySwYgt54EQ2hglOocdtIhqC+b05t6sLSkwx2ukxrU2cegnCBkdyF/FZ/+Et638CUEBbf 4bjplwpt2IPLazQgjkwjMuhz0OcYDpMhwimTvh3mIl+0wzpOts6mEmMw0QZdl3RXvIW+NSynOn7q mz/fAv4Htt6lv2Ka0s6R2voyi+5U7CcIqizPad5qZVn2uxmovcFreTzFt6nk37ZbbTfvA3e5F0bR RQeH3viT5XxpJF4Y76v/Ua+5N3Kd18K0sX85rD1G7cmxR2CZ5gW1X24sDqdYZdDbf10N39UIwjJH PTeuVMQqry792Ap0Etyj135YFCE0loDnZYKvy2Y1i0RuEdTUIonIHrLhe2J0bXQGbQImHIyMgB9/ lva8D+yvy2gyf2vjRhmJEEco7w9FdzP7p3PhKrUiTjRsjHw8iV8LOCFx9njZOq9mism9ZZ16tZpx 9mXOf11HcH1RtVuyyQRS/4ytQPzwshXdSDDW6Btkmo9AbZQKC54/hSyzpp3Br2T2xDH7ecnonDB/ jv8rWuKXSTbX3xWAIrNBNDcTYaNe4jkms4HF7jJE19eRlqsXMMx6Fxvrh4TtKICwJYJ3AUmXrK3X Ti/mjqYfJ1fpBn54rWs8nhSR1fuZPD+aMlcP8BDUPlNKPKtj0DGSh3/VlnnwARAQABtClWaW5jZW 50IEJyZWl0bW9zZXIgPGxvb2tAbXkuYW1hemluLmhvcnNlPokCOAQTAQIAIgUCVTNZmgIbAwYLCQ gHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQe9GDIN6t+hHcVg//aeiijNqsQ3pjbFQn3VvND7hNfJ vrVcLZ+U4kOzXPF818aVdOnDyNXyE17vBDDcvaZ730sCsZIRZJ3KhUJ+nPvdttKjUIGLARmx+pA3 Jl3IIv2uLtOb3I0TMuyfIGJVGF+q10/CeDMKVjKlmyOVrR0opkel+KEoN7VLq3Hf3zPKENO1HBgp LHeP31tlb9cgs+u4o2wLrVe9myHbuFBW7EjWbSvdz2zliwbsFeFVLMNcWrKAU0GkkiH69SgnwmXU RkhGma4L27GLtkHHufsxfbcPqPtmtCttsGZU4EmrghGUqVyDOxnn8ZqybzLrRfpin+OCIX+aHJz5 r2L8qtrP0LorNMX3Gopd26vfhNvq/wq8xk++bW1R5FmkaUhx9h+DhO2ybcg7p/E8JHc8zrWv+bb3 0o9lkrOaU8GxXrgtb1cjtbb+MxFvjm0Elw7MSZDG7sF/APFU6cwuIA9Nai/OGAUCSt/W2ecS8Zox cWWbGSEiDvjtEctkpmHjfVuGoL34966Olm41VdH+NjgoSYUJKx4Mty8DRcZxdyoXll84LvDkEEYK ZqOIACsJf8CDFvUkmhXc+moCj15Yxtj3/RslRVEiOUyrpDwB72zWcZG8YnzoyGxhcRIc/gFejO/y SI8bzCpYngeuTb5NjFG+ChGiInHbQcFeHBlaHtKi2o/B5axIO5Ag0EVDvOgQEQALJby/ztliToGE u1lslvWQUQ6teKZVUQ7hy9bM4N83G0AGLatUBHtY6PkJBe4XkIw3sK7LoFCV2W4GSt4zWp9l+kG3 /J8Ow7EFjN0F7DrCg0M0lMg9dQz9jYSoBR8skaH3BRzCq9AKIVKV94poL/G65289L7zKDHoZnnyF qbBtedYZir0SZx+kiouZ1qnmxRPaYmH2fkuiuvYEAyzLDLYM8F5gQhdZM4YVtuvSICYPet0z4CDi JX/vZmDi3AzzoEVaKeAM/0H9f9Ni547J2+8dZSllgTrA+fq0aMJVScAObIxTAQtEq0DoNBzPpVrm W10b4bmgePrAvNkifqSr5StymSBgwvoeW6GrJiyN4XhoLOadZzwgjqioR1nXw5tXtrr5sYdkZ06b 1WWHkxtu1hFTdLC7RYNxY07ytLNM+C2lplCwCwlWB7RwI9BL1Dhre4kv8uaaX2Gksaq9mDf9MSDW qQ0TJ/RAiwMGmFrzBEYI1J2Oyeshi/dqW4/OiZAukOIlxOnt6u8zU2KL6Qjxqqna0oTbS4Zv3fRd YkuUCL6CDEJdkuRAiW+Gw+lKcMjXqApEqixhaDkoB/kwtu+2gIFTzAxMfwFN1YtNc0kJZWnFkGIW MrrwTcOwAFzlFz7wn/EyMFtg+ERcqMX0+olXDwM8MODI2+BzulPuEDEteCw09hABEBAAGJAh8EGA ECAAkFAlQ7zoECGwwACgkQe9GDIN6t+hFjuQ//UQyg49f8TytUYQaBb8R0UfI+KhQFs1Nsz2z8a3 0CD1MeiHHYWdAcomVvTkg4g5LbnYHVDrj/XagY3FN/AIE97usFbsTG+rsWAOLi7N2dN2ehWZ634k MvrgyC9uTiOdkw31+B8K5MpyySgD8e6SAzRfiu06/bcQOUyJifw8Hudpj9by4uyGhSH+kHu4afrp OduUighbsGFtcuRwwQ/w/oSk68XvPUgiOQWMZh/pVoXdFyFvrt/hgArCi8dfy5UPK58nl7jPnu/I uQXrJ50nNAFIIxPVeo2/B83KAnEZPU+qWZsdba0V+FIIQQVizLtQFMuJJk4/UTAOfJ2tBpQ9PADX 6/scqDE7unXNWdxcHTjK7KmWjXC8CyhGOx8V/rb7Ial4mZo4cTED6SNlO7dV1XYwnSctL2HCYNM3 RUe4eJ7JWuu7/Nbf6yip2eq7BQKZ9hAH/se/OSZNYsEkZ4pxUc8W5U3uAZImUwC6L74SM0jBZIuD mQhOYX6sZZ6urIn/MYlj4/hqSBFS4vTK7nXRLmtr7+5T5U5srVseUiYc+l9pu9/XD8zGIu+M2xEd 41NwP44GDQTQm0bFljRv5fSblwmi56YHPFQUIh2RZNX3kOJgeyQ3enw5uY+7ocKRVP38hpnffliL lJcO6TtHWnElS3pACbTQM0RHJox3zqU3q6K3c= Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 12:25:27 -0000 I support this motion. - V Justus Winter wrote: > Hello, > > I propose to deprecate compression support in OpenPGP. The reasons > for this are: > > - Compression makes it impossible to reason about the size of a > decrypted message, requiring the use of a streaming interface even > for seemingly small messages, e.g. emails. Experience has shown > that downstream users struggle with the correct use of streaming > interfaces. > > - Compression allows the construction of quines. > > - Compression interacts badly with encryption, see e.g. CRIME, > BREACH, and hiding of EFAIL-style CFB gadgets [0]. > > - The downstream application is in a better position to decide whether > and how to compress data that is then encrypted using OpenPGP. > > - Compression make the standard more complex, and enlarges the > trusted computing base of implementations. > > I realize that we cannot suddenly drop decompression support, but I > would suggest to stop emitting compressed data packets. If this > proposal gathers traction, I would be happy to suggest a change to the > standard. > > Cheers, > Justus > > 0: Section 5.3 of https://efail.de/efail-attack-paper.pdf > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp From nobody Mon Mar 18 05:29:23 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA6212797D for ; Mon, 18 Mar 2019 05:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 fT0syNfat5l7 for ; Mon, 18 Mar 2019 05:29:18 -0700 (PDT) Received: from nimbus.fccf.net (nimbus.fccf.net [185.117.82.79]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26929127963 for ; Mon, 18 Mar 2019 05:29:18 -0700 (PDT) Received: from straylight.m.ringlet.net (gw1.storpool.com [46.233.30.128]) by nimbus.fccf.net (Postfix) with ESMTPSA id A3D8B414 for ; Mon, 18 Mar 2019 14:29:14 +0200 (EET) Received: from roam (uid 1000) (envelope-from roam@ringlet.net) id 620003 by straylight.m.ringlet.net (DragonFly Mail Agent v0.11); Mon, 18 Mar 2019 14:29:14 +0200 Date: Mon, 18 Mar 2019 14:29:14 +0200 From: Peter Pentchev To: Vincent Breitmoser Cc: Tobias Mueller , openpgp@ietf.org, Sebastian Schinzel Message-ID: <20190318122914.GH18475@straylight.m.ringlet.net> References: <87mumh33nc.wl-neal@walfield.org> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> <87h8co2t4v.wl-neal@walfield.org> <35C892F7-18A8-401E-828D-5CE180A3A731@icloud.com> <87r2brf0f1.wl-neal@walfield.org> <2a014c4a103ba7f52535546f7e77277ea2bdabdf.camel@cryptobitch.de> <90a28b7c-1b02-abbb-eb8d-bec5263a9f89@fh-muenster.de> <2HK22F68FITOF.35CB8RFLBNB8W@my.amazin.horse> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Fnm8lRGFTVS/3GuM" Content-Disposition: inline In-Reply-To: <2HK22F68FITOF.35CB8RFLBNB8W@my.amazin.horse> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 12:29:21 -0000 --Fnm8lRGFTVS/3GuM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 18, 2019 at 01:23:07PM +0100, Vincent Breitmoser wrote: >=20 > Hi, >=20 > a lot that Tobias is bringing up here resonates with me, I feel like we s= hould > be thinking more about the fully vs partially authenticated use cases, no= t just > chunking on its own. >=20 > (As an aside, I'm not convinced the early integrity check should have much > bearing on this discussion. Transmission errors are (and should be) hand= led on > other layers in mostly all cases, and noticing errors earlier than at the= end of > data that was going to be buffered anyways is not that big of a gain. In = cases > where this is a concern (like uh, tape drives?), a tool should be used th= at is > actually meant for the job, e.g. par2) >=20 > Ideally, a receiver won't ever output unauthenticated plaintext, hence id= eally > all of the chunking discussions would be moot. What chunking brings to th= e table > is to give the *sender* of a message the option to *allow* the *receiver*= to > emit partially authenticated plaintext, trading a truncation vulnerabilit= y for > the ability to process data on a smaller buffer size than the entire plai= ntext. > This is useful for $large amounts of data, or streamed workflows with unk= nown > data sizes. >=20 > While following the discussion I've gone back and forth a couple of times > between favoring the case for fully authenticated plaintext, or for suppo= rting > streamed workflows with fixed-size chunks (while sacrificing truncation).= Both > seem equally valid to me. However, I can't see a good use case for variab= le size > chunking: it adds complexity to spec and implementations in particular on= the > receiving side, and pushes the onus on reasoning about chunk sizes to the > implementations, which is basically impossible in the face of interoperab= ility > concerns. >=20 > I'd like to bring up a new proposal then: Support either no chunking, or > fixed-size chunking. The advantage would be that the sender's position on > authentication is made more explicit: If they don't do chunking, they exp= ect the > receiver to fully buffer and authenticate before processing, which could > currently only be achieved implicitly via a large chunk size. If they use= the > fixed-size chunking, they explicitly offer the option to emit partially > authenticated plaintext. Not rejecting your idea outright, just curious how it would work with e.g. instant messengers where there is streaming of irregularly-sized packets coming at irregular intervals (and the users would expect that Things Just Work(tm) for both two-character messages and five-megabyte files sent over the wire). G'luck, Peter --=20 Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} pp@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 --Fnm8lRGFTVS/3GuM Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEELuenpRf8EkzxFcNUZR7vsCUn3xMFAlyPjxUACgkQZR7vsCUn 3xM7AxAA0bm2cnFJReZrqfZAQKq2iw8kmU0ZuwKMVnvIu/IP0pkGar72SSVKr0XP PwiadKu1gkIfRrzaS7exT5DrP99bAUC3RYwTJdeflFIeAA1A057T4qQldi0oEcou OoCuCoRaOyiRuA+qWdSvlwYAGymukDDq9fHBCNWfG3e+FWUQws3HRwGfaxst5Cnt 2ThH+SzbcZ5puz+65BEkCi+GhORZQ7mKnPm7BSY4Bk7MQQFWZmTuHGUYAACTMVhK 8qHoNPEk7duuITpBuRsf77pRHEpr8LVkujkyEfWKzxL6X2APCsnQ9y3GkncHv5Yg WCpWL/V5HvsX05Hlozahr2mgiJssXakHEUrXnhYaAGfiRVFDODl+OPLX//eDm5Fj VcB9v5STzaiERAqA6lY9kHmXD12uBJYb/lR7koy+zIzNsIpCXk0iKdlzeKl+9PxF k0vr/5CgjbpXavg+ZmWLQpeoyixRn1g4Frx+oIXNiHPYcn3Q6dMivbZLJCfGiDDw V3hWSBWfAbgLb8tf/JJokfT3DHtIlvGKxi1F93+mBeZu1QS9B9TP0HGHjfir+HD5 42N8Qfs+AuA5VsInX4vGqTOk26Cygdp2gPipzjV2U5E38pO/KeFfGTCeyhZFcsyG EdwlLA158O4/biQZWee2HU0J/cgUSBxjOHiWI5vGRtLIee7WkmY= =9wqO -----END PGP SIGNATURE----- --Fnm8lRGFTVS/3GuM-- From nobody Mon Mar 18 05:39:34 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53249127916 for ; Mon, 18 Mar 2019 05:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=my.amazin.horse 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 8K32lSuXu2Ar for ; Mon, 18 Mar 2019 05:39:31 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2ED0126C01 for ; Mon, 18 Mar 2019 05:39:31 -0700 (PDT) Received: from localhost (dhcp229-087.wlan.rz.tu-bs.de [134.169.229.87]) by mail.mugenguild.com (Postfix) with ESMTPSA id B4E605FAFF; Mon, 18 Mar 2019 13:39:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=my.amazin.horse; s=mail; t=1552912769; bh=ztbyWnf3bGKLzWSfIj4V/uEnx0T/ZDC9IMoBH2ZCTXI=; h=Date:From:To:Subject:Autocrypt:From; b=eLqgsxKhD+c72jpP/LFSuuhylX+VkYdjY8WeqkqtTGTiwLHYsT6z7v50406j7Dyjj czh5Y8/P5PsgkFm7VXIuSKVhtCBPXeHCrlOIxCJc2aV2upM9sf9IqDo3UgcX84wsSq 5q0rGOPkGEG2BjN4GNmqw/A0tN3EsPTlM+vwZqeY= Message-Id: <2RLJEWAU9F6EV.2D7URZREU42QE@my.amazin.horse> In-Reply-To: <20190318122914.GH18475@straylight.m.ringlet.net> References: <20190318122914.GH18475@straylight.m.ringlet.net> <87mumh33nc.wl-neal@walfield.org> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> <87h8co2t4v.wl-neal@walfield.org> <35C892F7-18A8-401E-828D-5CE180A3A731@icloud.com> <87r2brf0f1.wl-neal@walfield.org> <2a014c4a103ba7f52535546f7e77277ea2bdabdf.camel@cryptobitch.de> <90a28b7c-1b02-abbb-eb8d-bec5263a9f89@fh-muenster.de> <2HK22F68FITOF.35CB8RFLBNB8W@my.amazin.horse> Date: Mon, 18 Mar 2019 13:39:27 +0100 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Vincent Breitmoser To: Peter Pentchev Cc: Tobias Mueller , openpgp@ietf.org, Sebastian Schinzel Autocrypt: addr=look@my.amazin.horse; keydata=mQINBFAB3UABEADCyB/vbIBA3m1Bwc yjTieEMLySwYgt54EQ2hglOocdtIhqC+b05t6sLSkwx2ukxrU2cegnCBkdyF/FZ/+Et638CUEBbf 4bjplwpt2IPLazQgjkwjMuhz0OcYDpMhwimTvh3mIl+0wzpOts6mEmMw0QZdl3RXvIW+NSynOn7q mz/fAv4Htt6lv2Ka0s6R2voyi+5U7CcIqizPad5qZVn2uxmovcFreTzFt6nk37ZbbTfvA3e5F0bR RQeH3viT5XxpJF4Y76v/Ua+5N3Kd18K0sX85rD1G7cmxR2CZ5gW1X24sDqdYZdDbf10N39UIwjJH PTeuVMQqry792Ap0Etyj135YFCE0loDnZYKvy2Y1i0RuEdTUIonIHrLhe2J0bXQGbQImHIyMgB9/ lva8D+yvy2gyf2vjRhmJEEco7w9FdzP7p3PhKrUiTjRsjHw8iV8LOCFx9njZOq9mism9ZZ16tZpx 9mXOf11HcH1RtVuyyQRS/4ytQPzwshXdSDDW6Btkmo9AbZQKC54/hSyzpp3Br2T2xDH7ecnonDB/ jv8rWuKXSTbX3xWAIrNBNDcTYaNe4jkms4HF7jJE19eRlqsXMMx6Fxvrh4TtKICwJYJ3AUmXrK3X Ti/mjqYfJ1fpBn54rWs8nhSR1fuZPD+aMlcP8BDUPlNKPKtj0DGSh3/VlnnwARAQABtClWaW5jZW 50IEJyZWl0bW9zZXIgPGxvb2tAbXkuYW1hemluLmhvcnNlPokCOAQTAQIAIgUCVTNZmgIbAwYLCQ gHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQe9GDIN6t+hHcVg//aeiijNqsQ3pjbFQn3VvND7hNfJ vrVcLZ+U4kOzXPF818aVdOnDyNXyE17vBDDcvaZ730sCsZIRZJ3KhUJ+nPvdttKjUIGLARmx+pA3 Jl3IIv2uLtOb3I0TMuyfIGJVGF+q10/CeDMKVjKlmyOVrR0opkel+KEoN7VLq3Hf3zPKENO1HBgp LHeP31tlb9cgs+u4o2wLrVe9myHbuFBW7EjWbSvdz2zliwbsFeFVLMNcWrKAU0GkkiH69SgnwmXU RkhGma4L27GLtkHHufsxfbcPqPtmtCttsGZU4EmrghGUqVyDOxnn8ZqybzLrRfpin+OCIX+aHJz5 r2L8qtrP0LorNMX3Gopd26vfhNvq/wq8xk++bW1R5FmkaUhx9h+DhO2ybcg7p/E8JHc8zrWv+bb3 0o9lkrOaU8GxXrgtb1cjtbb+MxFvjm0Elw7MSZDG7sF/APFU6cwuIA9Nai/OGAUCSt/W2ecS8Zox cWWbGSEiDvjtEctkpmHjfVuGoL34966Olm41VdH+NjgoSYUJKx4Mty8DRcZxdyoXll84LvDkEEYK ZqOIACsJf8CDFvUkmhXc+moCj15Yxtj3/RslRVEiOUyrpDwB72zWcZG8YnzoyGxhcRIc/gFejO/y SI8bzCpYngeuTb5NjFG+ChGiInHbQcFeHBlaHtKi2o/B5axIO5Ag0EVDvOgQEQALJby/ztliToGE u1lslvWQUQ6teKZVUQ7hy9bM4N83G0AGLatUBHtY6PkJBe4XkIw3sK7LoFCV2W4GSt4zWp9l+kG3 /J8Ow7EFjN0F7DrCg0M0lMg9dQz9jYSoBR8skaH3BRzCq9AKIVKV94poL/G65289L7zKDHoZnnyF qbBtedYZir0SZx+kiouZ1qnmxRPaYmH2fkuiuvYEAyzLDLYM8F5gQhdZM4YVtuvSICYPet0z4CDi JX/vZmDi3AzzoEVaKeAM/0H9f9Ni547J2+8dZSllgTrA+fq0aMJVScAObIxTAQtEq0DoNBzPpVrm W10b4bmgePrAvNkifqSr5StymSBgwvoeW6GrJiyN4XhoLOadZzwgjqioR1nXw5tXtrr5sYdkZ06b 1WWHkxtu1hFTdLC7RYNxY07ytLNM+C2lplCwCwlWB7RwI9BL1Dhre4kv8uaaX2Gksaq9mDf9MSDW qQ0TJ/RAiwMGmFrzBEYI1J2Oyeshi/dqW4/OiZAukOIlxOnt6u8zU2KL6Qjxqqna0oTbS4Zv3fRd YkuUCL6CDEJdkuRAiW+Gw+lKcMjXqApEqixhaDkoB/kwtu+2gIFTzAxMfwFN1YtNc0kJZWnFkGIW MrrwTcOwAFzlFz7wn/EyMFtg+ERcqMX0+olXDwM8MODI2+BzulPuEDEteCw09hABEBAAGJAh8EGA ECAAkFAlQ7zoECGwwACgkQe9GDIN6t+hFjuQ//UQyg49f8TytUYQaBb8R0UfI+KhQFs1Nsz2z8a3 0CD1MeiHHYWdAcomVvTkg4g5LbnYHVDrj/XagY3FN/AIE97usFbsTG+rsWAOLi7N2dN2ehWZ634k MvrgyC9uTiOdkw31+B8K5MpyySgD8e6SAzRfiu06/bcQOUyJifw8Hudpj9by4uyGhSH+kHu4afrp OduUighbsGFtcuRwwQ/w/oSk68XvPUgiOQWMZh/pVoXdFyFvrt/hgArCi8dfy5UPK58nl7jPnu/I uQXrJ50nNAFIIxPVeo2/B83KAnEZPU+qWZsdba0V+FIIQQVizLtQFMuJJk4/UTAOfJ2tBpQ9PADX 6/scqDE7unXNWdxcHTjK7KmWjXC8CyhGOx8V/rb7Ial4mZo4cTED6SNlO7dV1XYwnSctL2HCYNM3 RUe4eJ7JWuu7/Nbf6yip2eq7BQKZ9hAH/se/OSZNYsEkZ4pxUc8W5U3uAZImUwC6L74SM0jBZIuD mQhOYX6sZZ6urIn/MYlj4/hqSBFS4vTK7nXRLmtr7+5T5U5srVseUiYc+l9pu9/XD8zGIu+M2xEd 41NwP44GDQTQm0bFljRv5fSblwmi56YHPFQUIh2RZNX3kOJgeyQ3enw5uY+7ocKRVP38hpnffliL lJcO6TtHWnElS3pACbTQM0RHJox3zqU3q6K3c= Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 12:39:34 -0000 > Not rejecting your idea outright, just curious how it would work with > e.g. instant messengers where there is streaming of irregularly-sized > packets coming at irregular intervals (and the users would expect that > Things Just Work(tm) for both two-character messages and five-megabyte > files sent over the wire). I would expect the interface to use non-chunked mode for a simple "buffer in, buffer out" interface ("secret box"), and chunked mode ("secret stream") for streamed data. In your example, a messenger would probably encrypt text messages by passing an entire buffer, while images or larger data could be streamed. This is a useful distinction to have in general, streaming APIs are much harder to use correctly than simple buffered ones. See also libsodium. - V From nobody Mon Mar 18 06:22:47 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C3E131117 for ; Mon, 18 Mar 2019 06:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 f8kqvNPfoUD1 for ; Mon, 18 Mar 2019 06:22:28 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 EDC9413111D for ; Mon, 18 Mar 2019 06:22:27 -0700 (PDT) Received: from p57b22663.dip0.t-ipconnect.de ([87.178.38.99] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1h5sDh-0005SL-RQ; Mon, 18 Mar 2019 13:22:25 +0000 Date: Mon, 18 Mar 2019 14:22:25 +0100 Message-ID: <87pnqoiage.wl-neal@walfield.org> From: "Neal H. Walfield" To: Justus Winter Cc: openpgp@ietf.org In-Reply-To: <871s3475dy.fsf@europa.jade-hamburg.de> References: <871s3475dy.fsf@europa.jade-hamburg.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 13:22:40 -0000 Hi Justus, Thanks for bringing this up. On Mon, 18 Mar 2019 13:07:21 +0100, Justus Winter wrote: > I propose to deprecate compression support in OpenPGP. > ... > I realize that we cannot suddenly drop decompression support, but I > would suggest to stop emitting compressed data packets. If this > proposal gathers traction, I would be happy to suggest a change to the > standard. I propose that we change the standard to say: - Compliant implementations MUST NOT emit compressed data packets. - For backwards compatibility, compliant implementations MAY decompress compressed data packets. Obviously, we should deprecate the "Preferred Compression Algorithms" subpacket as well. Note: removing compression support was one of the original goals: Subject: [openpgp] details of 4880bis work From: Stephen Farrell Message-ID: <5527B621.3040104@cs.tcd.ie> Date: Fri, 10 Apr 2015 12:38:09 +0100 Archived-At: ... g) remove compression entirely ... :) Neal From nobody Mon Mar 18 06:32:04 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5459B1277DB for ; Mon, 18 Mar 2019 06:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com 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 yEmHrad5E_gM for ; Mon, 18 Mar 2019 06:32:01 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5899126CAD for ; Mon, 18 Mar 2019 06:32:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 8C28BE2040; Mon, 18 Mar 2019 09:31:59 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 32033-08; Mon, 18 Mar 2019 09:31:55 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 981EDE2042; Mon, 18 Mar 2019 09:31:55 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1552915915; bh=H1+LErXVsZsRYFdWsl95M/uTFf3qpGZmZ1w0swucgGM=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=ZDkZk6MMmcfXOuuDWuVLRDteEGHLAb8BbNm1q9y4mJd6X4rWWKMSNRt761S/VpJbw 84jVTAo4UXYRe80GDKnUvu9InsyZgPjsSDR5gd0sMuKxVxjwOGd1UCYqiozJQp2iIo bPWWT5kjldyMWYbjgsTZPF7dLrdH0pNrhq6JatiA= Received: from 99.46.190.172 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Mon, 18 Mar 2019 09:31:55 -0400 Message-ID: In-Reply-To: <87pnqoiage.wl-neal@walfield.org> References: <871s3475dy.fsf@europa.jade-hamburg.de> <87pnqoiage.wl-neal@walfield.org> Date: Mon, 18 Mar 2019 09:31:55 -0400 From: "Derek Atkins" To: "Neal H. Walfield" Cc: "Justus Winter" , openpgp@ietf.org User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 13:32:03 -0000 Hi, On Mon, March 18, 2019 9:22 am, Neal H. Walfield wrote: > Hi Justus, > > Thanks for bringing this up. > > On Mon, 18 Mar 2019 13:07:21 +0100, > Justus Winter wrote: >> I propose to deprecate compression support in OpenPGP. >> ... >> I realize that we cannot suddenly drop decompression support, but I >> would suggest to stop emitting compressed data packets. If this >> proposal gathers traction, I would be happy to suggest a change to the >> standard. > > I propose that we change the standard to say: > > - Compliant implementations MUST NOT emit compressed data packets. I would lessen this a tiny bit and say SHOULD NOT. I can still imagine cases where one MAY want to emit a compressed data packet, especially if the sender and receiver have some out-of-band knowledge. > - For backwards compatibility, compliant implementations MAY > decompress compressed data packets. I would also change this to SHOULD, because IMHO backwards compatibility is important and there are decades of compressed data out there. > Obviously, we should deprecate the "Preferred Compression Algorithms" > subpacket as well. > > Note: removing compression support was one of the original goals: > > Subject: [openpgp] details of 4880bis work > From: Stephen Farrell > Message-ID: <5527B621.3040104@cs.tcd.ie> > Date: Fri, 10 Apr 2015 12:38:09 +0100 > Archived-At: > > > ... > > g) remove compression entirely I am not against removing it, but it should be deprecated first IMHO. > ... > > :) Neal -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Mar 18 06:50:27 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1996127988 for ; Mon, 18 Mar 2019 06:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 r9q8EE-7fpa5 for ; Mon, 18 Mar 2019 06:50:24 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 D9CB6127598 for ; Mon, 18 Mar 2019 06:50:23 -0700 (PDT) Received: from p57b22663.dip0.t-ipconnect.de ([87.178.38.99] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1h5sei-0005jW-Rt; Mon, 18 Mar 2019 13:50:20 +0000 Date: Mon, 18 Mar 2019 14:50:20 +0100 Message-ID: <87o968i95v.wl-neal@walfield.org> From: "Neal H. Walfield" To: Vincent Breitmoser Cc: Tobias Mueller , openpgp@ietf.org, Sebastian Schinzel In-Reply-To: <2HK22F68FITOF.35CB8RFLBNB8W@my.amazin.horse> References: <87mumh33nc.wl-neal@walfield.org> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> <87h8co2t4v.wl-neal@walfield.org> <35C892F7-18A8-401E-828D-5CE180A3A731@icloud.com> <87r2brf0f1.wl-neal@walfield.org> <2a014c4a103ba7f52535546f7e77277ea2bdabdf.camel@cryptobitch.de> <90a28b7c-1b02-abbb-eb8d-bec5263a9f89@fh-muenster.de> <2HK22F68FITOF.35CB8RFLBNB8W@my.amazin.horse> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 13:50:26 -0000 On Mon, 18 Mar 2019 13:23:07 +0100, Vincent Breitmoser wrote: > Ideally, a receiver won't ever output unauthenticated plaintext, hence ideally > all of the chunking discussions would be moot. What chunking brings to the table > is to give the *sender* of a message the option to *allow* the *receiver* to > emit partially authenticated plaintext, trading a truncation vulnerability for > the ability to process data on a smaller buffer size than the entire plaintext. > This is useful for $large amounts of data, or streamed workflows with unknown > data sizes. When using chunking correctly, the emitted plaintext is not partially authenticated; it is fully authenticated: all of the bytes are right. As such, I'd prefer to use the term "authenticated prefix" in place of "partially authenticated plaintext". Some questions that come to mind: - Should an implementation ever be allowed to emit unauthenticated plaintext? Is it okay to have a --do-it-anyway flag? How to we prevent implementors from doing it anyways? - What should an implementation do if it is passed a large message (say n times the available RAM) and chunking is disabled? Should implementations be smart enough to detect that they can't process this apriori? Should they wait for the OOM-killer? Should they panic? High-level languages don't make it easy to recover from memory allocation failures. For instance on Rust, an out of memory error results in a panic. It would be a shame if the application crashed, or the sender could DoS the receiver. It seems to me, if we are going to handle the complexity of chunking, then we should just embrace it, and not make it even more complex. If an application wants to protect itself against truncation attacks, then it can buffer the output, or the openpgp implementation can have a flag. > However, I can't see a good use case for variable size > chunking: it adds complexity to spec and implementations in particular on the > receiving side, and pushes the onus on reasoning about chunk sizes to the > implementations, which is basically impossible in the face of interoperability > concerns. I fully agree with this. > I'd like to bring up a new proposal then: Support either no chunking, or > fixed-size chunking. The advantage would be that the sender's position on > authentication is made more explicit: If they don't do chunking, they expect the > receiver to fully buffer and authenticate before processing, which could > currently only be achieved implicitly via a large chunk size. If they use the > fixed-size chunking, they explicitly offer the option to emit partially > authenticated plaintext. I'm concerned about an attacker's ability to twiddle the chunking bit. Do you have any thoughts on how to prevent this? From nobody Mon Mar 18 06:55:38 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B004712798E for ; Mon, 18 Mar 2019 06:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=my.amazin.horse 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 sMP8Zc3I1nyY for ; Mon, 18 Mar 2019 06:55:33 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8495D127598 for ; Mon, 18 Mar 2019 06:55:33 -0700 (PDT) Received: from localhost (dhcp229-087.wlan.rz.tu-bs.de [134.169.229.87]) by mail.mugenguild.com (Postfix) with ESMTPSA id 9C82F5FAFF; Mon, 18 Mar 2019 14:55:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=my.amazin.horse; s=mail; t=1552917331; bh=1dTxAEGYCLgZW1FW0gFy8TGveASd665EV5cGT5lkgAA=; h=Date:From:To:Subject:Autocrypt:From; b=b++blczEiC8iyqmFiR1e/+3MCDje7UNzpKKgIXPOxR9Y1fIQxgjRtL7qdXhwDQM9x 6lqR4uY0UshFO6Gmb0Lh6qmA2hiMk6x22MQ5JRlL6J0BMfLtoEdPv8uAC/0OVp7Q0T tBUx8s5QQaWVTX0F2SBRQUF9JenLLaiYHf1lZ5Bc= Message-Id: <3D752D6Y1RJW8.3KGY8SKIXBW6E@my.amazin.horse> In-Reply-To: References: <871s3475dy.fsf@europa.jade-hamburg.de> <87pnqoiage.wl-neal@walfield.org> Date: Mon, 18 Mar 2019 14:55:29 +0100 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Vincent Breitmoser To: "Derek Atkins" Cc: "Neal H. Walfield" , openpgp@ietf.org, Justus Winter Autocrypt: addr=look@my.amazin.horse; keydata=mQINBFAB3UABEADCyB/vbIBA3m1Bwc yjTieEMLySwYgt54EQ2hglOocdtIhqC+b05t6sLSkwx2ukxrU2cegnCBkdyF/FZ/+Et638CUEBbf 4bjplwpt2IPLazQgjkwjMuhz0OcYDpMhwimTvh3mIl+0wzpOts6mEmMw0QZdl3RXvIW+NSynOn7q mz/fAv4Htt6lv2Ka0s6R2voyi+5U7CcIqizPad5qZVn2uxmovcFreTzFt6nk37ZbbTfvA3e5F0bR RQeH3viT5XxpJF4Y76v/Ua+5N3Kd18K0sX85rD1G7cmxR2CZ5gW1X24sDqdYZdDbf10N39UIwjJH PTeuVMQqry792Ap0Etyj135YFCE0loDnZYKvy2Y1i0RuEdTUIonIHrLhe2J0bXQGbQImHIyMgB9/ lva8D+yvy2gyf2vjRhmJEEco7w9FdzP7p3PhKrUiTjRsjHw8iV8LOCFx9njZOq9mism9ZZ16tZpx 9mXOf11HcH1RtVuyyQRS/4ytQPzwshXdSDDW6Btkmo9AbZQKC54/hSyzpp3Br2T2xDH7ecnonDB/ jv8rWuKXSTbX3xWAIrNBNDcTYaNe4jkms4HF7jJE19eRlqsXMMx6Fxvrh4TtKICwJYJ3AUmXrK3X Ti/mjqYfJ1fpBn54rWs8nhSR1fuZPD+aMlcP8BDUPlNKPKtj0DGSh3/VlnnwARAQABtClWaW5jZW 50IEJyZWl0bW9zZXIgPGxvb2tAbXkuYW1hemluLmhvcnNlPokCOAQTAQIAIgUCVTNZmgIbAwYLCQ gHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQe9GDIN6t+hHcVg//aeiijNqsQ3pjbFQn3VvND7hNfJ vrVcLZ+U4kOzXPF818aVdOnDyNXyE17vBDDcvaZ730sCsZIRZJ3KhUJ+nPvdttKjUIGLARmx+pA3 Jl3IIv2uLtOb3I0TMuyfIGJVGF+q10/CeDMKVjKlmyOVrR0opkel+KEoN7VLq3Hf3zPKENO1HBgp LHeP31tlb9cgs+u4o2wLrVe9myHbuFBW7EjWbSvdz2zliwbsFeFVLMNcWrKAU0GkkiH69SgnwmXU RkhGma4L27GLtkHHufsxfbcPqPtmtCttsGZU4EmrghGUqVyDOxnn8ZqybzLrRfpin+OCIX+aHJz5 r2L8qtrP0LorNMX3Gopd26vfhNvq/wq8xk++bW1R5FmkaUhx9h+DhO2ybcg7p/E8JHc8zrWv+bb3 0o9lkrOaU8GxXrgtb1cjtbb+MxFvjm0Elw7MSZDG7sF/APFU6cwuIA9Nai/OGAUCSt/W2ecS8Zox cWWbGSEiDvjtEctkpmHjfVuGoL34966Olm41VdH+NjgoSYUJKx4Mty8DRcZxdyoXll84LvDkEEYK ZqOIACsJf8CDFvUkmhXc+moCj15Yxtj3/RslRVEiOUyrpDwB72zWcZG8YnzoyGxhcRIc/gFejO/y SI8bzCpYngeuTb5NjFG+ChGiInHbQcFeHBlaHtKi2o/B5axIO5Ag0EVDvOgQEQALJby/ztliToGE u1lslvWQUQ6teKZVUQ7hy9bM4N83G0AGLatUBHtY6PkJBe4XkIw3sK7LoFCV2W4GSt4zWp9l+kG3 /J8Ow7EFjN0F7DrCg0M0lMg9dQz9jYSoBR8skaH3BRzCq9AKIVKV94poL/G65289L7zKDHoZnnyF qbBtedYZir0SZx+kiouZ1qnmxRPaYmH2fkuiuvYEAyzLDLYM8F5gQhdZM4YVtuvSICYPet0z4CDi JX/vZmDi3AzzoEVaKeAM/0H9f9Ni547J2+8dZSllgTrA+fq0aMJVScAObIxTAQtEq0DoNBzPpVrm W10b4bmgePrAvNkifqSr5StymSBgwvoeW6GrJiyN4XhoLOadZzwgjqioR1nXw5tXtrr5sYdkZ06b 1WWHkxtu1hFTdLC7RYNxY07ytLNM+C2lplCwCwlWB7RwI9BL1Dhre4kv8uaaX2Gksaq9mDf9MSDW qQ0TJ/RAiwMGmFrzBEYI1J2Oyeshi/dqW4/OiZAukOIlxOnt6u8zU2KL6Qjxqqna0oTbS4Zv3fRd YkuUCL6CDEJdkuRAiW+Gw+lKcMjXqApEqixhaDkoB/kwtu+2gIFTzAxMfwFN1YtNc0kJZWnFkGIW MrrwTcOwAFzlFz7wn/EyMFtg+ERcqMX0+olXDwM8MODI2+BzulPuEDEteCw09hABEBAAGJAh8EGA ECAAkFAlQ7zoECGwwACgkQe9GDIN6t+hFjuQ//UQyg49f8TytUYQaBb8R0UfI+KhQFs1Nsz2z8a3 0CD1MeiHHYWdAcomVvTkg4g5LbnYHVDrj/XagY3FN/AIE97usFbsTG+rsWAOLi7N2dN2ehWZ634k MvrgyC9uTiOdkw31+B8K5MpyySgD8e6SAzRfiu06/bcQOUyJifw8Hudpj9by4uyGhSH+kHu4afrp OduUighbsGFtcuRwwQ/w/oSk68XvPUgiOQWMZh/pVoXdFyFvrt/hgArCi8dfy5UPK58nl7jPnu/I uQXrJ50nNAFIIxPVeo2/B83KAnEZPU+qWZsdba0V+FIIQQVizLtQFMuJJk4/UTAOfJ2tBpQ9PADX 6/scqDE7unXNWdxcHTjK7KmWjXC8CyhGOx8V/rb7Ial4mZo4cTED6SNlO7dV1XYwnSctL2HCYNM3 RUe4eJ7JWuu7/Nbf6yip2eq7BQKZ9hAH/se/OSZNYsEkZ4pxUc8W5U3uAZImUwC6L74SM0jBZIuD mQhOYX6sZZ6urIn/MYlj4/hqSBFS4vTK7nXRLmtr7+5T5U5srVseUiYc+l9pu9/XD8zGIu+M2xEd 41NwP44GDQTQm0bFljRv5fSblwmi56YHPFQUIh2RZNX3kOJgeyQ3enw5uY+7ocKRVP38hpnffliL lJcO6TtHWnElS3pACbTQM0RHJox3zqU3q6K3c= Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 13:55:37 -0000 > > - For backwards compatibility, compliant implementations MAY > > decompress compressed data packets. > > I would also change this to SHOULD, because IMHO backwards compatibility > is important and there are decades of compressed data out there. With v4 keys, yes. But not with v5 keys. We could say MUST NOT compress when encrypting to v5 keys, or perhaps backport this a bit if we say MUST NOT compress with AEAD. Either will be a clear cut. > I would lessen this a tiny bit and say SHOULD NOT. I can still imagine > cases where one MAY want to emit a compressed data packet, especially if > the sender and receiver have some out-of-band knowledge. Keep in mind anything we keep as a SHOULD will definitely have to be supported by implementations forever on the receiving side. It would be nice if future implementations were able to also drop that attack surface altogether, together with v4 key or non-AE encryption support. - V From nobody Mon Mar 18 06:57:48 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D29127598 for ; Mon, 18 Mar 2019 06:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com 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 ss_Kul5LqyJu for ; Mon, 18 Mar 2019 06:57:41 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3263D127970 for ; Mon, 18 Mar 2019 06:57:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 96C85E2040; Mon, 18 Mar 2019 09:57:39 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 32594-05; Mon, 18 Mar 2019 09:57:38 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id F2A78E2042; Mon, 18 Mar 2019 09:57:37 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1552917457; bh=hzvRMupgav/ErSnGE+Mbam4xvLAAWLIeMdU70glCyRs=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=psQqFIx7xuBMro8Qf/ki1FAYs0RnbwQjlTorschR7a8AlbFPmQNvvRdSGO5eBpgSm XFFEemEWnAUg/pdq6GeQMK9y3igshXIBLgzPSA8p2D32AresQGOmTfchbk12SNHNdI s1mH4IA5f4aC0Y4A3gzb6+fDDfgr8eoMU9FVBn7A= Received: from 99.46.190.172 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Mon, 18 Mar 2019 09:57:37 -0400 Message-ID: <431ea8fdaca6b3d20e19cfe2a14f6c96.squirrel@mail2.ihtfp.org> In-Reply-To: <87va0gioae.wl-neal@walfield.org> References: <87d0n174w6.fsf@wheatstone.g10code.de> <87mumh33nc.wl-neal@walfield.org> <3GFS71V7BTJNZ.29C5TO8OY0O44@my.amazin.horse> <87r2bax5u2.wl-neal@walfield.org> <87pnqtwot9.wl-neal@walfield.org> <87y35hy2i0.fsf@wheatstone.g10code.de> <87k1h0we7w.wl-neal@walfield.org> <87va0g65ht.fsf@wheatstone.g10code.de> <87va0gioae.wl-neal@walfield.org> Date: Mon, 18 Mar 2019 09:57:37 -0400 From: "Derek Atkins" To: "Neal H. Walfield" Cc: "Neal H. Walfield" , "Derek Atkins" , openpgp@ietf.org, "Vincent Breitmoser" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 13:57:46 -0000 Hi Neal, On Mon, March 18, 2019 4:23 am, Neal H. Walfield wrote: > Hi Werner, > [snip] > Can you please explain how to get ciphertext integrity when streaming? > > To be clear: for me, truncation is an orthogonal issue; my primary > concern is how to ensure that no implementations ever release > plaintext derived from modified ciphertext. With or without AEAD? > If you think that the current proposal achieves this, I've presented a > few critiques in <87mum6ekbd.wl-neal@walfield.org> > (https://mailarchive.ietf.org/arch/msg/openpgp/WvaisWDd9WzoKXL1FyHDeZNtZ2U): > > 1. If messages can't be decrypted, because a chunk won't fit in > memory, but unauthenticated streaming would otherwise "work," > implementors will do the latter, because security must not get in > the way of a user getting her job done. > > 2. If unauthenticated streaming is allowed or tacitly encouraged, it > will be done first, because the set of messages that > unauthenticated streaming can decrypt is a superset of those that > authenticated decryption can handle, and it will perhaps be done > exclusively because introducing a second code path that, modulo > security concerns, is functionally equivalent to the code path > for unauthenticated streaming is extra work, and extra > complexity, which developers will try to avoid. > > 3. If implementations revert to unauthenticated streaming for large > chunk sizes, an attacker can conduct an EFAIL-style attack by > changing the chunk size. Which implementation? The sender or the receiver? Also, who is the attacker? The Sender? Or a third party? Note that the way I see Chunking + AEAD working together is that there is a 1:1 mapping of Chunk to AEAD block. I realize this is probably a change in the way it's currently working (and it's been 20 years since I wrote the original chunking code), but I feel that AEAD and Chunking go hand-in-hand. Specifically, I see chunking as a way to splice a bunch of separate AEAD blocks together into a chain to ensure you don't drop or reorder the AEAD chunks. The only attack is a DoS if the end is truncated, and the earlier (valid) chunks have already been released. In other words, AEAD is used for each chunked block as a single, coherent piece. Also I don't see how an attacker (third party) could leverage this at all. They couldn't change the chunk size enroute. Granted, if the attacker is the sender they could do much worse things, so you just need to ensure that, as you say, unauthenticated plaintext isn't released. But that cannot happen given the context above. Each chunk is either authenticated, or an error occurs. On error, it wouldn't be released. Chunk sizes SHOULD be limited to ensure processing capability, which is where this conversation started. Of course, this assumes chunked mode. It should still be allowed to have a single AEAD "chunk" if the sender wants to buffer the message. > Thanks! > > :) Neal -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Mar 18 07:23:32 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD69713129B for ; Mon, 18 Mar 2019 07:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=my.amazin.horse 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 AwfTV9QIKtVN for ; Mon, 18 Mar 2019 07:23:21 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05107131140 for ; Mon, 18 Mar 2019 07:23:21 -0700 (PDT) Received: from localhost (dhcp229-087.wlan.rz.tu-bs.de [134.169.229.87]) by mail.mugenguild.com (Postfix) with ESMTPSA id 82C785FAFF; Mon, 18 Mar 2019 15:23:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=my.amazin.horse; s=mail; t=1552918998; bh=F0IXGBSRVX+BpKMBtNYG2jm9VqUn0qXZtu2SkwDU41g=; h=Date:From:To:Subject:Autocrypt:From; b=jLAEDhVeQP3zmxTvYTDDGI6AQiIa5Pm8CPmsFkO2+Luugx36A91Kcr9Lv7dc43qMv IJyIxLm0sSLm2VYvNSZ1B+AMtFtZ3KcEjAxODyjGPqMRBC66r132hwth6QennCJepj OLwCSzylMJp6PlynwUDiV0kFYqEg70J5uWjKDJLM= Message-Id: <3VZ1MAG4BDSBE.2O5DF9N8L7NN1@my.amazin.horse> In-Reply-To: <87o968i95v.wl-neal@walfield.org> References: <87o968i95v.wl-neal@walfield.org> <87mumh33nc.wl-neal@walfield.org> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> <87h8co2t4v.wl-neal@walfield.org> <35C892F7-18A8-401E-828D-5CE180A3A731@icloud.com> <87r2brf0f1.wl-neal@walfield.org> <2a014c4a103ba7f52535546f7e77277ea2bdabdf.camel@cryptobitch.de> <90a28b7c-1b02-abbb-eb8d-bec5263a9f89@fh-muenster.de> <2HK22F68FITOF.35CB8RFLBNB8W@my.amazin.horse> Date: Mon, 18 Mar 2019 15:23:06 +0100 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Vincent Breitmoser To: "Neal H. Walfield" Cc: Tobias Mueller , openpgp@ietf.org, Sebastian Schinzel Autocrypt: addr=look@my.amazin.horse; keydata=mQINBFAB3UABEADCyB/vbIBA3m1Bwc yjTieEMLySwYgt54EQ2hglOocdtIhqC+b05t6sLSkwx2ukxrU2cegnCBkdyF/FZ/+Et638CUEBbf 4bjplwpt2IPLazQgjkwjMuhz0OcYDpMhwimTvh3mIl+0wzpOts6mEmMw0QZdl3RXvIW+NSynOn7q mz/fAv4Htt6lv2Ka0s6R2voyi+5U7CcIqizPad5qZVn2uxmovcFreTzFt6nk37ZbbTfvA3e5F0bR RQeH3viT5XxpJF4Y76v/Ua+5N3Kd18K0sX85rD1G7cmxR2CZ5gW1X24sDqdYZdDbf10N39UIwjJH PTeuVMQqry792Ap0Etyj135YFCE0loDnZYKvy2Y1i0RuEdTUIonIHrLhe2J0bXQGbQImHIyMgB9/ lva8D+yvy2gyf2vjRhmJEEco7w9FdzP7p3PhKrUiTjRsjHw8iV8LOCFx9njZOq9mism9ZZ16tZpx 9mXOf11HcH1RtVuyyQRS/4ytQPzwshXdSDDW6Btkmo9AbZQKC54/hSyzpp3Br2T2xDH7ecnonDB/ jv8rWuKXSTbX3xWAIrNBNDcTYaNe4jkms4HF7jJE19eRlqsXMMx6Fxvrh4TtKICwJYJ3AUmXrK3X Ti/mjqYfJ1fpBn54rWs8nhSR1fuZPD+aMlcP8BDUPlNKPKtj0DGSh3/VlnnwARAQABtClWaW5jZW 50IEJyZWl0bW9zZXIgPGxvb2tAbXkuYW1hemluLmhvcnNlPokCOAQTAQIAIgUCVTNZmgIbAwYLCQ gHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQe9GDIN6t+hHcVg//aeiijNqsQ3pjbFQn3VvND7hNfJ vrVcLZ+U4kOzXPF818aVdOnDyNXyE17vBDDcvaZ730sCsZIRZJ3KhUJ+nPvdttKjUIGLARmx+pA3 Jl3IIv2uLtOb3I0TMuyfIGJVGF+q10/CeDMKVjKlmyOVrR0opkel+KEoN7VLq3Hf3zPKENO1HBgp LHeP31tlb9cgs+u4o2wLrVe9myHbuFBW7EjWbSvdz2zliwbsFeFVLMNcWrKAU0GkkiH69SgnwmXU RkhGma4L27GLtkHHufsxfbcPqPtmtCttsGZU4EmrghGUqVyDOxnn8ZqybzLrRfpin+OCIX+aHJz5 r2L8qtrP0LorNMX3Gopd26vfhNvq/wq8xk++bW1R5FmkaUhx9h+DhO2ybcg7p/E8JHc8zrWv+bb3 0o9lkrOaU8GxXrgtb1cjtbb+MxFvjm0Elw7MSZDG7sF/APFU6cwuIA9Nai/OGAUCSt/W2ecS8Zox cWWbGSEiDvjtEctkpmHjfVuGoL34966Olm41VdH+NjgoSYUJKx4Mty8DRcZxdyoXll84LvDkEEYK ZqOIACsJf8CDFvUkmhXc+moCj15Yxtj3/RslRVEiOUyrpDwB72zWcZG8YnzoyGxhcRIc/gFejO/y SI8bzCpYngeuTb5NjFG+ChGiInHbQcFeHBlaHtKi2o/B5axIO5Ag0EVDvOgQEQALJby/ztliToGE u1lslvWQUQ6teKZVUQ7hy9bM4N83G0AGLatUBHtY6PkJBe4XkIw3sK7LoFCV2W4GSt4zWp9l+kG3 /J8Ow7EFjN0F7DrCg0M0lMg9dQz9jYSoBR8skaH3BRzCq9AKIVKV94poL/G65289L7zKDHoZnnyF qbBtedYZir0SZx+kiouZ1qnmxRPaYmH2fkuiuvYEAyzLDLYM8F5gQhdZM4YVtuvSICYPet0z4CDi JX/vZmDi3AzzoEVaKeAM/0H9f9Ni547J2+8dZSllgTrA+fq0aMJVScAObIxTAQtEq0DoNBzPpVrm W10b4bmgePrAvNkifqSr5StymSBgwvoeW6GrJiyN4XhoLOadZzwgjqioR1nXw5tXtrr5sYdkZ06b 1WWHkxtu1hFTdLC7RYNxY07ytLNM+C2lplCwCwlWB7RwI9BL1Dhre4kv8uaaX2Gksaq9mDf9MSDW qQ0TJ/RAiwMGmFrzBEYI1J2Oyeshi/dqW4/OiZAukOIlxOnt6u8zU2KL6Qjxqqna0oTbS4Zv3fRd YkuUCL6CDEJdkuRAiW+Gw+lKcMjXqApEqixhaDkoB/kwtu+2gIFTzAxMfwFN1YtNc0kJZWnFkGIW MrrwTcOwAFzlFz7wn/EyMFtg+ERcqMX0+olXDwM8MODI2+BzulPuEDEteCw09hABEBAAGJAh8EGA ECAAkFAlQ7zoECGwwACgkQe9GDIN6t+hFjuQ//UQyg49f8TytUYQaBb8R0UfI+KhQFs1Nsz2z8a3 0CD1MeiHHYWdAcomVvTkg4g5LbnYHVDrj/XagY3FN/AIE97usFbsTG+rsWAOLi7N2dN2ehWZ634k MvrgyC9uTiOdkw31+B8K5MpyySgD8e6SAzRfiu06/bcQOUyJifw8Hudpj9by4uyGhSH+kHu4afrp OduUighbsGFtcuRwwQ/w/oSk68XvPUgiOQWMZh/pVoXdFyFvrt/hgArCi8dfy5UPK58nl7jPnu/I uQXrJ50nNAFIIxPVeo2/B83KAnEZPU+qWZsdba0V+FIIQQVizLtQFMuJJk4/UTAOfJ2tBpQ9PADX 6/scqDE7unXNWdxcHTjK7KmWjXC8CyhGOx8V/rb7Ial4mZo4cTED6SNlO7dV1XYwnSctL2HCYNM3 RUe4eJ7JWuu7/Nbf6yip2eq7BQKZ9hAH/se/OSZNYsEkZ4pxUc8W5U3uAZImUwC6L74SM0jBZIuD mQhOYX6sZZ6urIn/MYlj4/hqSBFS4vTK7nXRLmtr7+5T5U5srVseUiYc+l9pu9/XD8zGIu+M2xEd 41NwP44GDQTQm0bFljRv5fSblwmi56YHPFQUIh2RZNX3kOJgeyQ3enw5uY+7ocKRVP38hpnffliL lJcO6TtHWnElS3pACbTQM0RHJox3zqU3q6K3c= Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 14:23:31 -0000 > When using chunking correctly, the emitted plaintext is not partially > authenticated; it is fully authenticated: all of the bytes are right. > As such, I'd prefer to use the term "authenticated prefix" in place of > "partially authenticated plaintext". I'm not sure calling individual bytes "authenticated" is valid if they have been authenticated as part of a larger message. But I don't mind the terminology much one way or another. > - Should an implementation ever be allowed to emit unauthenticated > plaintext? > > Is it okay to have a --do-it-anyway flag? How to we prevent > implementors from doing it anyways? I don't think we can do too much there, one way or another. > - What should an implementation do if it is passed a large message > (say n times the available RAM) and chunking is disabled? They can decide between failing hard, buffering to disk, or taking responsibility for emitting unauthenticated output. Note that this choice is much easier at implementation time if the chunk size isn't variable - either you support chunking, or you don't. > I'm concerned about an attacker's ability to twiddle the chunking bit. > Do you have any thoughts on how to prevent this? Good point. I guess we could simply stick with the "empty chunk at the end" mechanism, which implementations have to have anyways for chunked AE? - V From nobody Mon Mar 18 07:23:48 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790A01312B6 for ; Mon, 18 Mar 2019 07:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 aIzAbjbBTysP for ; Mon, 18 Mar 2019 07:23:35 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 A39DD131294 for ; Mon, 18 Mar 2019 07:23:26 -0700 (PDT) Received: from p57b22663.dip0.t-ipconnect.de ([87.178.38.99] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1h5tAh-00063O-RT; Mon, 18 Mar 2019 14:23:23 +0000 Date: Mon, 18 Mar 2019 15:23:23 +0100 Message-ID: <87mulsi7ms.wl-neal@walfield.org> From: "Neal H. Walfield" To: "Derek Atkins" Cc: openpgp@ietf.org, "Vincent Breitmoser" In-Reply-To: <431ea8fdaca6b3d20e19cfe2a14f6c96.squirrel@mail2.ihtfp.org> References: <87d0n174w6.fsf@wheatstone.g10code.de> <87mumh33nc.wl-neal@walfield.org> <3GFS71V7BTJNZ.29C5TO8OY0O44@my.amazin.horse> <87r2bax5u2.wl-neal@walfield.org> <87pnqtwot9.wl-neal@walfield.org> <87y35hy2i0.fsf@wheatstone.g10code.de> <87k1h0we7w.wl-neal@walfield.org> <87va0g65ht.fsf@wheatstone.g10code.de> <87va0gioae.wl-neal@walfield.org> <431ea8fdaca6b3d20e19cfe2a14f6c96.squirrel@mail2.ihtfp.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 14:23:46 -0000 On Mon, 18 Mar 2019 14:57:37 +0100, Derek Atkins wrote: > On Mon, March 18, 2019 4:23 am, Neal H. Walfield wrote: > > Hi Werner, > > Can you please explain how to get ciphertext integrity when streaming? > > > > To be clear: for me, truncation is an orthogonal issue; my primary > > concern is how to ensure that no implementations ever release > > plaintext derived from modified ciphertext. > > With or without AEAD? Well, whatever :). As I understand Werner, he agrees that ciphertext integrity while streaming is desirable, and, I guess, thinks that is achievable with the current draft. I don't think it is possible, and I've raised a few concerns in my prior mails. I hope Werner can address those concerns. > > If you think that the current proposal achieves this, I've presented a > > few critiques in <87mum6ekbd.wl-neal@walfield.org> > > (https://mailarchive.ietf.org/arch/msg/openpgp/WvaisWDd9WzoKXL1FyHDeZNtZ2U): > > > > 1. If messages can't be decrypted, because a chunk won't fit in > > memory, but unauthenticated streaming would otherwise "work," > > implementors will do the latter, because security must not get in > > the way of a user getting her job done. > > > > 2. If unauthenticated streaming is allowed or tacitly encouraged, it > > will be done first, because the set of messages that > > unauthenticated streaming can decrypt is a superset of those that > > authenticated decryption can handle, and it will perhaps be done > > exclusively because introducing a second code path that, modulo > > security concerns, is functionally equivalent to the code path > > for unauthenticated streaming is extra work, and extra > > complexity, which developers will try to avoid. > > > > 3. If implementations revert to unauthenticated streaming for large > > chunk sizes, an attacker can conduct an EFAIL-style attack by > > changing the chunk size. > > Which implementation? The sender or the receiver? I'm assuming that the sender is using the best we have to offer, i.e., chunked AEAD. I'm assuming that the receiver emits unauthenticated plaintext in some situations. > Also, who is the > attacker? The Sender? Or a third party? I'm thinking of something like EFAIL. So, a third-party attacker who modifies the ciphertext. > The only attack is a DoS if the end is > truncated, and the earlier (valid) chunks have already been released. > > In other words, AEAD is used for each chunked block as a single, coherent > piece. Also I don't see how an attacker (third party) could leverage this > at all. They couldn't change the chunk size enroute. I hacked Sequoia to emit unauthenticated data, and I was able to change the chunk size and still get the plaintext of at least the first chunk of a message. So, my concern is: if a receiving implementation releases unauthenticated plaintext for large chunks rather than fail with ENOMEM, then a third-party attacker can change the chunk size of an intercepted message, and cause the receiver to process unauthenticated data, even though a small chunk size was originally used. > Each chunk is either > authenticated, or an error occurs. On error, it wouldn't be released. The question for me is: what does an implementation do if it can't buffer the message? Does it really throw an error? There already exists at least one implementation written by an editor listed on 4880bis that processes unauthenticated plaintext. From nobody Mon Mar 18 07:27:48 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB296127918 for ; Mon, 18 Mar 2019 07:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=my.amazin.horse 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 B7Hi6A7gxHrN for ; Mon, 18 Mar 2019 07:27:46 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5ECB12423B for ; Mon, 18 Mar 2019 07:27:45 -0700 (PDT) Received: from localhost (dhcp229-087.wlan.rz.tu-bs.de [134.169.229.87]) by mail.mugenguild.com (Postfix) with ESMTPSA id F09E75FAFF; Mon, 18 Mar 2019 15:27:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=my.amazin.horse; s=mail; t=1552919264; bh=ruYfTFSq6OCln6pn/WbdCcZGWArCfZpPXPozm+HWG3M=; h=Date:From:To:Subject:Autocrypt:From; b=jXHtA59cebMZECkK25J7T4jj8sESFtAwwMNztOrCKE9+iiJHpy3PqkYf2Ne9aHbRI 0qzSyPDSLkGU4jEnBrdhytyr7htZhGQ2rq/CvJxaDkKlAGRA8AD+PK2x47n1xiNgFG a9ANS2P6ou5DY1UJaYY/KBMwC0tYHACbG+XQeH60= Message-Id: <3G3KNESYHBWGN.3VKH8PG8TYPOW@my.amazin.horse> In-Reply-To: <3VZ1MAG4BDSBE.2O5DF9N8L7NN1@my.amazin.horse> References: <3VZ1MAG4BDSBE.2O5DF9N8L7NN1@my.amazin.horse> <87o968i95v.wl-neal@walfield.org> <87mumh33nc.wl-neal@walfield.org> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> <87h8co2t4v.wl-neal@walfield.org> <35C892F7-18A8-401E-828D-5CE180A3A731@icloud.com> <87r2brf0f1.wl-neal@walfield.org> <2a014c4a103ba7f52535546f7e77277ea2bdabdf.camel@cryptobitch.de> <90a28b7c-1b02-abbb-eb8d-bec5263a9f89@fh-muenster.de> <2HK22F68FITOF.35CB8RFLBNB8W@my.amazin.horse> Date: Mon, 18 Mar 2019 15:27:43 +0100 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Vincent Breitmoser To: Vincent Breitmoser Cc: "Neal H. Walfield" , Tobias Mueller , openpgp@ietf.org, Sebastian Schinzel Autocrypt: addr=look@my.amazin.horse; keydata=mQINBFAB3UABEADCyB/vbIBA3m1Bwc yjTieEMLySwYgt54EQ2hglOocdtIhqC+b05t6sLSkwx2ukxrU2cegnCBkdyF/FZ/+Et638CUEBbf 4bjplwpt2IPLazQgjkwjMuhz0OcYDpMhwimTvh3mIl+0wzpOts6mEmMw0QZdl3RXvIW+NSynOn7q mz/fAv4Htt6lv2Ka0s6R2voyi+5U7CcIqizPad5qZVn2uxmovcFreTzFt6nk37ZbbTfvA3e5F0bR RQeH3viT5XxpJF4Y76v/Ua+5N3Kd18K0sX85rD1G7cmxR2CZ5gW1X24sDqdYZdDbf10N39UIwjJH PTeuVMQqry792Ap0Etyj135YFCE0loDnZYKvy2Y1i0RuEdTUIonIHrLhe2J0bXQGbQImHIyMgB9/ lva8D+yvy2gyf2vjRhmJEEco7w9FdzP7p3PhKrUiTjRsjHw8iV8LOCFx9njZOq9mism9ZZ16tZpx 9mXOf11HcH1RtVuyyQRS/4ytQPzwshXdSDDW6Btkmo9AbZQKC54/hSyzpp3Br2T2xDH7ecnonDB/ jv8rWuKXSTbX3xWAIrNBNDcTYaNe4jkms4HF7jJE19eRlqsXMMx6Fxvrh4TtKICwJYJ3AUmXrK3X Ti/mjqYfJ1fpBn54rWs8nhSR1fuZPD+aMlcP8BDUPlNKPKtj0DGSh3/VlnnwARAQABtClWaW5jZW 50IEJyZWl0bW9zZXIgPGxvb2tAbXkuYW1hemluLmhvcnNlPokCOAQTAQIAIgUCVTNZmgIbAwYLCQ gHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQe9GDIN6t+hHcVg//aeiijNqsQ3pjbFQn3VvND7hNfJ vrVcLZ+U4kOzXPF818aVdOnDyNXyE17vBDDcvaZ730sCsZIRZJ3KhUJ+nPvdttKjUIGLARmx+pA3 Jl3IIv2uLtOb3I0TMuyfIGJVGF+q10/CeDMKVjKlmyOVrR0opkel+KEoN7VLq3Hf3zPKENO1HBgp LHeP31tlb9cgs+u4o2wLrVe9myHbuFBW7EjWbSvdz2zliwbsFeFVLMNcWrKAU0GkkiH69SgnwmXU RkhGma4L27GLtkHHufsxfbcPqPtmtCttsGZU4EmrghGUqVyDOxnn8ZqybzLrRfpin+OCIX+aHJz5 r2L8qtrP0LorNMX3Gopd26vfhNvq/wq8xk++bW1R5FmkaUhx9h+DhO2ybcg7p/E8JHc8zrWv+bb3 0o9lkrOaU8GxXrgtb1cjtbb+MxFvjm0Elw7MSZDG7sF/APFU6cwuIA9Nai/OGAUCSt/W2ecS8Zox cWWbGSEiDvjtEctkpmHjfVuGoL34966Olm41VdH+NjgoSYUJKx4Mty8DRcZxdyoXll84LvDkEEYK ZqOIACsJf8CDFvUkmhXc+moCj15Yxtj3/RslRVEiOUyrpDwB72zWcZG8YnzoyGxhcRIc/gFejO/y SI8bzCpYngeuTb5NjFG+ChGiInHbQcFeHBlaHtKi2o/B5axIO5Ag0EVDvOgQEQALJby/ztliToGE u1lslvWQUQ6teKZVUQ7hy9bM4N83G0AGLatUBHtY6PkJBe4XkIw3sK7LoFCV2W4GSt4zWp9l+kG3 /J8Ow7EFjN0F7DrCg0M0lMg9dQz9jYSoBR8skaH3BRzCq9AKIVKV94poL/G65289L7zKDHoZnnyF qbBtedYZir0SZx+kiouZ1qnmxRPaYmH2fkuiuvYEAyzLDLYM8F5gQhdZM4YVtuvSICYPet0z4CDi JX/vZmDi3AzzoEVaKeAM/0H9f9Ni547J2+8dZSllgTrA+fq0aMJVScAObIxTAQtEq0DoNBzPpVrm W10b4bmgePrAvNkifqSr5StymSBgwvoeW6GrJiyN4XhoLOadZzwgjqioR1nXw5tXtrr5sYdkZ06b 1WWHkxtu1hFTdLC7RYNxY07ytLNM+C2lplCwCwlWB7RwI9BL1Dhre4kv8uaaX2Gksaq9mDf9MSDW qQ0TJ/RAiwMGmFrzBEYI1J2Oyeshi/dqW4/OiZAukOIlxOnt6u8zU2KL6Qjxqqna0oTbS4Zv3fRd YkuUCL6CDEJdkuRAiW+Gw+lKcMjXqApEqixhaDkoB/kwtu+2gIFTzAxMfwFN1YtNc0kJZWnFkGIW MrrwTcOwAFzlFz7wn/EyMFtg+ERcqMX0+olXDwM8MODI2+BzulPuEDEteCw09hABEBAAGJAh8EGA ECAAkFAlQ7zoECGwwACgkQe9GDIN6t+hFjuQ//UQyg49f8TytUYQaBb8R0UfI+KhQFs1Nsz2z8a3 0CD1MeiHHYWdAcomVvTkg4g5LbnYHVDrj/XagY3FN/AIE97usFbsTG+rsWAOLi7N2dN2ehWZ634k MvrgyC9uTiOdkw31+B8K5MpyySgD8e6SAzRfiu06/bcQOUyJifw8Hudpj9by4uyGhSH+kHu4afrp OduUighbsGFtcuRwwQ/w/oSk68XvPUgiOQWMZh/pVoXdFyFvrt/hgArCi8dfy5UPK58nl7jPnu/I uQXrJ50nNAFIIxPVeo2/B83KAnEZPU+qWZsdba0V+FIIQQVizLtQFMuJJk4/UTAOfJ2tBpQ9PADX 6/scqDE7unXNWdxcHTjK7KmWjXC8CyhGOx8V/rb7Ial4mZo4cTED6SNlO7dV1XYwnSctL2HCYNM3 RUe4eJ7JWuu7/Nbf6yip2eq7BQKZ9hAH/se/OSZNYsEkZ4pxUc8W5U3uAZImUwC6L74SM0jBZIuD mQhOYX6sZZ6urIn/MYlj4/hqSBFS4vTK7nXRLmtr7+5T5U5srVseUiYc+l9pu9/XD8zGIu+M2xEd 41NwP44GDQTQm0bFljRv5fSblwmi56YHPFQUIh2RZNX3kOJgeyQ3enw5uY+7ocKRVP38hpnffliL lJcO6TtHWnElS3pACbTQM0RHJox3zqU3q6K3c= Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 14:27:48 -0000 > Good point. I guess we could simply stick with the "empty chunk at the end" > mechanism, which implementations have to have anyways for chunked AE? Actually, using any fixed value as chunk index as additional data would work fine, perhaps reserving all 0xFF for that (and boldly assuming that we'll never have 2^65-1 chunks in an actual message). - V From prvs=9739a0164=james.howard@jhu.edu Mon Mar 18 09:35:05 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A009F131132 for ; Mon, 18 Mar 2019 09:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jhu.edu header.b=Nd4fppTJ; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=livejohnshopkins.onmicrosoft.com header.b=tvUtnmyH 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 HYirhcjnZ_Le for ; Mon, 18 Mar 2019 09:35:01 -0700 (PDT) Received: from IronEB2.johnshopkins.edu (ironeb2.johnshopkins.edu [162.129.199.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9D7A12788D for ; Mon, 18 Mar 2019 09:35:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=jhu.edu; i=@jhu.edu; q=dns/txt; s=jhuiron; t=1552926900; x=1584462900; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=wCjN7Fy+d1w70mcjAJ8T7pVaNNuHuCgGwG1nFE9uhrc=; b=Nd4fppTJtJUOj68PI7AYc20glB9G7orbIYsDaIA1sAukKSPO7oc0AJGR 8Y3AE2I6DAIUUGcwLyCeIIgN2Glz9sOBIboG8hMKIjFIKZodRB+HMOSlE DBIOC7iBggmljmWAknD3DJh9cL0l79SMdMHRtgSfCnNPNtzB5KQsUYxge I=; IronPort-Data: A9a23:82UxkqlYoRaWlAqfhbNAGRbo5mJPLRPurspz2KjqYX0GODweGkDUK9 VKMmPbWsuDV1oV6QSLyJhcZif/2+qciVDsxsaQcR9ItoljS4ByFsBD0UmzmTiUKgh9uTmjkg 6RwAkUEqIS07r0afPof9burtn/fgIKtY703SKUtWXAp8Aw747ILhQ0ybIJ3FYeJrDkro0fzH eG6QmB0ecraMFz/dUOIeCvKgP9YEZiVlrrnfAdZlY1G2rdw/4RQ/+AkaMYPCb48eNrKC1Lmq 6uOZEO2ZZTpJwPOV4MjBBh009L8c8OHEEnd5NWzAfqC3kEwCYxijJQ3dmtCK+gStYfyK/SE3 7bWZWBTLJ2roTu67DzDtT3dLV0t6l8Azc8pmoag5K7aAOAt0TIIgNtii7xqDWFQHhl8Q+mRJ YDFrAclKYU9fWovTDaCSiYAFReK7SDIOyN6zW2lmed5Ssbj2cSf0FXz8AtQThWar86wW0c7H HVW2xvA+NWn9XCdpt2pRg+CcQAUqwa87kKHh6fIGKlhQQEMUBiocPoiJzNOaSu2vE01hVVC4 SBJxFKh3WVUdvvcIuOl117LgmBbYCq0+KRboOoMfiPguE7e/8S1C253bw1laIY5QBXADny5f XhU39By5yEfrby8kGXdnqQs6oKprF2nbT9+1bA6h9RP9hgA1hgzjT3KFDaktPsMOAR1fZnZw ArKGj6oGBDh1ZysPfAutg5ONtXQLoWI65bRVeAP583Kmp+XJTDOZTQ3lMFxU9GpHF3Z0b+D0 mDLBoQBjPlm3shOrwMt74gh2dX6xq8Ax3a/6JB3s4WJbhxUkFAOblCaTxp54A2WoTbKdmYoC Ew7NKAS49WVyyfVNyyZ++clB5xNQKlZr+uBC3KVSoKUzgRXKm07BL/18bpWuJqArWHivBy1q dk1NK/tIbtpJL1R/JD/Q5N48+cTlR/qOPYcK54d2xUKABW6NVfra5Rtt8/zBPMV6JuggzOx1 XU3kmpRJn2spnZJuIlU7WmRlBPuwnPYB5BimnTYENklTfHTIvmm/vpIelX6MBpr6djA1wHuu TzWur7xXOU+c8bzBOIO+DD4cJo0o/6cHZpDIUi1aVkDfCN6WrIaoCdAB2mKAi5Cg9sTnZAvG Ovntgyc0UmMWuqQW0= IronPort-PHdr: 9a23:fSl2Lx+ts5gsZf9uRHKM819IXTAuvvDOBiVQ1KB+0+4UIJqq85mqBk HD//Il1AaPAdyDraodw8Pt8InYEVQa5piAtH1QOLdtbDQizfssogo7HcSeAlf6JvO5JwYzHc BFSUM3tyrjaRsdF8nxfUDdrWOv5jAOBBr/KRB1JuPoEYLOksi7ze+/94DPbwlSmDaxfK55IQ mrownWqsQYm5ZpJLwryhvOrHtIeuBWyn1tKFmOgRvy5dq+8YB6/ShItP0v68BPUaPhf6QlVr NYFygpM3o05MLwqxbOSxaE62YGXWUXlhpIBBXF7A3/U5zsvCb2qvZx1S+HNsDtU7s6RSqt4L tqSB/wiScIKTg58H3MisdtiK5XuQ+tqwBjz4LRZoyeKfhwcb7Hfd4CRWRPQNtfVzBPDI2/YY sADeQOPedEoIbyvFYOogeyBQy2Ce/z0DJFhHn71rA63eQ7FgHG2RQtEdYUv3TRstr1L7oZX+ KyzKjG1zrDde5Z0ir65YjKaB8hpO+DXalqfcrRzkkuGRnKjk+NpoH+PTOV1vkNv3KF4OV9SO KikmgqoBx/rDiow8cjkIjJhoQNx1/a+yV22oc1JdmiREFmf9GoCIdfuDucN4tqXMwiWXpnuD sgyrwGo5K0ZjQFxI4hxx/ec/CHcpaH4g7tVOqLJjd4nn1ldbSijBix6Uit0vDwWtWu3FpXrS dJj8PAum4N2hDJ98SKRPlw8l+g1DuBzQzf9O9JLEAumabGKZMt3KQ8mocSvEjdBiP2llv5ga yKekgh/+Wn9+Tqbqnoq5KZKoN4lg/+Prgrl8G8H+g4PBQBUm2Z9Om9yLHu/Uv0S6hQgPIsiK nWqpXaKNwepq6+HgBazJ4u6w26Dze6yNQYmmQHLE5ddBKHkYfpP1bOLej3A/miglqilyllyP DJMLLgHJnBNHbCkLbnfbpn8UFT1RA/zdJf55JJEL0OPu/8WlLpuNzZCB82LRC0zv76BNlhzI 8SRGGCDrKDPK/MsVKE/P8jLueOaYMNvTbyMfkl5/rgjX8jnl8deLGk3ZkNZ3C9APtmOF+VYX rrgtYPC2gKpBcxQffoiF2CTD5ffWi9UL8h5j0jEoKpEZ/DRpyxgLyGxCq7GYVWaX5AClCUHn fob56JW/YSZyKOLM9tiDsEVaKuS4U5zxGhqBf6y6Z7LurT4iAYt4/j1MNp5+3OjhEz+z10D8 KB026TVWF5hWwIRzos06B+pUxx0EuM0a99g68QKdsGxe5SThohfaHdyfB3EZimWB/aYsqSV1 egXti8KT40R9M1hdQJZhA5U5+llh3FxyWyK74Yi7LNA4Y7uOqI2GD8Id5y017H2bUvyV48TZ 0cG3ehg/td/g3eHMbplFqQjariIaYV2SPWsmeE0mOUsGlaUBM2XKnYCyNMLnDKpMj0sxuRB4 SlDq4qZ04YkZbYcPlDd8HpgFNaRfzqJNXZZSerlnytAQqTmOjed5LkLmMa2iiVSFMJlQwe5z 6nDUA/HW/gxgCWFzlyDRTqakLo//N5rSa5R0o51EeKaFJozbad+B4Iw/GQVqBb0w== X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EnAABex49c/4kZtQpjGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZYEPL1BrdAQyCoQBg0qPKoIyJYNbgjuDHI1RglIDGBclAQc?= =?us-ascii?q?BAwEYAQoJAoN4RgIghF04EgEBAwEBAQgBAQEBAgEBAmkcDII6KQEUMRw5BQE?= =?us-ascii?q?BAQEBASYBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBBQI?= =?us-ascii?q?UJAwSAQEYAQEBAQECAQEQERoDAQEsDA8CAQgRAwECKwICAh8GCx0IAgQBEg4?= =?us-ascii?q?UgwABgV0DFQECDJ5aikJxgS+CeAEBBXSBU4I+DQtAAQeBPQcICQGBJQGBSIM?= =?us-ascii?q?ThAuCLHKBAj+BOAwTgkyCV0cBAQEBX4EgDYJdMYImiEKBcY1xi381BwKCRwS?= =?us-ascii?q?CFoIJBiNIhAKECYNRB4F8W4hfhGGDQIsHhXiBNogIg0UCBAIEBQIVgTUpIoF?= =?us-ascii?q?WMxolTioBgkEJIgERgU0JAxeDSzOETBWFP0AyTVuHOgGBHgEB?= X-IPAS-Result: =?us-ascii?q?A2EnAABex49c/4kZtQpjGgEBAQEBAgEBAQEHAgEBAQGBZ?= =?us-ascii?q?YEPL1BrdAQyCoQBg0qPKoIyJYNbgjuDHI1RglIDGBclAQcBAwEYAQoJAoN4R?= =?us-ascii?q?gIghF04EgEBAwEBAQgBAQEBAgEBAmkcDII6KQEUMRw5BQEBAQEBASYBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBBQIUJAwSAQEYAQEBA?= =?us-ascii?q?QECAQEQERoDAQEsDA8CAQgRAwECKwICAh8GCx0IAgQBEg4UgwABgV0DFQECD?= =?us-ascii?q?J5aikJxgS+CeAEBBXSBU4I+DQtAAQeBPQcICQGBJQGBSIMThAuCLHKBAj+BO?= =?us-ascii?q?AwTgkyCV0cBAQEBX4EgDYJdMYImiEKBcY1xi381BwKCRwSCFoIJBiNIhAKEC?= =?us-ascii?q?YNRB4F8W4hfhGGDQIsHhXiBNogIg0UCBAIEBQIVgTUpIoFWMxolTioBgkEJI?= =?us-ascii?q?gERgU0JAxeDSzOETBWFP0AyTVuHOgGBHgEB?= X-IronPort-AV: E=Sophos;i="5.58,494,1544504400"; d="xml'?xlsx'72,48?scan'72,48,208,72,48,217?p7s'72,48,208,72,48,217?rels'72,48,208,72,48,217"; a="175109357" X-Amp-Result: UNKNOWN(File analysis pending) X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: True Received: from esgmtwex2.win.ad.jhu.edu ([10.181.25.137]) by IronEB2.johnshopkins.edu with ESMTP/TLS/AES256-SHA; 18 Mar 2019 12:34:58 -0400 Received: from ESGMTWEX14.win.ad.jhu.edu (10.181.25.248) by ESGMTWEX2.win.ad.jhu.edu (10.181.25.137) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 18 Mar 2019 12:34:57 -0400 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.173.97.201) by ESGMTWEX14.win.ad.jhu.edu (10.181.25.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 18 Mar 2019 12:34:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=livejohnshopkins.onmicrosoft.com; s=selector1-jhu-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Wf2yF6Trv3UQVNhIzve95s8yDeCvuYChrDMHf0FGixg=; b=tvUtnmyHhdLb7gPfOoGQeo0J9avQADa/Xa2NY/fywm2O+hpQR2UX/mrbLfQYJMJRI7myNcBRPMkNUKpad/6disgjV3fWtC8hf65mQUuCAQevgSKEx661B9jw1Q+RRusYgwhZFe/7++XvsvaEyUKCzK1Cgj6+Ch8Fdo7JeRJdpxw= Received: from BN7PR01MB3681.prod.exchangelabs.com (52.132.7.12) by BN7PR01MB3651.prod.exchangelabs.com (52.132.6.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.14; Mon, 18 Mar 2019 16:34:56 +0000 Received: from BN7PR01MB3681.prod.exchangelabs.com ([fe80::c503:10f0:82fc:7605]) by BN7PR01MB3681.prod.exchangelabs.com ([fe80::c503:10f0:82fc:7605%3]) with mapi id 15.20.1709.015; Mon, 18 Mar 2019 16:34:56 +0000 From: James Howard To: Justus Winter , "openpgp@ietf.org" Thread-Topic: [openpgp] Deprecating compression support Thread-Index: AQHU3Z6G5c/V3W/7AkK6JS/ITr/vBqYRUrwA Date: Mon, 18 Mar 2019 16:34:55 +0000 Message-ID: References: <871s3475dy.fsf@europa.jade-hamburg.de> In-Reply-To: <871s3475dy.fsf@europa.jade-hamburg.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.18.0.190313 authentication-results: spf=none (sender IP is ) smtp.mailfrom=james.howard@jhu.edu; x-originating-ip: [63.235.172.162] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 553814b9-24b8-485e-4917-08d6abbfa7b4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN7PR01MB3651; x-ms-traffictypediagnostic: BN7PR01MB3651: x-microsoft-antispam-prvs: x-forefront-prvs: 098076C36C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(39860400002)(376002)(366004)(396003)(189003)(199004)(110136005)(81156014)(71190400001)(3846002)(966005)(6116002)(81166006)(5024004)(256004)(14454004)(71200400001)(53936002)(5660300002)(606006)(88552002)(82746002)(97736004)(786003)(14444005)(8676002)(58126008)(105586002)(316002)(83716004)(106356001)(7066003)(86362001)(44832011)(2501003)(2616005)(75432002)(6306002)(476003)(54896002)(99286004)(446003)(26005)(6512007)(478600001)(2906002)(6486002)(99936001)(66066001)(236005)(25786009)(68736007)(102836004)(6246003)(6436002)(561944003)(36756003)(76176011)(6506007)(53546011)(7736002)(486006)(11346002)(33656002)(229853002)(186003)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR01MB3651; H:BN7PR01MB3681.prod.exchangelabs.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: DWuYVn1QezCgKUGWmI5ZY9MTIPXaSQ5snxZrGzwGUMc/KR9XiuCdt/2Mk3cbGoG7clkKsSfAb0/jgsOXmAn8sIXiE/s8Etqdamnq9IBnAPI+Iq3yV5Ds/179jfv5rbk44PAp7fTcbzdZVo8vLbQe8EK3UmPNtgcdSYCCb6UGdL+VIOFqCnRU5vniOG8vld3qkcemoVGJarg2W0dauI/oFy5YL1srIJfFmbFwvypS5q6S8PIpIf5+AOR1aBeQwEskeAYLt0HGVyCQfIw5PBaK9Kcd32NZIe1x/g3GUTl8gfTzxTg3u6pPIWTRIiq9gWs+A9wEwMlvzdnwZnUi1tu3x5p+BcDUr/utDnigbV2jgkDD5GUd6kDrNRpb9cn6VNUOVyxCiaSH3dyFyeFKGD7pb3HXL7J1G5mgRnc/sqKQRoY= Content-type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3635757295_781967524" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 553814b9-24b8-485e-4917-08d6abbfa7b4 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2019 16:34:55.9266 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9fa4f438-b1e6-473b-803f-86f8aedf0dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR01MB3651 X-OriginatorOrg: jhu.edu Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 16:43:26 -0000 --B_3635757295_781967524 Content-type: multipart/mixed; boundary="B_3635757294_526583040" --B_3635757294_526583040 Content-type: multipart/alternative; boundary="B_3635757294_2017449390" --B_3635757294_2017449390 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hello, long-time lurker, first time caller.=C2=A0 As I read this, this morning,= I fail to see the advantages.=C2=A0 For instance, let=E2=80=99s look at a couple of t= hese issues: =20 Compression makes it impossible to reason about the size of a decrypted message, =20 It=E2=80=99s hard not to look at this and say, good!=C2=A0 The idea of encryption is = the hide information and burying information about the length of the message= can only be an improvement. =20 - Compression interacts badly with encryption, see e.g. CRIME, BREACH, and hiding of EFAIL-style CFB gadgets [0]. =20 I am not sure how valid this is.=C2=A0 For instance, in the paper cited, we see= the following comments: =20 [F]or OpenPGP, we needed to develop more complex exploit techniques upon ma= lleability gadgets because the data is typically compressed before encryptio= n OpenPGP=E2=80=99s plaintext compression significantly complicates our attack. The difficulty here is to guess a certain amount of compressed plaintext by= tes in order to fully utilize the CFB gadget technique. Not knowing enough c= ompressed plaintext bytes is hardly a countermeasure, but makes practical ex= ploitation a lot harder. =20 The problems described in the paper are not compression, but rather the sen= der drops known plaintext right into the start of the stream.=C2=A0 I mean, it=E2=80= =99s not rocket science and in the, e.g., Facebook example, it could be addres= sed by adding a nonce string to the start of the message.=C2=A0 There are certai= n streams of thought which have advocated this for years, anyway.=C2=A0=20 =20 Then there=E2=80=99s this: =20 - The downstream application is in a better position to decide whether and how to compress data that is then encrypted using OpenPGP. =20 Now, I will admit to misinterpreting this (I think) and assumed you meant c= ompressing after application of PGP.=C2=A0 That=E2=80=99s, of course, silly, but since= I did the work of showing AES cyphertext to be basically incompressible, I = will send it out, anyway.=C2=A0 See the attached Excel spreadsheet for results o= f pre/post-encryption compression on the Canterbury Corpus.=C2=A0 Nothing here s= urprising, but data is good! =20 =E2=80=94James =20 From: openpgp on behalf of Justus Winter Date: Monday, March 18, 2019 at 11:25 To: Subject: [openpgp] Deprecating compression support =20 Hello, =20 I propose to deprecate compression support in OpenPGP. The reasons for this are: =20 - Compression makes it impossible to reason about the size of a decrypted message, requiring the use of a streaming interface even for seemingly small messages, e.g. emails. Experience has shown that downstream users struggle with the correct use of streaming interfaces. =20 - Compression allows the construction of quines. =20 - Compression interacts badly with encryption, see e.g. CRIME, BREACH, and hiding of EFAIL-style CFB gadgets [0]. =20 - The downstream application is in a better position to decide whether and how to compress data that is then encrypted using OpenPGP. =20 - Compression make the standard more complex, and enlarges the trusted computing base of implementations. =20 I realize that we cannot suddenly drop decompression support, but I would suggest to stop emitting compressed data packets. If this proposal gathers traction, I would be happy to suggest a change to the standard. =20 Cheers, Justus =20 0: Section 5.3 of https://efail.de/efail-attack-paper.pdf _______________________________________________ openpgp mailing list openpgp@ietf.org https://www.ietf.org/mailman/listinfo/openpgp =20 --B_3635757294_2017449390 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

 

Compression makes it impossible to reason about th= e size of a

decrypted message= ,

<= p class=3DMsoNormal>&= nbsp;

It=E2=80=99s hard not to look at this and say, good!=C2=A0 The idea o= f encryption is the hide information and burying information about the lengt= h of the message can only be an improvement.

 

  - Compr= ession interacts badly with encryption, see e.g. CRIME,

    BREACH, and hiding of EFA= IL-style CFB gadgets [0].

 

I am= not sure how valid this is.=C2=A0 For instance, in the paper cited, we see the = following comments:

 

  1. [F]or OpenPGP, we needed to develop more comp= lex exploit techniques upon malleability gadgets because the data is typical= ly compressed before encryption
  2. OpenPGP=E2=80=99s plaintext compression signi= ficantly complicates our attack.
  3. The difficulty here is to guess a cert= ain amount of compressed plaintext bytes in order to fully utilize the CFB g= adget technique. Not knowing enough compressed plaintext bytes is hardly a c= ountermeasure, but makes practical exploitation a lot harder.

 = ;

The problems described in the paper are not compression, but ra= ther the sender drops known plaintext right into the start of the stream.=C2=A0 = I mean, it=E2=80=99s not rocket science and in the, e.g., Facebook example, it cou= ld be addressed by adding a nonce string to the start of the message.=C2=A0 Ther= e are certain streams of thought which have advocated this for years, anyway= .=C2=A0

 

Then there=E2=80=99s this:<= /span>

 

  - The downstream application is in a better position to decide = whether

   &nb= sp;and how to compress data that is then encrypted using OpenPGP.

 <= /o:p>

Now, I will admit to misinterpreting this (I think) and assumed y= ou meant compressing after application of PGP.=C2=A0 That=E2=80=99s, of course, silly,= but since I did the work of showing AES cyphertext to be basically incompre= ssible, I will send it out, anyway.=C2=A0 See the attached Excel spreadsheet for= results of pre/post-encryption compression on the Canterbury Corpus.=C2=A0 Nothing here= surprising, but data is good!

 

<= div>

=E2=80=94James

 

From: openpgp <openpgp-bounces@ietf.org> on behalf of= Justus Winter <justuswinter@gmail.com>
Date: Monday, March = 18, 2019 at 11:25
To: <openpgp@ietf.org>
Subject: = [openpgp] Deprecating compression support

 

Hello,

 

I propose to deprecate compression support in OpenPGP.  The= reasons

for this are:

 

  = - Compression makes it impossible to reason about the size of a

    decrypted message, requiring th= e use of a streaming interface even

 &= nbsp;  for seemingly small messages, e.g. emails.  Exper= ience has shown

    tha= t downstream users struggle with the correct use of streaming

=

    interfaces.

 

  -= Compression allows the construction of quines.

 

  - Compre= ssion interacts badly with encryption, see e.g. CRIME,

    BREACH, and hiding of EFAIL-style CFB ga= dgets [0].

 

=

  - The downstream application is in a better p= osition to decide whether

   = ; and how to compress data that is then encrypted using OpenPGP.

 

  - Compression make the standard more complex, and enlarges the=

    trusted computing = base of implementations.

 <= /p>

I realize that we cannot suddenly drop deco= mpression support, but I

would suggest to s= top emitting compressed data packets.  If this

proposal gathers traction, I would be happy to suggest a chang= e to the

standard.

 

Cheers,

Justus

 =

___________________________________________= ____

openpgp mailing list

--B_3635757294_2017449390-- --B_3635757294_526583040 Content-type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="PGP-Compression-Analysis.xlsx"; x-mac-creator="4F50494D" Content-disposition: attachment; filename="PGP-Compression-Analysis.xlsx" Content-transfer-encoding: base64 UEsDBBQABgAIAAAAIQCeLGxvawEAABAFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIo oAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACslMFOwzAMhu9IvEOVK2qzcUAIrdthwBEm MR4gJO4aLU2iOBvb2+NmY0KorELrpVEb+/+/uHYms11jsi0E1M6WbFyMWAZWOqXtqmTvy+f8 nmUYhVXCOAsl2wOy2fT6arLce8CMsi2WrI7RP3COsoZGYOE8WNqpXGhEpNew4l7ItVgBvx2N 7rh0NoKNeWw12HTyCJXYmJg97ejzgSSAQZbND4GtV8mE90ZLEYmUb6365ZIfHQrKTDFYa483 hMF4p0O787fBMe+VShO0gmwhQnwRDWHwneGfLqw/nFsX50U6KF1VaQnKyU1DFSjQBxAKa4DY mCKtRSO0/eY+45+CkadlPDBIe74k3MMR6X8DT8/LEZJMjyHGvQEcuuxJtM+5FgHUWww0GYMD /NTu4ZDCyHlNLTJwEU665/ypbxfBeaQJDvB/gO8RbbNzT0IQoobTkHY1+8mRpv/iE0N7vyhQ Hd483WfTLwAAAP//AwBQSwMEFAAGAAgAAAAhALVVMCP0AAAATAIAAAsACAJfcmVscy8ucmVs cyCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACskk1PwzAMhu9I/IfI99XdkBBC S3dBSLshVH6ASdwPtY2jJBvdvyccEFQagwNHf71+/Mrb3TyN6sgh9uI0rIsSFDsjtnethpf6 cXUHKiZylkZxrOHEEXbV9dX2mUdKeSh2vY8qq7iooUvJ3yNG0/FEsRDPLlcaCROlHIYWPZmB WsZNWd5i+K4B1UJT7a2GsLc3oOqTz5t/15am6Q0/iDlM7NKZFchzYmfZrnzIbCH1+RpVU2g5 abBinnI6InlfZGzA80SbvxP9fC1OnMhSIjQS+DLPR8cloPV/WrQ08cudecQ3CcOryPDJgosf qN4BAAD//wMAUEsDBBQABgAIAAAAIQCSB5TsBAEAAD8DAAAaAAgBeGwvX3JlbHMvd29ya2Jv b2sueG1sLnJlbHMgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAACskstqxDAMRfeF/oPRvnEyfVCGcWbRUphtm36AcJQ4TGIHW33k72tSOsnAkG6yMUjC 9x6Ju9t/d634JB8aZxVkSQqCrHZlY2sF78XLzSOIwGhLbJ0lBQMF2OfXV7tXapHjp2CaPoio YoMCw9xvpQzaUIchcT3ZOKmc75Bj6WvZoz5iTXKTpg/SzzUgP9MUh1KBP5S3IIqhj87/a7uq ajQ9O/3RkeULFjLw0MYFRIG+JlbwWyeREeRl+82a9hzPQpP7WMrxzZYYsjUZvpw/BkPEE8ep FeQ4WYS5XxNGY6ufDDZ2gjm1li5yt2ooDHoq39jHzM+zMW//wciz2Oc/AAAA//8DAFBLAwQU AAYACAAAACEAFY5awFoDAAAzCAAADwAAAHhsL3dvcmtib29rLnhtbKxVXW+cOBR9X2n/A+Kd 2OZzQCHVMIA2UlNFSZo+Vg6Y4A5gakxmoqj/vdfMMEmaajWb7oixsX05nHPvsTn9sG0b44HJ gYsuNskJNg3WFaLk3X1sfr7JrYVpDIp2JW1Ex2LzkQ3mh7O//zrdCLm+E2JtAEA3xGatVB8h NBQ1a+lwInrWwUolZEsVDOU9GnrJaDnUjKm2QTbGPmop78wdQiSPwRBVxQuWimJsWad2IJI1 VAH9oeb9MKO1xTFwLZXrsbcK0fYAcccbrh4nUNNoi+j8vhOS3jUge0s8Yyvh8uFPMDT2/CZY evOqlhdSDKJSJwCNdqTf6CcYEfIqBdu3OTgOyUWSPXBdwwMr6b+TlX/A8p/BCP5jNALWmrwS QfLeieYduNnm2WnFG3a7s65B+/4TbXWlGtNo6KCykitWxmYAQ7Fhrybk2Ccjb2CVYIc4Jjo7 2PlSGiWr6NioGzDyDA+Bvh/ano4EYywbxWRHFVuJToEP97r+1HMT9qoW4HDjin0fuWSwscBf oBVaWkT0brikqjZG2cQm+jyAeFSLDZXfeoJSNqyV6NELY9K3u+A/WJMWWi8CwTtSu/tfxQM3 Gc32u1TSgPvz9COU4Jo+QEGg7OV+v57rjDtfu0JG5OtT5tj50lkFVuYGnpV4bmaFq4Vt4cwj mZtmAfbTHyBG+lEh6Kjqfa01dGy6zm+WLuh2XiE4Gnn5TOMJ73+W7n9p5rUfWrA+1W452wzP rtBDY/uFd6XYxKbtYxD1OA9dYsNwMy1+4aWqIWKB3cPcP4zf18CYBK6eBPdrZrH5FBA/SHCY WsRd2tYycG1rkTqhFdi5neRhTnBKJkboBaXp/ARqU290k+ev9ZlK4KDW/ZRk05CRfoc8L8lU xPmxgjYFeFx3U+CCYDvUEWyrPg5q6sFeHOgRFy8DHLpQEMez3EUI9FzHtlZuamdekKVZ4un6 6PM/+j9Owcnl0fxh0SxrKtWNpMUaPkdXrEroAIbaCQK+L8km3iLBDlB0c5JbLgmxlSS+a3lp 7ngBSVeZlz+T1fKrd55BCzQ9zagaYX/qrTmNI93m+9nDZLWb2Nfp1d6LrlKd9/3T/xZ4Deob dmRwfntk4OrTxc3F5I3fCkBTgnU72QLNZTn7CQAA//8DAFBLAwQUAAYACAAAACEAmfRetS0B AACQAgAAFAAAAHhsL3NoYXJlZFN0cmluZ3MueG1sjJLPTsMwDMbvSLxDlRMclrSVhhhqO6Fp nCcBD5ClXhstf0rsom5PT6bd0h44+vv5sy3b1XayJvuFgNq7mhU8Zxk45Vvtupp9f32sXlmG JF0rjXdQswsg2zaPDxUiZdHrsGY90fAmBKoerETuB3CRnHywkmIYOoFDANliD0DWiDLPX4SV 2rFM+dFRzdYFy0anf0bY3YViw5oKdVNRc9IGKkFNJW7xXZNGKyg3nCaaIbz40ejzElMD7+MA qeWkwbTIVap3QVorAzc4pOgMzkF74ZPBFBkFVORL7QcT5NEV5SIjWqeVcLSpNMnQIS9mmfo6 21F31bOxj1ErU/NC3sHE6xDMt3sIsNo7FS4DxYfJdt7Gy+LtebKn9/3nc1r74JH+aRDxo5o/ AAAA//8DAFBLAwQUAAYACAAAACEAlU/WDcsDAAB6DAAADQAAAHhsL3N0eWxlcy54bWzEV11v GjkUfV+p/8Hy+2Q+mAEGMVQlZLSV2ipSUmlfzeABK/5AHpPCrva/77XNwNAUmiXV7kOCbXzu ufee62szfr8VHD1T3TAlCxzfRBhRWakFk8sCf30sgyFGjSFyQbiStMA72uD3k3e/jRuz4/Rh RalBYEI2BV4Zsx6FYVOtqCDNjVpTCd/USgtiYKqXYbPWlCwaCxI8TKKoHwrCJPYWRqJ6jRFB 9NNmHVRKrIlhc8aZ2TlbGIlq9HEplSZzDq5u45RUaBv3dYK2uiVxqy94BKu0alRtbsBuqOqa VfSlu3mYh6Q6WgLL11mKszBKTmLf6istpaGmz8zKhyfjWknToEptpClwCo7aFIyepPomS/sV KLzfNRk3f6JnwmElweFkXCmuNDIgHWQutiuSCOp33BLO5prZxZoIxnd+2eGc2vt9gkHu7a7Q +uG9+e945kB8iKn3Iia38qtiOuFy2TrJ3y/icmlsII+M84OqiRUQFiZjKH9DtSxhgvbjx90a 5JNwUr0Mbt9Pdi812cVJ1gGEjnAyniu9gM7Q1lMPmP3SZMxpbSDfmi1X9tOoNfyfK2Pg9EzG C0aWShJuS6FFvAIJjQZ6SoHNilVPQHaSU6hmw2xZRzdpnufDdJBGgzRL+q4MgcZyv5la0AXb iAvcPeAeZNkwi/MkhT8n/kX2fQZAx4py/mBD/KM+JDUDrm2N5EaUwnxcQHgY2dPTDkHB/dAn 0E8gsSeg/AiKYfhjECLrNd/ZPuBY/Ay2HmdTJ/hx/oGzpRS0C7jXytDKuNsisjVzzvnkjB/g n2P+shFzqkt3O5zz5y38vTP84Nf/yg/6vpr/Gj3CbpX5mntzuaFt/dO6s3V7pu48uhXeF6A7 N+dq54J23pZrsP8WDR56dHpl3Xq07zc2y5DXzqE+OdIHEZC9cgr8O7x74EmFoPpaK2i+YRxa ms1sPHD3VdsfvgNBOtqwT0DDSyB7+zvVYNBlyn8E+mKPIW8RkKgOwp3y7+O5p7qCvtAiQNsO wt8lBwgkabE9djxnz9gnmuuFh7QB64LWZMPN4+HLAh/Hn11rhgTud92zZ2WciQIfx5/sjRT3 bZB0az418AyBT7TRrMB/3U0H+eyuTIJhNB0GaY9mQZ5NZ0GW3k5nszKPkuj2785D8Q3PRPeu he4Yp6OGw2NS74PdO/9wXCtwZ+Ldd3cxuN31PU/60YcsjoKyF8VB2ifDYNjvZUGZxcmsn07v sjLr+J5d+ZyMwjj2D1PrfDYyTFDOZKtVq1B3FUSC6YUgwlaJ8PijYfIPAAAA//8DAFBLAwQU AAYACAAAACEAma8cYacQAAAyRAAAGAAAAHhsL3dvcmtzaGVldHMvc2hlZXQxLnhtbJxca28b uxH9XqD/QRB6gRZoLL65NGIXcSRLkdIH2tv2YyHLcizEtlxJedwW/e895L6Hu5SUoq2cJfcM yeGQM2dGevuH789Pg6/r3X6zfbka8gs2HKxfVtv7zcunq+Hff759kw0H+8Py5X75tH1ZXw1/ We+Hf7j+9a/eftvuPu8f1+vDAAgv+6vh4+Hwejka7VeP6+fl/mL7un5By8N297w84J+7T6P9 6269vA8vPT+NBGNm9LzcvAxzhMvdKRjbh4fNaj3err48r18OOchu/bQ8YPz7x83rvkR7Xp0C 97zcff7y+ma1fX4FxN3maXP4JYAOB8+ryw+fXra75d0T5v2dq+Vq8H2H/wr8T5ZiwvNI0vNm tdvutw+HCyCP8jHH03cjN1quKqR4/ifBcDXarb9uvAJrKPFjQ+K6whI1mPxBMFOB+eXaXX7Z 3F8N/zvOrFA3fPxmzCfyzTul3Jt3fMLfMMZu39n30mrO/je8fnu/gYb9rAa79cPV8B2//KjM cHT9Nmygf2zW3/aNvweH5d3f1k/r1WENIXw4OGxfP64fDu/XT0/+ZYzA79i77fazf/UDOjEI 2YdXvJDl6rD5us67L6TDrv93kOv/htBRJbX5dzmC27DL/7Ib3C336/fbp39u7g+PGAas6X79 sPzydPjr9ttsvfn0eMBTg9Xw2+ny/pfxer/CPsZgLoQXs9o+ARP/P3jeeHvENlx+D5/fCkh+ YYxiRujh4G69P9xuPOJwsPqyP2yfS7kFVA6CqQcQvwQ5iLjIpGCSe5DEixhneBGf572I1Qsv 4vO8Fzl2XT5h/HHSq6N8xYJ2xsvD8vrtbvttAFPCmuxfl/5g4pceNqw8DrPD42b1+Wabr1qX GjS2xcojvPMQV0OFd66Gezz9es3N29FXbIBV0eWm7OJV5995Tx+M6YMJfXBLH0zpgxl98IE+ mNMHC/rgY+PBCEtUrROWJl4nW6zTz9vXsJJ927VYa+ysfozT1tpDXA0xmGqtGVnquAcX7S7v yy6lNsYd78j2O5NWl8MOan64/tf3p4eXi/d//tP7dz//dix/PxgOfhr+7u3owe+BT//ZvA5+ aqPcUsnTDsmq/c7sqOQpkXwHyYKK/kBFzztE67boxVHRcyK6Y84fG4JbOwoG09oNnZuntDHf +WoIqNrGiN5VbnlasMy1m8Z5k1ZKkglOclgetDlWo9/cYPGD9tiF1NZxrSRnzghDDHqaQyoc j2RzzZqQ0zakyBTTVhrONZPWMTKaeTlObS1RRBN0TseZZcoxp5y0OK5VPdLWauMIP321fef2 apNZ3vjTD+ec0NzS1c6bVOY0JzaUw4bVDnp8XO7W98P83p7oywn309yEG3esoQysT6kMx5nK GHdCGqWlzNrI01ymdNqQ0cxSMmf6clbKxKimRCY3zDmpvMYcU5bY5byYp196oq2UzIW+XJQy xfB6TucpuGMyk9JyxkW9DVq6xEV7ui5957YuydF2Y4IusXMYaRnnLdY5sqqTHDTSZK48HKtf r2FA2BxCOC1UppVxgqzStAA3tGGWAOfeYwngzGUZcyzDlhfaCLI/5zl4xiW1pAR48KwCuGTW W7bSymWamxq8pQbcfqerwXduq4Gsx43NTcofDuT8ylskV/RSykHTahAZxyIpljHLrcro4Tgt wJmklpMAr9QgrNDaMC0zzo12VAsFtshIwyKBXWlBOCWVs1bbTFnYfH1atrTgA8+mA5e8Rnzn thbIGXyTBS1IK8jhNc4bePOADa7cJMc8YgsSRoBdypXSmE1GduW0BM+IhmcJ8NoWlIKJ2kwz puCtc6LIeQEuM3JqLhLgtS1YyXjGmHZcyAw3YrU3W1rwgdDJWvCd21qg/rLLbYEJZxWxk3He Jpix9OqZ5MBH7IHBFAyOWesyCdMgep4WoiUTGbHDWQK+UgYXBicGYDPjNy4n8PNq9I7usEUC vjYKhusGqBmHaWjcEt3q8BHl6foIvdsKIRv0Bl38wauEsZoqpGjD3s4y6mAV0Mesw2lcsMJI ayR3Gb0pSgHMWkZ2yiwloD6mNPauEjhLHFTOaHg2r2agmSACFikBjRsDmwnXnYVWcNaqPrXQ aDN5WPE8Fms6vcSCb9AlqMVvN3pgFW0cNzAj700K6LRa4KxybGdrrRAKNyk5xKelAKUjh3WW EtC4xAXnisFRVNLgvqX+cD0DrC3xsVICKrVgBoCH358xeAnQUI+10OA2rRbfu20t5MS9AZHg 1aK5FHSvjcs2g2ER/9jzD56I8OFI00FuuVWIR3B0Man8KQMvm7rCBb4/HuiNnsIvlOIujNNa 2AxRFI4Xqc3kDb3VqxnggKNaScyg0grncK2wJ7lkJnOG18vQulI8F3fGGZaHma0IkVIDQPRq kZlQ1MUqmriI/NRJGMcxrcBhdxYeFgDyDxKg1Pgs0ko+8k6t16YCvhPXicaFhShSR3d8iS+Z jnSSwK8PMMUR4Xid48bFR30Et3VyVtAe4hwStRM7vkGf/GJpBDvBrxoXLdxqciTnceIxjSgE 73DWwBJjO2vE3FQjBWFgG+59EJyHhD3wlUK8+SkcLlYZ3PQycn3L0WdRdFisSqe+65ML0a7l zh/rnjRoHH9tfdAY5Efoy9wZb/GX0fVf9qkJTPpkzOmTSfTkNnoyjZ7Moicfoifz6MkievKx +aS9aDRkCIt2JpfJqcfbAjmROM49vhSbGcS0Cc+Izqz6VHxm11vRZdMS3slocncCpRlJn3ZJ p6Rmu0+XdMC0pXfTmpH4eZd4SmweFw+YtvguarMpvM2Wn+V/C987zW6iSyDcuujNok0rTe+W SYFcEJyCgVQTuPoqihNnC/ztTMJJssbQqLQABstpyALOWsBTCowrSlkOPkA4LuEd0iCoHLET 1EdZtIDn0YjhL+CqZRxhAsLpBoPaXv6z/GwR+9mU7kSXXr6zaAMHy4lXMSmQexhPwS8n0qse lCc8k7HgXj1Yq5r0xEUvlRLOT5v4DdNCrnTG0aAoKXcGubNSLi5BABG5HH4MYn0BhlpqhA/t m3NeCNbg98iEF0nBaL1clILBngKoLVhxbEMHF8ZIJSVvRDRt7Z7lrovYXacEKLp47XYxoEVT BieCOOsFbuc1LiuaEgSZtZgJAgE47TRZMC3gLRztNvwsBa8qeAROsCE46loacJaRneUTg8NI o9oUvK7gEZYh1hBggJBtz3gPHS3OctRD7zQTii7B2jqo0KIJ7Cx1CgvctD5E5plEA844M84H OsQpLOF5I4LPncIUfKUPcK3Wc3A6A20lnSKu+LwaPacpgxR8pQ8B59+H5JzBaYWB1CdC2z7O ctJFnFqjnCi6hLgpJkWLFkRylGEoYI+Yh+bYV/CiQfThEoovoMJHR/xOzaOREaOhcm0elmUm Ywo3BfgLSSOMeT16yk+nRt8wD4cT0sECDbYUbtFudsFXT5wex4beaXIUXYJ5dLKjRaMAB9Ww 15ypLrDTOoE/AJ4a/0HSMwSE1ETK1B9ooeje6cl8+Ruu0goodCYNYiaweUJbRbyOeTk9zz9Q vy01g0ovPAMJh6yNMJ4ikaonfSPOSqOF3mmOFF16OdKijcNHo7mqSQF9xFQk9KJBviKuzXBH RidXLtwfDTZSSyLpVZ9d4Eg5on+cWgJp5EgrBb5GSpQyDKkJ1NYCTYOxx0UCSwR73aeVs7Jq Ik6rUYoUXXop0qINFGmUHJkU0GmteIIxw05DqgpnII4xaixFUg8XMM2BzVIC6iOM4aBHCSRD SpIrEftiuQBcCWCGCBmXElCpJTCvyK2DJvEbq4/4EWel2ULvNEWKLr0UadlmkDKjXlciZ1V5 XZ5gBE0K7xUsqFOC+HvTAh/J3SwylQR+oRR3YcFVW/DhcPmRllQ8pkirGWAkVCsJCfURxpCo UNoZkNbwgnrSCeKsrFvoTaJMypCiTx9DWjQF0pYqJZG5ql1hxVFIgXjT5B9RsFkl3lh02Sfw a0uRcOgyv4fzj8j3KvBBCka3SgK/cX7B90J9CSp3sC9dw/9sOV8hvjk5Exp6H2FI0aeHIS1a OC5sopEC98jhhdomibQ0rkqfd6Pnx7SCpwUJefTYw5BWClFYKFROoXAXZxPyIDQ4qeApmZ3H iD3wjYOLSTjEyOuBCujzvSQNTX6AHw0YpL6TXjJVn4ofjZ6MoyeT6Mlt9GQaPZlFTz5ET+bR k0X05GPzSXsL0/jhR/hRSb3eH+BHA8aRas/c42xSqHG5Z9mnrvfseCsq+Gz16a741KeUfFLp 045p0Xhw1u7TyY9KIr2n7JOKn3eJjwo/j04eMMf50UqUr4xvVhPLs3zv0DvNj6JLLz9at8Gx pQdlwzW+HksDQkrCJwgMHL7l4qst4IHB4UYFYORHVMDwlwnwrBhzzrxOY2CLu4plFtDIfNPE dz1i1HQS/6EFPI+BUT/IfNG+hUPX42PLs3zs0Lu9+pQeRZdeerRuaxIWeUBaQPfwo9JeTvBV jsCPQr1jab124DdU2kGUmiEuQkWoT18S37sS7IliQh8kBc8geFYKxsymsWB4ZSgOBbeNmjrK jc/rGStaN7xICkbr5aIUDP8YSHTGCDUE+MQMdZVNNrFtXGf56jKuiaP8KLr08aNVEwZFTSvh 6IYv6KB+GBYGL1c4MGYoCECRHNVhIRkVIpEKE/A2ZzABL+B6GMOQBgZC5IGU88o0mfKiWJVO Byqr0BF1gdpFBSuiABCL3fxP+JLQ6R5hXBxHC0UB2EePVk1RxmYShtHjVNXqgEcIEgD5FaWR uyHn0rSCRyxKLSrhQ9fq0ChPwNZ1RqF0XFOOoYIHQURPvQR8rQ9QPoj6Sgk9+lBn5eZC73TJ KLr00KNlCw4pYhwFbOf+qrWBUxzlnL6IiSNFQI2jQEd6iGzsWQq9UgbX8PnBjVoLWlnQuuB5 OXZHuddFCr3WBbJSTKH2yjErcFx224Y6K1EXeqe5UXTp50arRomzk3oCBfgRjeBFJA4sY9CL oZf+tBagDGVfZykBtYWgDhLZCbB8SIOhqre9beaNGeASIDaSElDrBScumGGNmmyFyfSkENRZ KbbQO82NoksvN1q3wdmidpIoKGtcIgwnMIrhkN6RiM/JJVLho5yGptmKoXdqvaEUBPwGOxmM j9G0bnde4SPdQB3pFH5TJyhN9VkKMNfwKHps5aw0m4rr4WjQii69zGjVBueUXuwF9FFLQR2s gZOLxCdMhuqklA1Doa5zCr+pEwsPjGMjK5wvBGNejx++MLWTREFcSye+ugtmgjulz5NW532J LU610cpRAPbSonUbLJfaSSIf1rQTmAl4fs1Q7EEdtmmFb3hUZh0m2uM9tOzE05X4Ugj0QpM3 83r8qJejOkmMv6kTA1/RKNSAOFDuPXZyVr5Nxd91o1UNN+jTx4pWTVhTqpJEMqyhEpxZgU/M aUVqJqVkJEmJw1UM/MjJ1WQskXCj10kJj8p9qpDE6BsKQYoQNSI6/+j56mGIaE52gEPvI5Qo +vRQomULioSoOhJJsFodwiDch1sEn8rT71QdhVyUk1NtJNBrjwtFGv57JTAO2VEyWo49+qph HhP2WF+tDNyA+GaktfjaGsZOa93zXybIv/v+uvy0/uNy92nzsh884dcP/O8KgBPY5T88EP7G 7yKEp9gGd9sDfjOg/Ncjfptjja+w4wt+w8HDdnso/+E5nurXPq7/DwAA//8DAFBLAwQUAAYA CAAAACEAwRcQvk4HAADGIAAAEwAAAHhsL3RoZW1lL3RoZW1lMS54bWzsWc2LGzcUvxf6Pwxz d/w1448l3uDPbJPdJGSdlBy1tuxRVjMykrwbEwIlOfVSKKSll0JvPZTSQAMNvfSPCSS06R/R J83YI63lJJtsSlp2DYtH/r2np/eefnrzdPHSvZh6R5gLwpKWX75Q8j2cjNiYJNOWf2s4KDR8 T0iUjBFlCW75Cyz8S9uffnIRbckIx9gD+URsoZYfSTnbKhbFCIaRuMBmOIHfJozHSMIjnxbH HB2D3pgWK6VSrRgjkvhegmJQe30yISPsDZVKf3upvE/hMZFCDYwo31eqsSWhsePDskKIhehS 7h0h2vJhnjE7HuJ70vcoEhJ+aPkl/ecXty8W0VYmROUGWUNuoP8yuUxgfFjRc/LpwWrSIAiD WnulXwOoXMf16/1av7bSpwFoNIKVprbYOuuVbpBhDVD61aG7V+9Vyxbe0F9ds7kdqo+F16BU f7CGHwy64EULr0EpPlzDh51mp2fr16AUX1vD10vtXlC39GtQRElyuIYuhbVqd7naFWTC6I4T 3gyDQb2SKc9RkA2r7FJTTFgiN+VajO4yPgCAAlIkSeLJxQxP0AiyuIsoOeDE2yXTCBJvhhIm YLhUKQ1KVfivPoH+piOKtjAypJVdYIlYG1L2eGLEyUy2/Cug1TcgL549e/7w6fOHvz1/9Oj5 w1+yubUqS24HJVNT7tWPX//9/RfeX7/+8OrxN+nUJ/HCxL/8+cuXv//xOvWw4twVL7598vLp kxffffXnT48d2tscHZjwIYmx8K7hY+8mi2GBDvvxAT+dxDBCxJJAEeh2qO7LyAJeWyDqwnWw 7cLbHFjGBbw8v2vZuh/xuSSOma9GsQXcY4x2GHc64Kqay/DwcJ5M3ZPzuYm7idCRa+4uSqwA 9+czoFfiUtmNsGXmDYoSiaY4wdJTv7FDjB2ru0OI5dc9MuJMsIn07hCvg4jTJUNyYCVSLrRD YojLwmUghNryzd5tr8Ooa9U9fGQjYVsg6jB+iKnlxstoLlHsUjlEMTUdvotk5DJyf8FHJq4v JER6iinz+mMshEvmOof1GkG/CgzjDvseXcQ2kkty6NK5ixgzkT122I1QPHPaTJLIxH4mDiFF kXeDSRd8j9k7RD1DHFCyMdy3CbbC/WYiuAXkapqUJ4j6Zc4dsbyMmb0fF3SCsItl2jy22LXN iTM7OvOpldq7GFN0jMYYe7c+c1jQYTPL57nRVyJglR3sSqwryM5V9ZxgAWWSqmvWKXKXCCtl 9/GUbbBnb3GCeBYoiRHfpPkaRN1KXTjlnFR6nY4OTeA1AuUf5IvTKdcF6DCSu79J640IWWeX ehbufF1wK35vs8dgX9497b4EGXxqGSD2t/bNEFFrgjxhhggKDBfdgogV/lxEnatabO6Um9ib Ng8DFEZWvROT5I3Fz4myJ/x3yh53AXMGBY9b8fuUOpsoZedEgbMJ9x8sa3pontzAcJKsc9Z5 VXNe1fj/+6pm014+r2XOa5nzWsb19vVBapm8fIHKJu/y6J5PvLHlMyGU7ssFxbtCd30EvNGM BzCo21G6J7lqAc4i+Jo1mCzclCMt43EmPycy2o/QDFpDZd3AnIpM9VR4MyagY6SHdSsVn9Ct +07zeI+N005nuay6mqkLBZL5eClcjUOXSqboWj3v3q3U637oVHdZlwYo2dMYYUxmG1F1GFFf DkIUXmeEXtmZWNF0WNFQ6pehWkZx5QowbRUVeOX24EW95YdB2kGGZhyU52MVp7SZvIyuCs6Z RnqTM6mZAVBiLzMgj3RT2bpxeWp1aaq9RaQtI4x0s40w0jCCF+EsO82W+1nGupmH1DJPuWK5 G3Iz6o0PEWtFIie4gSYmU9DEO275tWoItyojNGv5E+gYw9d4Brkj1FsXolO4dhlJnm74d2GW GReyh0SUOlyTTsoGMZGYe5TELV8tf5UNNNEcom0rV4AQPlrjmkArH5txEHQ7yHgywSNpht0Y UZ5OH4HhU65w/qrF3x2sJNkcwr0fjY+9AzrnNxGkWFgvKweOiYCLg3LqzTGBm7AVkeX5d+Jg ymjXvIrSOZSOIzqLUHaimGSewjWJrszRTysfGE/ZmsGh6y48mKoD9r1P3Tcf1cpzBmnmZ6bF KurUdJPphzvkDavyQ9SyKqVu/U4tcq5rLrkOEtV5Srzh1H2LA8EwLZ/MMk1ZvE7DirOzUdu0 MywIDE/UNvhtdUY4PfGuJz/IncxadUAs60qd+PrK3LzVZgd3gTx6cH84p1LoUEJvlyMo+tIb yJQ2YIvck1mNCN+8OSct/34pbAfdStgtlBphvxBUg1KhEbarhXYYVsv9sFzqdSoP4GCRUVwO 0+v6AVxh0EV2aa/H1y7u4+UtzYURi4tMX8wXteH64r5c2Xxx7xEgnfu1yqBZbXZqhWa1PSgE vU6j0OzWOoVerVvvDXrdsNEcPPC9Iw0O2tVuUOs3CrVyt1sIaiVlfqNZqAeVSjuotxv9oP0g K2Ng5Sl9ZL4A92q7tv8BAAD//wMAUEsDBBQABgAIAAAAIQDCXlkIkAEAABsDAAAQAAgBZG9j UHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAJySTW/bMAyG7wP6HwzdGzltUQyBrGJIV/SwYgGSdmdOpmOhsiSIrJHs10+20dTZ dtqNHy9ePqKo7g6dK3pMZIOvxHJRigK9CbX1+0o87x4uP4uCGHwNLnisxBFJ3OmLT2qTQsTE FqnIFp4q0TLHlZRkWuyAFrntc6cJqQPOadrL0DTW4H0wbx16lldleSvxwOhrrC/jyVBMjque /9e0Dmbgo5fdMWZgrb7E6KwBzq/UT9akQKHh4gmM9RyoLb4eDDol5zKVObdo3pLloy6VnKdq a8DhOo/QDThCJT8K6hFhWN8GbCKtel71aDikguyvvMArUfwEwgGsEj0kC54z4CCbkjF2kTjp HyG9UovIpGQWTMUxnGvnsb3Ry1GQg3PhYDCB5MY54s6yQ/rebCDxP4iXc+KRYeKdcLYD3zRz zjc+OU/6w3sdugj+mBun6Jv1r/Qcd+EeGN/XeV5U2xYS1vkHTus+FdRj3mRyg8m6Bb/H+l3z d2M4g5fp1vXydlFel/lfZzUlP65a/wYAAP//AwBQSwMEFAAGAAgAAAAhAMj+KLZNAQAAdwIA ABEACAFkb2NQcm9wcy9jb3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAIySUUvDMBSF3wX/Q8mzbZrVjRnaDlSGE4WBE8W3kNxtxSYNSbTb vzdtt1rZHnxMzrlfzrkkne1kGXyDsUWlMkSiGAWgeCUKtcnQ62oeTlFgHVOClZWCDO3Boll+ eZFyTXllYGkqDcYVYANPUpZynaGtc5pibPkWJLORdygvrisjmfNHs8Ga8U+2ATyK4wmW4Jhg juEGGOqeiA5IwXuk/jJlCxAcQwkSlLOYRAT/eh0Yac8OtMrAKQu3177TIe6QLXgn9u6dLXpj XddRnbQxfH6C35+fXtqqYaGaXXFAeSo45QaYq0z+yKRfzzIKHqqaGXEVLBYpHujNLktm3bNf +7oAcbs/P3Jq86+0pbqnQAQ+Ju1KHZW35O5+NUf5KCY3YZyEZLoi1zQZ0/Hoo0nxZ76J3V3I Q5Z/Eic08VAyIB4BeYpPvkr+AwAA//8DAFBLAwQUAAYACAAAACEAinPNU6EBAAAbCAAAEAAA AHhsL2NhbGNDaGFpbi54bWxklctunEAQRfeR/A+o9zZDQ5yHhvHCqgjpbpMPQEzHMxKPEaAo /vuQyJ5R6myQOFTB7du36P3T76HPfqV5OU9jHYqHXcjS2E3H8/hShx/fv91/DtmytuOx7acx 1eE1LeHpcPdh37V993xqz2O2vWFc6nBa18vXPF+6Uxra5WG6pHF78nOah3bdbueXfLnMqT0u p5TWoc/jbveYD9sLwmHfZXMdVD2G7LyJCFn/95q/8ebK34mBqPr41nvr8sRQo6pClyeGGlUl ujwx1KiK6PLEUKNqc+OfJ7d1eWKoUbVto+vyxFCj8ovvAjEQlVtC/v8WiIGo/IQuTww1Kt8T cnUDxEBUIhsgBqISHoIYiCI8BDEQRXgIYiCK8BDEQBThIYiBKMJDEANRxHyBGIgi5gvEQBQx XyAGooj5AjEQRWQDxEBUIBsgRgIzPBBA4W1XwRpvlwpvhQq/TPkVyAdXPpPycZNPkhAS6G+g vymw3dDfQH+DHcDgYaYwLjxp3K/MoN+g36DfoN+g37x+8/oNf1Gv33gu3vTn12P98AcAAP// AwBQSwECLQAUAAYACAAAACEAnixsb2sBAAAQBQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRl bnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQC1VTAj9AAAAEwCAAALAAAAAAAAAAAAAAAA AKQDAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQCSB5TsBAEAAD8DAAAaAAAAAAAAAAAA AAAAAMkGAAB4bC9fcmVscy93b3JrYm9vay54bWwucmVsc1BLAQItABQABgAIAAAAIQAVjlrA WgMAADMIAAAPAAAAAAAAAAAAAAAAAA0JAAB4bC93b3JrYm9vay54bWxQSwECLQAUAAYACAAA ACEAmfRetS0BAACQAgAAFAAAAAAAAAAAAAAAAACUDAAAeGwvc2hhcmVkU3RyaW5ncy54bWxQ SwECLQAUAAYACAAAACEAlU/WDcsDAAB6DAAADQAAAAAAAAAAAAAAAADzDQAAeGwvc3R5bGVz LnhtbFBLAQItABQABgAIAAAAIQCZrxxhpxAAADJEAAAYAAAAAAAAAAAAAAAAAOkRAAB4bC93 b3Jrc2hlZXRzL3NoZWV0MS54bWxQSwECLQAUAAYACAAAACEAwRcQvk4HAADGIAAAEwAAAAAA AAAAAAAAAADGIgAAeGwvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQDCXlkIkAEA ABsDAAAQAAAAAAAAAAAAAAAAAEUqAABkb2NQcm9wcy9hcHAueG1sUEsBAi0AFAAGAAgAAAAh AMj+KLZNAQAAdwIAABEAAAAAAAAAAAAAAAAACy0AAGRvY1Byb3BzL2NvcmUueG1sUEsBAi0A FAAGAAgAAAAhAIpzzVOhAQAAGwgAABAAAAAAAAAAAAAAAAAAjy8AAHhsL2NhbGNDaGFpbi54 bWxQSwUGAAAAAAsACwC+AgAAXjEAAAAA --B_3635757294_526583040-- --B_3635757295_781967524 Content-type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUFQYJKoZIhvcNAQcCoIIUBjCCFAICAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghGkMIIFtzCCBJ+gAwIBAgIQHSZTQeHycjMzwwAm1mnzdTANBgkqhkiG9w0BAQsFADCB iTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAk1JMRIwEAYDVQQHEwlBbm4gQXJib3IxEjAQBgNV BAoTCUludGVybmV0MjERMA8GA1UECxMISW5Db21tb24xMjAwBgNVBAMTKUluQ29tbW9uIFJT QSBTdGFuZGFyZCBBc3N1cmFuY2UgQ2xpZW50IENBMB4XDTE4MDgxNDAwMDAwMFoXDTE5MDgx NDIzNTk1OVowga4xGTAXBgNVBAsTEEpIIERpZ2l0YWwgQ2VydHMxITAfBgNVBAoTGEpvaG5z IEhvcGtpbnMgVW5pdmVyc2l0eTERMA8GA1UECBMITWFyeWxhbmQxEjAQBgNVBAcTCUJhbHRp bW9yZTELMAkGA1UEBhMCVVMxFTATBgNVBAMTDEphbWVzIEhvd2FyZDEjMCEGCSqGSIb3DQEJ ARYUamFtZXMuaG93YXJkQGpodS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDAOFa149AOMsnb1JQoXnbuCsd1K1rsUU/g3U6NQdz/hRq8ml/ynl9u0wJP+gftjR5q5y3R /tlrrjIh8A372kc7Gevxof0/3J6JOISc1Qc91nN35H4g7ytAxOe0kFHQUQeygFLLohDmv3aR gQ5EAmXy6j3uJ17EMVb6prLGYff8q0ds/klnL9xhP8Da71VQdh+kJCYEgfcngOId7yaIlema yQyMwwtkY/np2J75oGYT1lQ8wOFEMdTc06+crzXFi8H8XkdUhSNlrdFFmkczw48/0AObA3Uc lXWTnY14tnnXrRWEWlkZ0k+Qxl5wABu0lJ7DrI0wQ66REqyLZP/cXYSdAgMBAAGjggHyMIIB 7jAfBgNVHSMEGDAWgBR97nHQH+upYW2PZoStDysH4jHbvDAdBgNVHQ4EFgQUbFnTfHBLLom3 EVQsojTmuLRKZ/0wDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYI KwYBBQUHAwQGCCsGAQUFBwMCMGoGA1UdIARjMGEwXwYNKwYBBAGuIwEEAwMAATBOMEwGCCsG AQUFBwIBFkBodHRwczovL3d3dy5pbmNvbW1vbi5vcmcvY2VydC9yZXBvc2l0b3J5L2Nwc19z dGFuZGFyZF9jbGllbnQucGRmMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9jcmwuaW5jb21t b24tcnNhLm9yZy9JbkNvbW1vblJTQVN0YW5kYXJkQXNzdXJhbmNlQ2xpZW50Q0EuY3JsMIGK BggrBgEFBQcBAQR+MHwwUAYIKwYBBQUHMAKGRGh0dHA6Ly9jcnQuaW5jb21tb24tcnNhLm9y Zy9JbkNvbW1vblJTQVN0YW5kYXJkQXNzdXJhbmNlQ2xpZW50Q0EuY3J0MCgGCCsGAQUFBzAB hhxodHRwOi8vb2NzcC5pbmNvbW1vbi1yc2Eub3JnMB8GA1UdEQQYMBaBFGphbWVzLmhvd2Fy ZEBqaHUuZWR1MA0GCSqGSIb3DQEBCwUAA4IBAQBnjjY5rrDEW27qnMHStctnmHKx+tVqrM4L ntlY8g6k2axGqA2b4cE5XftSN0Oe8Q2gYtgyDXG/vbx3fWrg7y6WbzO+uoIBoGTFFFHOFWQ6 82Iu7chBvjE6L2kpZpoXuFMl4XcXYgvIZxqpXMvZkDvv85aMDvnAy/kf236P9XyJjF+FyLAR 0UlwNN5qWqKqUYHDPox7Ahn222fIai0UrHrKMEgh0eRNqHwtEwyE4cwqbKvLZ707Pr1TYR7W 4nwA/x2MJI7GtfbLRKJfsCHXV6oQargTm1BdaWlzduAZPWeYPpm2m6FaIrcUuMb5bLM1wRqm g997kQEnB34gGCNG64MqMIIGAzCCA+ugAwIBAgIQP7008rpS/A7TClejgeG+ZDANBgkqhkiG 9w0BAQ0FADCBiDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcT C0plcnNleSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxLjAsBgNVBAMT JVVTRVJUcnVzdCBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTQwOTE5MDAwMDAw WhcNMjQwOTE4MjM1OTU5WjCBiTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAk1JMRIwEAYDVQQH EwlBbm4gQXJib3IxEjAQBgNVBAoTCUludGVybmV0MjERMA8GA1UECxMISW5Db21tb24xMjAw BgNVBAMTKUluQ29tbW9uIFJTQSBTdGFuZGFyZCBBc3N1cmFuY2UgQ2xpZW50IENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAgP7KW3d3xh/sgvvnWYpVrcDqnrEH6CYrNgmi 8S9MOllAnKuc8kApQCWScil4j5sGahB8t2QH/xj8UNuoGCDG5xEZxgFoRz/ZkuzdNJK4ZJ8b 9dIm2XPUTKbgIwluPp38+oLV5P6kpUZ5AGXlPW7otk5+i+Hr9GaqddHbh27hFaodi/JMnIZe +hPlDGnshdZg+KhtiHMDlafCe9Lxko77emOpkahmurX9sy3Sf/zLg5uLiTS9V10KdZdmgJW8 l9G6GhjBbLh960aMdWj9sJr4vrPtWT8yt3EGQFV3cqUvN0kBgCuri97s2U2KvV5frg8zBZW/ NCXRYqw18ZaDi8PbpwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAUU3m/WqorSs9UgOHYm8Cd 8rIDZsswHQYDVR0OBBYEFH3ucdAf66lhbY9mhK0PKwfiMdu8MA4GA1UdDwEB/wQEAwIBhjAS BgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNV HSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHYGCCsGAQUFBwEB BGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJT QUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29t MA0GCSqGSIb3DQEBDQUAA4ICAQB206fEkrXkvbWWXa2Zt9VK1Jn/jkTfRVJOQ3uKfWk80zyM piHpfdGFZLayBbjn/TmZhKuCa8V73JStVPBmo+mGMs9xGbGpQsEWLW0mPkrKjlJjBfULfXJ8 gyKsnXR5CfCDQliKMgxY3jE9HGyXVNNyCWjK7o1sQAtUMAVvbzVkPvHLaXwCe3PlVJruPa/p u3vstIJQQkrgLtibp6JK6VcCDfOTY3+TiHYXkTivLcsLd/QU85NtYfLdhC1I8BgMn0R8ZMlm id5oqmjpQBYqRMsxnIiqak/Y0pyrbzQYiMYq397UphBqV5fhTpGkCQ5NYbHGIHfQ1JFecgOY tyEJUUNkIFVR88kf3wn5TDBf3LMjDec4KaNXpZv4VIKYFWdAbuDAtePoa4DuGyfMy2os/dbD xnt3LKoXcS5SqPpDu61bm619yi3JmmHKlP7k/6mEUKAQxbWuGOFEuMoDGSznqxYZVzDlWG71 2JZP4gYz6iLUVBCyTI2YG6OoXxxQw4BLxmMpo7MCjMiH3XJL1O6E5VpxJolK3ri4NaVB7uH4 YKaNfN799byF5cmjS2m/8Ep2ZqOJuYOJaV3ZsZ+i2YIg+ZHr2bMux5Vw9p+S7EiQu6wZEy4K MkXNYKqNZuwjFuSXUcU+s3Td1Lg3iGHZjtdboJYteU55BH1mWfSnkN4K45IeczCCBd4wggPG oAMCAQICEAH9bTD8o8pRqBu8ZA41Ay0wDQYJKoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMV VGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVVU0VSVHJ1c3QgUlNBIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MB4XDTEwMDIwMTAwMDAwMFoXDTM4MDExODIzNTk1OVowgYgxCzAJ BgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtKZXJzZXkgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVVU0VSVHJ1c3QgUlNB IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKC AgEAgBJlFzYOw9sIs9CsVw127c0n00ytUINh4qogTQktZAnczomfzD2p7PbPwdzx07HWezco EStH2jnGvDoZtF+mvX2do2NCtnbyqTsrkfjib9DsFiCQCT7i6HTJGLSR1GJk23+jBvGIGGqQ Ijy8/hPwhxR79uQfjtTkUcYRZ0YIUcuGFFQ/vDP+fmyc/xadGL1RjjWmp2bIcmfbIWax1Jt4 A8BQOujM8Ny8nkz+rwWWNR9XWrf/zvk9tyy29lTdyOcSOk2uTIq3XJq0tyA9yn8iNK5+O2hm AUTnAU5GU5szYPeUvlM3kHND8zLDU+/bqv50TmnHa4xgk97Exwzf4TKuzJM7UXiVZ4vuPVb+ DNBpDxsP8yUmazNt925H+nND5X4OpWaxKXwyhGNVicQNwZNUMBkTrNN9N6frXTpsNVzbQdcS 2qlJC9/YgIoJk2KOtWbPJYjNhLixP6Q5D9kCnusSTJV882sFqV4Wg8y4Z+LoE53MW4LTTLPt W//e5XOsIzstAL81VXQJSdhJWBp/kjbmUZIO8yZ9HE0XvMnsQybQv0FfQKlERPSZ51eHnlAf V1SoPv10Yy+xUGUJ5lhCLkMaTLTwJUdZ+gQek9QmRkpQgbLevni3/GcV4clXhB4PY9bpYrrW X1Uu6lzGKAgEJTm4Diup8kyXHAc/DVL17e8vgg8CAwEAAaNCMEAwHQYDVR0OBBYEFFN5v1qq K0rPVIDh2JvAnfKyA2bLMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MA0GCSqG SIb3DQEBDAUAA4ICAQBc1HwNz/cBfUGZZQxzxVKfy/jPmQZ/G9pDFZ+eAlVXlhTxUjwnh5Qo 7R86ATeidvxTUMCEm8ZrTrqMIU+ijlVikfNpFdi8iOPEqgv976jpS1UqBiBtVXgpGe5fMFxL JBFV/ySabl4qK+4LTZ9/9wE4lBSVQwcJ+2Cp7hyrEoygml6nmGpZbYs/CPvI0UWvGBVkkBIP cyguxeIkTvxY7PD0Rf4is+svjtLZRWEFwZdvqHZyj4uMNq+/DQXOcY3mpm8fbKZxYsXY0INy DPFnEYkMnBNMcjTfvNVx36px3eG5bIw8El1l2r1XErZDa//l3k1mEVHPma7sF7bocZGM3kn+ 3TVxohUnlBzPYeMmu2+jZyUhXebdHQsuaBs7gq/sg2eF1JhRdLG5mYCJ/394GVx5SmAukkCu TDcqLMnHYsgOXfc2W8rgJSUBtN0aB5x3AD/Q3NXsPdT6uz/MhdZvf6kt37kC9/WXmrU12sNn sIdKqSieI47/XCdr4bBP8wfuAC7UWYfLUkGV6vRH1+5kQVV8jVkCld1incK57loodISlm7eQ xwwH3/WJNnQy1ijBsLAL4JxMwxzW/ONptUdGgS+igqvTY0RwxI3/LTO6rY97tXCIrj4Zz0Ao 2PzIkLtdmSL1UuZYxR+IMUPuiB3Xxo48Q2odpxjefT0W8WL5ypCo/TGCAjUwggIxAgEBMIGe MIGJMQswCQYDVQQGEwJVUzELMAkGA1UECBMCTUkxEjAQBgNVBAcTCUFubiBBcmJvcjESMBAG A1UEChMJSW50ZXJuZXQyMREwDwYDVQQLEwhJbkNvbW1vbjEyMDAGA1UEAxMpSW5Db21tb24g UlNBIFN0YW5kYXJkIEFzc3VyYW5jZSBDbGllbnQgQ0ECEB0mU0Hh8nIzM8MAJtZp83UwDQYJ YIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgft9F4Z3HaHGojTIKDOi8dMyu4v2jtt6l C+GzTyO28HYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkw MzE4MTYzNDU0WjANBgkqhkiG9w0BAQEFAASCAQBOaiVaSAoXBob//ekIUnrp3xdfPktyhdgM s/BLpGB5N8TL4CYdUvX+UpPtLKeaDxoL+bhYyB/xTbLTJqqj1nWclatCtGIz/6+P4dS8vn0d RqvTrQ/RSmvgwWqIHAY4qGf//etC/YLYIsv0sncI1tJC+Oi4HalLbHVD7+OLMUlW8SirJU1m 5RaadIPH18yK9ML2agwq3d94G1tiQjTtDst1+vktiElXia8Lh2YPVMCqQg5iOAjvk77wBmC/ sM3ay7LzKDjdNJWS//dLM2calSFQgSXPXCXq8clUnAH2JdSRMIC9EhmYtlsjjwQ+pxr8SVto GVncGxG/5/39KL9jPRFO --B_3635757295_781967524-- From nobody Mon Mar 18 10:16:04 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F66F130E00 for ; Mon, 18 Mar 2019 10:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 4uwU9RwWvqGF for ; Mon, 18 Mar 2019 10:16:01 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 4A8651200D8 for ; Mon, 18 Mar 2019 10:16:01 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id z11so5354305wmi.0 for ; Mon, 18 Mar 2019 10:16:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:in-reply-to:references:date:message-id:mime-version; bh=pWt/Uazrb1phEqb4/a3oKQK/SopB/ZyTWHItrbbtbHI=; b=d5wztlGJYDeuXHydiBmyeGUg1qNylZB/oYDMiKcn04/3kcMpNzpq5JcfPVUX76SuvA hEDIX+5ORLR4F+udQJV4RnqU9+sGhrJSYwA2iFicqTyHPA5V9D2xxBGbhSoX9tfMi3/q CbX9dJvIUUgA2dp6Vfn7aotmWi8cXs7HhLDjejLWBLhKk5c8yy0WgsZGP3uqid8mh7ix 458iJRMmZSdhPIg+EZpmHYTVz4z6DhCkiGB7uYjvuYtbKbWPfnUMEmmPkI3SW0ZJccik OwyrBcdU99HjHe3b/tywrCSyyN4EKQ75kgybaog77Bk4M1NAqyPXGotQPJlYlXZlFeko cMSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version; bh=pWt/Uazrb1phEqb4/a3oKQK/SopB/ZyTWHItrbbtbHI=; b=GwXekiGnKq+PRM1j0GkQergarwjNqw5YMjQyINLwPXNoFHZWYstfODEPJy8ii9Jj1j cnEQOBq9bsSmzpS1F4blHPU8oKZhtXQpWN9v/u+89z/cZsvb33bJ3cr4tEAnHD47IJ0b zUlNNpL30tcKJoX0o1FvttiejKN4mzfigBE7OmqB/RAyn3VoPwkMo9HboH0BcB5jFfs2 lKVw/V6Ip2PNmqVu67tBfSnjPBxOx8F9YpwmMpKc9HmyhnzhoJP1QJ083clEq/eeXHl8 gbqSY4/wnCR7q1kj9RxTJaIVpgBVsekcccOGBGfsO6rO573m+9lvB9JRlAdNfReOUaER 5wMw== X-Gm-Message-State: APjAAAVSshez/DXu8tNHKFgEEqHNIaz95XjzQezEqfSepZ5xbai6gz95 pIhWAliWlxT3iMcFTpByr0w= X-Google-Smtp-Source: APXvYqzmDVIzXA7CHYRkyQ13waGVh/p+GB2HxXgzbyCZAwwMU649r3qGVjlmwSqpJoLNtdEe/2+APA== X-Received: by 2002:a1c:7306:: with SMTP id d6mr12411716wmb.40.1552929359827; Mon, 18 Mar 2019 10:15:59 -0700 (PDT) Received: from localhost (port-92-193-68-206.dynamic.qsc.de. [92.193.68.206]) by smtp.gmail.com with ESMTPSA id c10sm10250170wrr.1.2019.03.18.10.15.58 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 18 Mar 2019 10:15:59 -0700 (PDT) From: Justus Winter To: James Howard , "openpgp\@ietf.org" In-Reply-To: References: <871s3475dy.fsf@europa.jade-hamburg.de> Date: Mon, 18 Mar 2019 18:15:56 +0100 Message-ID: <87y35c5cj7.fsf@europa.jade-hamburg.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 17:16:03 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable James Howard writes: > Hello, long-time lurker, first time caller.=C2=A0 As I read this, this > morning, I fail to see the advantages.=C2=A0 For instance, let=E2=80=99s = look at a > couple of these issues: > >> Compression makes it impossible to reason about the size of a >> decrypted message, > > It=E2=80=99s hard not to look at this and say, good! What I meant here is that the receiver (i.e. not an adversary) cannot know in advance how big a decrypted message is by looking at the encrypted message. This means that the only safe interface for an OpenPGP library is a streaming one, and this is perceived as difficult to use, and/or to increase the complexity of implementations. > The idea of encryption is the hide information and burying information > about the length of the message can only be an improvement. However, compress-then-encrypt leaks the entropy of the plaintext, see e.g. CRIME, BREACH. >> - Compression interacts badly with encryption, see e.g. CRIME, >> BREACH, and hiding of EFAIL-style CFB gadgets [0]. > > I am not sure how valid this is.=C2=A0 For instance, in the paper cited, = we > see the following comments: > > > [F]or OpenPGP, we needed to develop more complex exploit techniques > > upon malleability gadgets because the data is typically compressed > > before encryption OpenPGP=E2=80=99s plaintext compression significantly > > complicates our attack. The difficulty here is to guess a certain > > amount of compressed plaintext bytes in order to fully utilize the > > CFB gadget technique. Not knowing enough compressed plaintext bytes > > is hardly a countermeasure, but makes practical exploitation a lot > > harder. You conveniently left out the very next paragraph, which I will cite here: > We show how the compression structure can be exploited to create > exfiltration channels. Interestingly, with the compression in place, > we can create exfiltration chan- nels even more precisely and remove > the random data blocks from the resulting plaintext. > Then there=E2=80=99s this: > >> - The downstream application is in a better position to decide whether >> and how to compress data that is then encrypted using OpenPGP. > > Now, I will admit to misinterpreting this (I think) and assumed you > meant compressing after application of PGP.=C2=A0 That=E2=80=99s, of cour= se, silly, I meant compress-then-encrypt, of course. Justus PS: Your MUA is terrible, it doesn't preserve quotations. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEJWpOVeSnLZetJGjniNx+MzhfeR0FAlyP0kwACgkQiNx+Mzhf eR0oCQf9GfUgaOH5v24bf+Rv085vcJ4BB/aBOdIlQcGQiKfhEXS9bb98Ryq7RzGy eoOgLwl8ANGz/UBVK14oujgbukMfOuAvk5j115keveeL5Mw+ah7hCYyUVBuHarmx YISTbuNhHW5uJvO32tvUNXFopvg7njpucRBmzdnLArV1wmNIgfOww+K3t6eprw9w LTNf2nPBM1b7SROK3Z2JENIrN1jlMPJVjNiMfXfzCjeTaRVMmNCh70CmTajvumTh 01f4OL3pSu/Ar2sd5XW8puunjUG2XjTT0hGDJlFXjxjTuIGTQ1K3BVYArbuOosHh ISn9ubKk2u7ibSqUqdiOJUukK4kmHQ== =hPZO -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 18 12:51:46 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251971312AD for ; Mon, 18 Mar 2019 12:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 kQK_cM7S2vFS for ; Mon, 18 Mar 2019 12:51:38 -0700 (PDT) Received: from bitbox.cryptobit.ch (cryptobit.ch [188.40.138.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4935B1312D2 for ; Mon, 18 Mar 2019 12:51:38 -0700 (PDT) Received: from unibox.fritz.box (p5B0F5932.dip0.t-ipconnect.de [91.15.89.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.cryptobit.ch (Postfix) with ESMTPSA id 44NRdf2mjlz13CLF; Mon, 18 Mar 2019 20:51:34 +0100 (CET) Message-ID: <241225ce914a1843b48dab304c760151fe05b764.camel@cryptobitch.de> From: Tobias Mueller To: "Neal H. Walfield" Cc: Derek Atkins , Werner Koch , openpgp@ietf.org, Vincent Breitmoser Date: Mon, 18 Mar 2019 20:51:32 +0100 In-Reply-To: <87sgvkihd1.wl-neal@walfield.org> References: <87d0n174w6.fsf@wheatstone.g10code.de> <87mumh33nc.wl-neal@walfield.org> <3GFS71V7BTJNZ.29C5TO8OY0O44@my.amazin.horse> <87r2bax5u2.wl-neal@walfield.org> <87pnqtwot9.wl-neal@walfield.org> <0f7f492bf18145f96e70886ba19ba290.squirrel@mail2.ihtfp.org> <87lg1gwelf.wl-neal@walfield.org> <61e3fb9d194d0b47f21be8e176daa0b9b6c5d0a5.camel@cryptobitch.de> <87sgvkihd1.wl-neal@walfield.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 19:51:45 -0000 Hi, On Mon, 2019-03-18 at 11:53 +0100, Neal H. Walfield wrote: > > For me, a plaintext is authenticated if the whole ciphertext could > be > > successfully authenticated. Which seems to be very well in line with > the > > definition you've linked to. > > 4880bis defines a chunking mechanism based on AEAD: the message is > split into multiple chunks. In 4880bis, AEAD operates on a per-chunk > basis. The chunking algorithm provides mechanisms for ensuring chunks > can't be reordered, detecting the end of the message, etc. Using AEAD > to decrypt a chunk authenticates that chunk's ciphertext; for a given > chunk, the decryption operation will either return the correct > plaintext, or it will return an error. This is exactly what RFC 5116 > requires. I beg to differ. Because, as you mention: > RFC 5116 doesn't discuss chunking; chunking is not AEAD. > Chunking is not AEAD. It's a protocol on top of AEAD messages that you have to come up with. And then you have to implement it correctly. The security guarantees that AEAD gives you, do not automatically apply to your chunking scheme. As you've said: Chunking is not AEAD. Hence, it cannot automatically be in line with what RFC5116 demands. > You seem to think that AEAD's guarantees must apply to the whole > message. I disagree. I'm glad you're saying this. And yes, I think that proper AE means that the full message enjoys the security guarantees of AE. Also because I am not aware of definitions covering partially authenticated plaintext. And I think that RFC5116 leans more towards full messages rather than trying to define security guarantees for partial plaintext. I further think getting as close to proper AE as possible is a goal worth pursuing. > I agree it is useful, but it is not possible > when streaming. If you absolutely must stream, then there is no way that you can buffer the whole message, otherwise you wouldn't stream. I claim, however, that in the vast majority of use-cases you don't have the requirement of having to stream. As in, purely from a functional perspective, not from an implementation perspective. Hence, imposing the concept of streaming onto everybody somehow does not feel right. I'd like to note, though, that it is possible to not reveal the plaintext no matter how large the message is, though. You can mask the output you release, e.g. XOR it or apply CTR mode, and provide the key to remove the mask only when the ciphertext has checked out correctly. >From the proposal you made it seem you think we should not even try to provide a format for a non-streaming message. Would you describe that as correct? > > I think that even if we add a bit that says: "don't stream", > implementations will ignore it. Hm. I'd classify this as a wilful violation of the spec rather than an accident while implementing it. Once you assume that implementations are doing things wilfully wrongly, it gets messy. I mean... where do we stop making compromises in the security of the spec because we believe someone will wilfully ignore the spec? We rely on the client not actively misinterpreting the spec. Like.. not making secret key material available. Cheers, Tobi From nobody Mon Mar 18 13:46:00 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2CC7130DD3 for ; Mon, 18 Mar 2019 13:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com 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 Zgzhg6CKqB4C for ; Mon, 18 Mar 2019 13:45:55 -0700 (PDT) Received: from mr85p00im-zteg06021901.me.com (mr85p00im-zteg06021901.me.com [17.58.23.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBCE61289FA for ; Mon, 18 Mar 2019 13:45:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1552941955; bh=4hu+9h8M/Mlt52FNFZDicELMMWv/giLuU1VXyiNEgAs=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=pRIh19OmLY3axZ/7jQL30QscWz36OXe1tFZZlSHyb8GwYMBsIf+XXAeczLEZOlVzN X5fTKpUU1/3vwfHhxW/NQH0DY3ComL7ZAb698+Xl+8VwlMtPHUbhhTYPC1HsqaaGSv qH2D+576qLCQbl51JaL9faLmzmcvBbM3TgWQxRqKeDAeOOPZcdHE57hO4/gzANOyAl TR9wx249pKqwv1dbTeVM8nYowZTRuNyRWbP+SivtY8nW5BIkmrm/U2Lj4Y0GB5Iz4P 6LtdROxdCBCcmgOdYuEwAE5KZNBrB4UoU5H/L0V9iE0kjuoiOCLsqKjndVSX7CpRgC +XuLleVQh/VtA== Received: from [192.168.7.69] (thing1.merrymeet.com [173.164.244.99]) by mr85p00im-zteg06021901.me.com (Postfix) with ESMTPSA id EA1CB720135; Mon, 18 Mar 2019 20:45:54 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Jon Callas In-Reply-To: <871s3475dy.fsf@europa.jade-hamburg.de> Date: Mon, 18 Mar 2019 13:45:54 -0700 Cc: Jon Callas Content-Transfer-Encoding: quoted-printable Message-Id: <96055353-B0EB-4E25-95CC-B25D9C5A0BA8@icloud.com> References: <871s3475dy.fsf@europa.jade-hamburg.de> To: openpgp@ietf.org X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-18_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1903180146 Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 20:45:58 -0000 I like the basic proposal. I think that deprecation is better than = banning, and consequently we ought to be doing it with SHOULDs and = SHOULD NOTs rather than MUSTs, as that=E2=80=99s banning rather than = deprecating. However, I want to add that implementations today can deprecate it on = their own and no changes in the standard need not be there. If an = implementation creates a key with compression preferences set to no = compression then any other implementation is bound by the standard not = to compress. I advocate this as well. As OpenPGP sits today, any = implementer can unilaterally not only deprecate, but eliminate = compression. In fact, I=E2=80=99ll go so far as to advocate that all = implementers, even GnuPG ought to just start making keys by default that = eschew compression. More on this below. My rationale for getting rid of compression is different. I think that = the security-based reasons in this thread are largely unconvincing and = often just not quite correct. I don=E2=80=99t want to discuss that in = this thread, because I agree with the destination =E2=80=94 let=E2=80=99s = move away from compression, and am afraid that if we debate the reasons = for it we distract from the result we mutually want. We should deprecate = compression, but not because of security, but because of simplicity, and = in short a case of =E2=80=9Cthat was then, this is now." OpenPGP has many things in it that are needlessly complex, and = compression is one of them. (Other needless complexities include the way = that packet sizes are computed, and others.) Much of this comes from its = heritage as a utility, and a utility that was designed for DOS and = BBSes. The considerations of networking and communications in 1991 are = not at all what we should have for 2021.=20 One of these differences is that zip-style compression is just not as = useful now. Obviously, the wins for compression are on things that are = the largest. Most of the large things we transfer today are already = compressed, and thus compressing them again is mostly a waste of cpu = cycles. There are some file formats that have zip-style compression = built in. For example, GIF and PNG graphics are explicitly compressed. = Other formats like JPEG are a different sort of compression but have the = same characteristic that it is reasonably mathematically pseudo-random = and not readily compressed further. Ditto for audio formats like MP3 and = AAC, while FLAC and ALAC are like GIF and PNG in that they=E2=80=99re = losslessly compressed.=20 Today, the large things we send are media, and therefore there=E2=80=99s = no need to compress them. The things we send that are easily = compressible tend to be smaller. In the cases where large files are sent that can be compressed, the best = solution is for that system to compress the file itself. Remember, = OpenPGP=E2=80=99s history comes from DOS programs on small computers and = they didn=E2=80=99t even have a way to pipe a tar or zip command to an = encryption program. That=E2=80=99s not the case today. Historically, compression has been the largest share of the time it = takes to process a file with an OpenPGP implementation, and thus we are = doing something by default that burns CPU for little gain. We should = stop doing it by default. Again, the best way to do this is to create = keys that have a compression preference of none. We can do this now. Over a decade ago, the PGP program had a feature of the =E2=80=9CPGP = Zip=E2=80=9D file. This was literally nothing more than a tar file that = was run through gzip, and then encrypted with OpenPGP without = compression. PGP itself had some nice viewers that let someone = manipulate the container just as other directory compression systems = did, but any unix system could handle the file by just decrypting with = gnupg and piping that to tar. Later on, as I remember (correct me if = I=E2=80=99m wrong, Derek, or someone), we shifted to bz2. The same = strategy can be improved as compression tools improve. The compression inside of OpenPGP is also hard to implement correctly. = The default compression, the =E2=80=9CDEFLATE=E2=80=9D option is a = modified implementation of ZIP-style programs from the era of the late = 1980s. As those programs coalesced into default (not precisely standard, = merely ubiquitous) implementations, they went in one direction and that = era=E2=80=99s PGP stayed with the variant. When we did RFC 2440, we = added in ZLIB (RFC 1950) encryption so that an implementation wouldn=E2=80= =99t have to hack the compression software. This is another reason to = move away from compression inside OpenPGP. RFC 4880 added in an option = for BZ2 (it was the new hotness at the time), and these days the cool = kids are using 7-Zip as it's even better than bzip. The best way to keep = up with advances in compression is piping from a compressor to some = OpenPGP implementation, rather than continuing to chase advancements. The underlying reality is even worse. Go look at section 5.6 of 2440, = and there are interoperability hints for working with PGP2 because it = had further limitations in it for internal table sizes. This is another = reason to get rid of it for simplicity. It flat isn=E2=80=99t needed. Simply not having compression aids implementation, as well. A number of = years ago, I was putting together a Javascript implementation and there = were no good compression libraries at the time, so we just created keys = that said =E2=80=9Cno compression, please=E2=80=9D and ran with it. = Every implementation can handle decoding an OpenPGP object that is not = compressed, so there are fewer bits of backwards compatibility to = transition away from it. Lastly, I=E2=80=99ll note that everything I=E2=80=99ve said here could = be applied to banning encryption in 4880-bis, as well. I am not opposed = to a ban, but I think deprecation is better, particularly since every = implementation can just stop doing compression by default and everything = will work just fine. Repeating myself, I even advocate this. Everyone = who makes some OpenPGP program can stop today, and likely should. I=E2=80=99= ll even promote that to SHOULD.=20 (The biggest reason against an outright ban is that there are a lot of = systems that use OpenPGP in the midst of some internal process, like = moving around large, sensitive files. There are thus likely a whole lot = of shell scripts somewhere that someone=E2=80=99s got to find and = change, and I wouldn=E2=80=99t be surprised if something breaks if = there=E2=80=99s a sudden shift. If we simply start creating keys with = preference of no compression, it gets maximum quick uptake, and can even = be improved with some options in gnupg.conf or equivalent.) So to sum up, I completely support deprecating compression, because it = improves and simplifies the standard. Today, compression by default is = of limited benefit, and it simplifies implementation and understanding = of OpenPGP to phase it out. I am an enthusiastic supporter of = implementations just making the changes now, without a document change. = I=E2=80=99m also in favor of deprecating. I=E2=80=99m not opposed to a = ban, but I think it=E2=80=99s unneeded. Jon From nobody Mon Mar 18 14:03:31 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8D6131192 for ; Mon, 18 Mar 2019 14:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 NcWI99q8LNgM for ; Mon, 18 Mar 2019 14:03:27 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 1DEE813118B for ; Mon, 18 Mar 2019 14:03:26 -0700 (PDT) Received: from p57b22663.dip0.t-ipconnect.de ([87.178.38.99] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1h5zPh-0000fu-TK; Mon, 18 Mar 2019 21:03:17 +0000 Date: Mon, 18 Mar 2019 22:03:17 +0100 Message-ID: <87imwfj3oq.wl-neal@walfield.org> From: "Neal H. Walfield" To: Tobias Mueller Cc: Derek Atkins , Werner Koch , openpgp@ietf.org, Vincent Breitmoser In-Reply-To: <241225ce914a1843b48dab304c760151fe05b764.camel@cryptobitch.de> References: <87d0n174w6.fsf@wheatstone.g10code.de> <87mumh33nc.wl-neal@walfield.org> <3GFS71V7BTJNZ.29C5TO8OY0O44@my.amazin.horse> <87r2bax5u2.wl-neal@walfield.org> <87pnqtwot9.wl-neal@walfield.org> <0f7f492bf18145f96e70886ba19ba290.squirrel@mail2.ihtfp.org> <87lg1gwelf.wl-neal@walfield.org> <61e3fb9d194d0b47f21be8e176daa0b9b6c5d0a5.camel@cryptobitch.de> <87sgvkihd1.wl-neal@walfield.org> <241225ce914a1843b48dab304c760151fe05b764.camel@cryptobitch.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 21:03:30 -0000 On Mon, 18 Mar 2019 20:51:32 +0100, Tobias Mueller wrote: > On Mon, 2019-03-18 at 11:53 +0100, Neal H. Walfield wrote: > > > For me, a plaintext is authenticated if the whole ciphertext could > > be > > > successfully authenticated. Which seems to be very well in line with > > the > > > definition you've linked to. > > > > 4880bis defines a chunking mechanism based on AEAD: the message is > > split into multiple chunks. In 4880bis, AEAD operates on a per-chunk > > basis. The chunking algorithm provides mechanisms for ensuring chunks > > can't be reordered, detecting the end of the message, etc. Using AEAD > > to decrypt a chunk authenticates that chunk's ciphertext; for a given > > chunk, the decryption operation will either return the correct > > plaintext, or it will return an error. This is exactly what RFC 5116 > > requires. > I beg to differ. Because, as you mention: > > > RFC 5116 doesn't discuss chunking; chunking is not AEAD. > > > Chunking is not AEAD. It's a protocol on top of AEAD messages that you > have to come up with. And then you have to implement it correctly. The > security guarantees that AEAD gives you, do not automatically apply to > your chunking scheme. > As you've said: Chunking is not AEAD. Hence, it cannot automatically be > in line with what RFC5116 demands. The chunks use AEAD. So 5116 applies to the chunks. That means, for a given chunk, either authenticated plaintext is returned or failure. I don't see a contradiction. > > You seem to think that AEAD's guarantees must apply to the whole > > message. I disagree. > I'm glad you're saying this. > And yes, I think that proper AE means that the full message enjoys the > security guarantees of AE. Also because I am not aware of definitions > covering partially authenticated plaintext. TLS is used by a few billion people. Let's just do what they do... > And I think that RFC5116 > leans more towards full messages rather than trying to define security > guarantees for partial plaintext. RFC 5116 only talks about AEAD. But these trade-offs are specifically addressed by David McGrew, the author of 5116, here: https://mailarchive.ietf.org/arch/msg/cfrg/_iVbSmVLW7nY82k8xZmuVFIX6cs Fragmenting the plaintexts before applying AEAD requires that each AEAD message be independently authenticated, and thus this technique has more data/encapsulation overhead. In his terminology, fragmentation is approximately the same as chunking in our terminology. It seems to me, the he says AEAD is applied to fragments/chunks, not the whole message, which is the terminology that I've been using. The whole thread, starting here, https://mailarchive.ietf.org/arch/msg/cfrg/-lj3IEm9agpfgUOb2yX9JNrtrm8 is an interesting read. And, I think it generally supports my position. > I further think getting as close to > proper AE as possible is a goal worth pursuing. I think that if we accept your position, OpenPGP will have less practical security. You've repeatedly said that if an implementation doesn't want authenticated plaintext, it is free to release unauthenticated plaintext (e.g., "you are free to release unauthenticated plaintext as much as you want", 734216a3ee1c0e252ecf0ad297be2cfdcb049c2e.camel@cryptobitch.de). That's much, much worse than a possible truncation attack. And, David McGrew agrees: https://mailarchive.ietf.org/arch/msg/cfrg/_iVbSmVLW7nY82k8xZmuVFIX6cs robustness against decryption misuse is a valuable property for an AEAD algorithm to have. Nonetheless, it would be better if the protocol using AEAD actually performed some sort of plaintext fragmentation, if it can accommodate the overhead, because the security would be better. > > I agree it is useful, but it is not possible > > when streaming. > If you absolutely must stream, then there is no way that you can buffer > the whole message, otherwise you wouldn't stream. I claim, however, > that in the vast majority of use-cases you don't have the requirement of > having to stream. As in, purely from a functional perspective, not from > an implementation perspective. Hence, imposing the concept of streaming > onto everybody somehow does not feel right. Let's consider email, which is a common use case for OpenPGP. I like that K-9 just downloads the first few kilobytes of each message. I want K-9 to be able to continue to do that even when everyone is encrypting their email. For that, I need an authenticated prefix. Likewise, with a dropbox-like application, I'd like to be able to preview the content. Again, I need an authenticated prefix. I want to be able to stream archives and backups. Pretty much the only case that I can think of that chunking is not useful is for verifying software updates. > I'd like to note, though, that it is possible to not reveal the > plaintext no matter how large the message is, though. You can mask the > output you release, e.g. XOR it or apply CTR mode, and provide the key > to remove the mask only when the ciphertext has checked out correctly. I don't see how that helps with streaming. Basically any further processing needs to wait until the whole message has been decrypted a second time... > From the proposal you made it seem you think we should not even try to > provide a format for a non-streaming message. Would you describe that > as correct? We should provide exactly one variant. Additional variants must justify their existence, and I don't see the huge value add for "proper AEAD". In fact, it seems dangerous as I think it will encourage decryption misuse. > > I think that even if we add a bit that says: "don't stream", > > implementations will ignore it. > Hm. I'd classify this as a wilful violation of the spec rather than an > accident while implementing it. > Once you assume that implementations are doing things wilfully wrongly, > it gets messy. > I mean... where do we stop making compromises in the security of the > spec because we believe someone will wilfully ignore the spec? We rely > on the client not actively misinterpreting the spec. Like.. not making > secret key material available. It's a simple question of: "can I use the software to get my work done"? If the security is in the way, then the security will be disabled. "Proper AEAD" will be in the way often enough that it will get disabled, and decrease the security of the whole system. Sorry, Neal From nobody Mon Mar 18 14:11:47 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0B512EB11 for ; Mon, 18 Mar 2019 14:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=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 5vgl64de4Cqr for ; Mon, 18 Mar 2019 14:11:42 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9E0A12D4E6 for ; Mon, 18 Mar 2019 14:11:42 -0700 (PDT) Received: from [47.143.125.151] (helo=Williams-MacBook-Pro.local) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1h5zXp-0009td-CJ for openpgp@ietf.org; Mon, 18 Mar 2019 17:11:41 -0400 Date: Mon, 18 Mar 2019 14:11:41 -0700 From: Bill Frantz To: openpgp@ietf.org X-Priority: 3 In-Reply-To: <87o968i95v.wl-neal@walfield.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4.3 (480) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79e8723706e5625eecc08ab560e5432836350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 47.143.125.151 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 21:11:45 -0000 On 3/18/19 at 6:50 AM, neal@walfield.org (Neal H. Walfield) wrote: >If >an application wants to protect itself against truncation attacks, >then it can buffer the output, or the openpgp implementation can have >a flag. When processing streamed messages, you have already bought into=20 the idea that you may be processing early data in the message=20 before the later data has even been sent. To protect against truncation attacks you can borrow an idea=20 from the database people and not commit your changes until you=20 have a complete message. Cheers - Bill ------------------------------------------------------------------------ Bill Frantz |"Insofar as the propositions of mathematics=20 refer to 408-356-8506 | reality, they are not certain; and insofar=20 they are www.pwpconsult.com | certain, they do not refer to reality.=E2=80=9D=20 -- Einstein From nobody Mon Mar 18 14:53:52 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF271311A0 for ; Mon, 18 Mar 2019 14:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 gW-Ib-OSJoaF for ; Mon, 18 Mar 2019 14:53:49 -0700 (PDT) Received: from mail.heinecke.or.at (mail.heinecke.or.at [159.69.149.236]) by ietfa.amsl.com (Postfix) with ESMTP id CC4AE131188 for ; Mon, 18 Mar 2019 14:53:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.heinecke.or.at (Postfix) with ESMTP id 1C32B3ED45 for ; Mon, 18 Mar 2019 22:53:47 +0100 (CET) Received: from mail.heinecke.or.at ([127.0.0.1]) by localhost (mail.heinecke.or.at [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnVQW3f27k4p for ; Mon, 18 Mar 2019 22:53:45 +0100 (CET) Received: from esus.localnet (193-80-87-252.hdsl.highway.telekom.at [193.80.87.252]) (Authenticated sender: andre@heinecke.or.at) by mail.heinecke.or.at (Postfix) with ESMTPSA id 329D73E8A9 for ; Mon, 18 Mar 2019 22:53:45 +0100 (CET) From: Andre Heinecke To: openpgp@ietf.org Date: Mon, 18 Mar 2019 22:53:44 +0100 Message-ID: <18491354.eQth273D07@esus> In-Reply-To: <87mumh33nc.wl-neal@walfield.org> References: <87mumh33nc.wl-neal@walfield.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4518279.az5CKMTa4R"; micalg="pgp-sha256"; protocol="application/pgp-signature" Archived-At: Subject: [openpgp] WTF (Re: AEAD Chunk Size) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 21:53:51 -0000 --nextPart4518279.az5CKMTa4R Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hi, You know I would love to follow all discussions here but this thread feels= =20 somehow like a denial of service attack. I can't get though it. I need a tl;dr; here. Honestly. Today I saw replies in three different bran= ches=20 of this thread and I think it just got out of hand. My tl;dr; is (and I'm sure you'all will correct me if I'm wrong): 1. The AEAD chunk size in the current proposal is too variable. 2. Neal proposed using a fixed chunk size. 2.3. Some people had points that spoke against it. 3. There was a compromise offered with a smaller "variable chunk size". Then you wen't off the rails and repeatedly talked by and around each other= and=20 off topic. Here is where you lost me. This thread now has some epic (rambli= ng)=20 proportions. Can we somehow get some clear "votable" proposals out of this thread? I mean really. This stuff does not have to be so complicated as you make it= =20 out?! Just write in as few (that is a _good_ thing) words as possible what= =20 your proposal ist now. Maybe we could then vote on it or something like tha= t? "Chunk size should be between 512byte and 128MiB" does not sound so=20 complicated to me. I mean I really do not want to disrespect your efforts but I think there is= =20 valuable time of OpenPGP implementors wasted in this thread repeating=20 themselfs and I really want to move forward with 4880bis Best Regards, Andre =2D-=20 GnuPG.com - a brand of g10 Code, the GnuPG experts. g10 Code GmbH, Erkrath/Germany, AG Wuppertal HRB14459 GF Werner Koch, USt-Id DE215605608, www.g10code.com. GnuPG e.V., Rochusstr. 44, D-40479 D=FCsseldorf. VR 11482 D=FCsseldorf Vorstand: W.Koch, M.Gollowitzer, A.Heinecke. Mail: board@gnupg.org =46inanzamt D-Altstadt, St-Nr: 103/5923/1779. Tel: +49-2104-4938799 --nextPart4518279.az5CKMTa4R Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRwkxlKrbuKLRTTyRcpeOnUDLq6XAUCXJATaAAKCRApeOnUDLq6 XFfhAP9Sh5nPLNwE2ozIwboQ2GsHknsSsgqxnYufTAYBvScUOQEAnPKMWGvPPfuA PqGu6rEvgJW/2M3CF/i2ArhGl/K5ew0= =QKK+ -----END PGP SIGNATURE----- --nextPart4518279.az5CKMTa4R-- From nobody Mon Mar 18 15:04:16 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D3C1311AB for ; Mon, 18 Mar 2019 15:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 8KMDhk-VbZeL for ; Mon, 18 Mar 2019 15:04:10 -0700 (PDT) Received: from mail-yw1-f54.google.com (mail-yw1-f54.google.com [209.85.161.54]) (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 E152B1311A7 for ; Mon, 18 Mar 2019 15:04:09 -0700 (PDT) Received: by mail-yw1-f54.google.com with SMTP id e76so14230091ywa.9 for ; Mon, 18 Mar 2019 15:04:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=F/7YWqmW+Hzqz2azhiuQ2a39DJ3e5agUcMUS7c68EOw=; b=nE46sTieT6NdF/HA8se8ztQdMeqrCb+5ALVtNQEblLHrMSpdlyko0CSpT+7d4kyYjB K956UnoSYH5whV0l+kAbGM/Lc6dujEsC7cbiA4iQPBvGH5Tpwwh7YDM0lfCAmuuvSV18 B1wTcvXrWZzRZynd521kPV1RJUR8UEfG2y/ZDnNgqPLdziz0PLoREMC6m//j9z5WPjcv hHrVqTu8JjvbKxxJKjKgxO7tuGD4dw6yXV+l+5OhCkFvAkD3K5Zx8xGDRT8uzAyGhdXN NO7qyQnAYAZNb235xhj82pYTVsUx1RAA1CQmq9WAFsRX7aPHFnZ8IUjPmSiWIh5mUvK3 XKzw== X-Gm-Message-State: APjAAAXwxFsKn75KcfOqow2v4bKO0xEfdmm7iZwGEPVh4pPczG0kS5MY 8KeE8TIRHXqVkI+m8XYrP5McEr/hd7VIxIxDYPXuCw== X-Google-Smtp-Source: APXvYqzjkQsps9R0nSeSZkWMukZMWqPpKyhpPlch/iHmEEPYoCDMdoy8LzIv8awwXRRKyg7TF5g4OUPxa+VVOxkXotk= X-Received: by 2002:a25:9945:: with SMTP id n5mr16172514ybo.453.1552946648550; Mon, 18 Mar 2019 15:04:08 -0700 (PDT) MIME-Version: 1.0 References: <871s3475dy.fsf@europa.jade-hamburg.de> <96055353-B0EB-4E25-95CC-B25D9C5A0BA8@icloud.com> In-Reply-To: <96055353-B0EB-4E25-95CC-B25D9C5A0BA8@icloud.com> From: Andrey Jivsov Date: Mon, 18 Mar 2019 15:03:57 -0700 Message-ID: To: Jon Callas Cc: openpgp@ietf.org, Jon Callas Content-Type: multipart/alternative; boundary="00000000000057a90105846591c7" Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2019 22:04:15 -0000 --00000000000057a90105846591c7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with deprecation at a reasonable pace. SHOULD looks right. I would primarily like to correct what PGP Zip is. It is a TAR file with standard OpenPGP compression. The compression layer was not provided by gzip (that would not have worked in Windows environment). PGP Zip doesn't need a license / is free. Therefore, we should expect that OpenPGP compression is likely used by users of commercial PGP on Windows. In business world, many users have PGP installed because their employer wants every machine to use PGP disk, and so they get PGP Zip available to them. On Mon, Mar 18, 2019, 1:46 PM Jon Callas wrote: > I like the basic proposal. I think that deprecation is better than > banning, and consequently we ought to be doing it with SHOULDs and SHOULD > NOTs rather than MUSTs, as that=E2=80=99s banning rather than deprecating= . > > However, I want to add that implementations today can deprecate it on > their own and no changes in the standard need not be there. If an > implementation creates a key with compression preferences set to no > compression then any other implementation is bound by the standard not to > compress. I advocate this as well. As OpenPGP sits today, any implementer > can unilaterally not only deprecate, but eliminate compression. In fact, > I=E2=80=99ll go so far as to advocate that all implementers, even GnuPG o= ught to > just start making keys by default that eschew compression. More on this > below. > > My rationale for getting rid of compression is different. I think that th= e > security-based reasons in this thread are largely unconvincing and often > just not quite correct. I don=E2=80=99t want to discuss that in this thre= ad, > because I agree with the destination =E2=80=94 let=E2=80=99s move away fr= om compression, > and am afraid that if we debate the reasons for it we distract from the > result we mutually want. We should deprecate compression, but not because > of security, but because of simplicity, and in short a case of =E2=80=9Ct= hat was > then, this is now." > > OpenPGP has many things in it that are needlessly complex, and compressio= n > is one of them. (Other needless complexities include the way that packet > sizes are computed, and others.) Much of this comes from its heritage as = a > utility, and a utility that was designed for DOS and BBSes. The > considerations of networking and communications in 1991 are not at all wh= at > we should have for 2021. > > One of these differences is that zip-style compression is just not as > useful now. Obviously, the wins for compression are on things that are th= e > largest. Most of the large things we transfer today are already compresse= d, > and thus compressing them again is mostly a waste of cpu cycles. There ar= e > some file formats that have zip-style compression built in. For example, > GIF and PNG graphics are explicitly compressed. Other formats like JPEG a= re > a different sort of compression but have the same characteristic that it = is > reasonably mathematically pseudo-random and not readily compressed furthe= r. > Ditto for audio formats like MP3 and AAC, while FLAC and ALAC are like GI= F > and PNG in that they=E2=80=99re losslessly compressed. > > Today, the large things we send are media, and therefore there=E2=80=99s = no need > to compress them. The things we send that are easily compressible tend to > be smaller. > > In the cases where large files are sent that can be compressed, the best > solution is for that system to compress the file itself. Remember, > OpenPGP=E2=80=99s history comes from DOS programs on small computers and = they > didn=E2=80=99t even have a way to pipe a tar or zip command to an encrypt= ion > program. That=E2=80=99s not the case today. > > Historically, compression has been the largest share of the time it takes > to process a file with an OpenPGP implementation, and thus we are doing > something by default that burns CPU for little gain. We should stop doing > it by default. Again, the best way to do this is to create keys that have= a > compression preference of none. We can do this now. > > Over a decade ago, the PGP program had a feature of the =E2=80=9CPGP Zip= =E2=80=9D file. > This was literally nothing more than a tar file that was run through gzip= , > and then encrypted with OpenPGP without compression. PGP itself had some > nice viewers that let someone manipulate the container just as other > directory compression systems did, but any unix system could handle the > file by just decrypting with gnupg and piping that to tar. Later on, as I > remember (correct me if I=E2=80=99m wrong, Derek, or someone), we shifted= to bz2. > The same strategy can be improved as compression tools improve. > > The compression inside of OpenPGP is also hard to implement correctly. Th= e > default compression, the =E2=80=9CDEFLATE=E2=80=9D option is a modified i= mplementation of > ZIP-style programs from the era of the late 1980s. As those programs > coalesced into default (not precisely standard, merely ubiquitous) > implementations, they went in one direction and that era=E2=80=99s PGP st= ayed with > the variant. When we did RFC 2440, we added in ZLIB (RFC 1950) encryption > so that an implementation wouldn=E2=80=99t have to hack the compression s= oftware. > This is another reason to move away from compression inside OpenPGP. RFC > 4880 added in an option for BZ2 (it was the new hotness at the time), and > these days the cool kids are using 7-Zip as it's even better than bzip. T= he > best way to keep up with advances in compression is piping from a > compressor to some OpenPGP implementation, rather than continuing to chas= e > advancements. > > The underlying reality is even worse. Go look at section 5.6 of 2440, and > there are interoperability hints for working with PGP2 because it had > further limitations in it for internal table sizes. This is another reaso= n > to get rid of it for simplicity. It flat isn=E2=80=99t needed. > > Simply not having compression aids implementation, as well. A number of > years ago, I was putting together a Javascript implementation and there > were no good compression libraries at the time, so we just created keys > that said =E2=80=9Cno compression, please=E2=80=9D and ran with it. Every= implementation > can handle decoding an OpenPGP object that is not compressed, so there ar= e > fewer bits of backwards compatibility to transition away from it. > > Lastly, I=E2=80=99ll note that everything I=E2=80=99ve said here could be= applied to > banning encryption in 4880-bis, as well. I am not opposed to a ban, but I > think deprecation is better, particularly since every implementation can > just stop doing compression by default and everything will work just fine= . > Repeating myself, I even advocate this. Everyone who makes some OpenPGP > program can stop today, and likely should. I=E2=80=99ll even promote that= to > SHOULD. > > (The biggest reason against an outright ban is that there are a lot of > systems that use OpenPGP in the midst of some internal process, like movi= ng > around large, sensitive files. There are thus likely a whole lot of shell > scripts somewhere that someone=E2=80=99s got to find and change, and I wo= uldn=E2=80=99t be > surprised if something breaks if there=E2=80=99s a sudden shift. If we si= mply start > creating keys with preference of no compression, it gets maximum quick > uptake, and can even be improved with some options in gnupg.conf or > equivalent.) > > So to sum up, I completely support deprecating compression, because it > improves and simplifies the standard. Today, compression by default is of > limited benefit, and it simplifies implementation and understanding of > OpenPGP to phase it out. I am an enthusiastic supporter of implementation= s > just making the changes now, without a document change. I=E2=80=99m also = in favor > of deprecating. I=E2=80=99m not opposed to a ban, but I think it=E2=80=99= s unneeded. > > Jon > > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > --00000000000057a90105846591c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with deprecation at a reasonable pace. SHOULD loo= ks right.=C2=A0

I would primar= ily like to correct what PGP Zip is. It is a TAR file with standard OpenPGP= compression. The compression layer was not provided by gzip (that would no= t have worked in Windows environment). PGP Zip doesn't need a license = =C2=A0/ is free. Therefore, we should expect that OpenPGP compression is li= kely used by users of commercial PGP on Windows. In business world, many us= ers have PGP installed because their employer wants every machine to use PG= P disk, and so they get PGP Zip available to them.

On Mon, Mar 18, 201= 9, 1:46 PM Jon Callas <joncallas=3D40icloud.com@dmarc.ietf.org> wrote:
I like the basic proposal. I think that deprecation is be= tter than banning, and consequently we ought to be doing it with SHOULDs an= d SHOULD NOTs rather than MUSTs, as that=E2=80=99s banning rather than depr= ecating.

However, I want to add that implementations today can deprecate it on their= own and no changes in the standard need not be there. If an implementation= creates a key with compression preferences set to no compression then any = other implementation is bound by the standard not to compress. I advocate t= his as well. As OpenPGP sits today, any implementer can unilaterally not on= ly deprecate, but eliminate compression. In fact, I=E2=80=99ll go so far as= to advocate that all implementers, even GnuPG ought to just start making k= eys by default that eschew compression. More on this below.

My rationale for getting rid of compression is different. I think that the = security-based reasons in this thread are largely unconvincing and often ju= st not quite correct. I don=E2=80=99t want to discuss that in this thread, = because I agree with the destination =E2=80=94 let=E2=80=99s move away from= compression, and am afraid that if we debate the reasons for it we distrac= t from the result we mutually want. We should deprecate compression, but no= t because of security, but because of simplicity, and in short a case of = =E2=80=9Cthat was then, this is now."

OpenPGP has many things in it that are needlessly complex, and compression = is one of them. (Other needless complexities include the way that packet si= zes are computed, and others.) Much of this comes from its heritage as a ut= ility, and a utility that was designed for DOS and BBSes. The consideration= s of networking and communications in 1991 are not at all what we should ha= ve for 2021.

One of these differences is that zip-style compression is just not as usefu= l now. Obviously, the wins for compression are on things that are the large= st. Most of the large things we transfer today are already compressed, and = thus compressing them again is mostly a waste of cpu cycles. There are some= file formats that have zip-style compression built in. For example, GIF an= d PNG graphics are explicitly compressed. Other formats like JPEG are a dif= ferent sort of compression but have the same characteristic that it is reas= onably mathematically pseudo-random and not readily compressed further. Dit= to for audio formats like MP3 and AAC, while FLAC and ALAC are like GIF and= PNG in that they=E2=80=99re losslessly compressed.

Today, the large things we send are media, and therefore there=E2=80=99s no= need to compress them. The things we send that are easily compressible ten= d to be smaller.

In the cases where large files are sent that can be compressed, the best so= lution is for that system to compress the file itself. Remember, OpenPGP=E2= =80=99s history comes from DOS programs on small computers and they didn=E2= =80=99t even have a way to pipe a tar or zip command to an encryption progr= am. That=E2=80=99s not the case today.

Historically, compression has been the largest share of the time it takes t= o process a file with an OpenPGP implementation, and thus we are doing some= thing by default that burns CPU for little gain. We should stop doing it by= default. Again, the best way to do this is to create keys that have a comp= ression preference of none. We can do this now.

Over a decade ago, the PGP program had a feature of the =E2=80=9CPGP Zip=E2= =80=9D file. This was literally nothing more than a tar file that was run t= hrough gzip, and then encrypted with OpenPGP without compression. PGP itsel= f had some nice viewers that let someone manipulate the container just as o= ther directory compression systems did, but any unix system could handle th= e file by just decrypting with gnupg and piping that to tar. Later on, as I= remember (correct me if I=E2=80=99m wrong, Derek, or someone), we shifted = to bz2. The same strategy can be improved as compression tools improve.

The compression inside of OpenPGP is also hard to implement correctly. The = default compression, the =E2=80=9CDEFLATE=E2=80=9D option is a modified imp= lementation of ZIP-style programs from the era of the late 1980s. As those = programs coalesced into default (not precisely standard, merely ubiquitous)= implementations, they went in one direction and that era=E2=80=99s PGP sta= yed with the variant. When we did RFC 2440, we added in ZLIB (RFC 1950) enc= ryption so that an implementation wouldn=E2=80=99t have to hack the compres= sion software. This is another reason to move away from compression inside = OpenPGP. RFC 4880 added in an option for BZ2 (it was the new hotness at the= time), and these days the cool kids are using 7-Zip as it's even bette= r than bzip. The best way to keep up with advances in compression is piping= from a compressor to some OpenPGP implementation, rather than continuing t= o chase advancements.

The underlying reality is even worse. Go look at section 5.6 of 2440, and t= here are interoperability hints for working with PGP2 because it had furthe= r limitations in it for internal table sizes. This is another reason to get= rid of it for simplicity. It flat isn=E2=80=99t needed.

Simply not having compression aids implementation, as well. A number of yea= rs ago, I was putting together a Javascript implementation and there were n= o good compression libraries at the time, so we just created keys that said= =E2=80=9Cno compression, please=E2=80=9D and ran with it. Every implementa= tion can handle decoding an OpenPGP object that is not compressed, so there= are fewer bits of backwards compatibility to transition away from it.

Lastly, I=E2=80=99ll note that everything I=E2=80=99ve said here could be a= pplied to banning encryption in 4880-bis, as well. I am not opposed to a ba= n, but I think deprecation is better, particularly since every implementati= on can just stop doing compression by default and everything will work just= fine. Repeating myself, I even advocate this. Everyone who makes some Open= PGP program can stop today, and likely should. I=E2=80=99ll even promote th= at to SHOULD.

(The biggest reason against an outright ban is that there are a lot of syst= ems that use OpenPGP in the midst of some internal process, like moving aro= und large, sensitive files. There are thus likely a whole lot of shell scri= pts somewhere that someone=E2=80=99s got to find and change, and I wouldn= =E2=80=99t be surprised if something breaks if there=E2=80=99s a sudden shi= ft. If we simply start creating keys with preference of no compression, it = gets maximum quick uptake, and can even be improved with some options in gn= upg.conf or equivalent.)

So to sum up, I completely support deprecating compression, because it impr= oves and simplifies the standard. Today, compression by default is of limit= ed benefit, and it simplifies implementation and understanding of OpenPGP t= o phase it out. I am an enthusiastic supporter of implementations just maki= ng the changes now, without a document change. I=E2=80=99m also in favor of= deprecating. I=E2=80=99m not opposed to a ban, but I think it=E2=80=99s un= needed.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Jon


_______________________________________________
openpgp mailing list
op= enpgp@ietf.org
https://www.ietf.org/mailman/listinfo/openpg= p
--00000000000057a90105846591c7-- From nobody Mon Mar 18 17:58:00 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33168130EA7 for ; Mon, 18 Mar 2019 17:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 jzH5D_jeZRUy for ; Mon, 18 Mar 2019 17:57:56 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8610F1240D3 for ; Mon, 18 Mar 2019 17:57:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1552957075; x=1584493075; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FzhokFlCRjDIt6AcwuNnaCnDdGTOE4gD6TzdeWhMMOg=; b=RciXOmnofy27rhoBwfZctZF6f84wiMN2bM5K3Y3ZHU1M7aQYY6uUOdCx Thq73JT66wnSwQLj2iqF4MWlw7e2Vt7yJlx9fvs/1GBH/HddFtS3wjzwc 4okC62YBUcBzmzJH9OLiqcMa3EWEEXo2UN9WXXogHFgmRZMzTtshDs+Q+ I7VFJGQUWpSO4kVcoXJNvVof1rjtJ0OhL9DbibC1yb+R4h7a5oCps6XIx 0vkaObKUJEtvmV7M+5UCex201FWo2nWZmELzjXs1u8xrlxwxeSzizEBFz R/nY10yb77zKnXDHiicEJl+wtGCKdM78RenvOrJZeWY5vhYacBbslUHvE g==; X-IronPort-AV: E=Sophos;i="5.58,495,1544439600"; d="scan'208";a="52222457" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.9 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-e.UoA.auckland.ac.nz) ([10.6.3.9]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 19 Mar 2019 13:57:52 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-e.UoA.auckland.ac.nz (10.6.3.9) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 19 Mar 2019 13:57:51 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Tue, 19 Mar 2019 13:57:51 +1300 From: Peter Gutmann To: Jon Callas , "openpgp@ietf.org" CC: Jon Callas Thread-Topic: [openpgp] Deprecating compression support Thread-Index: AQHU3YM4vbELTl6DS0ip+YCblb7fpaYRAjQAgAEgQyg= Date: Tue, 19 Mar 2019 00:57:51 +0000 Message-ID: <1552957009760.34092@cs.auckland.ac.nz> References: <871s3475dy.fsf@europa.jade-hamburg.de>, <96055353-B0EB-4E25-95CC-B25D9C5A0BA8@icloud.com> In-Reply-To: <96055353-B0EB-4E25-95CC-B25D9C5A0BA8@icloud.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 00:57:58 -0000 Jon Callas writes:=0A= =0A= >One of these differences is that zip-style compression is just not as usef= ul=0A= >now. =0A= =0A= There is one situation in which PGP was at one point widely used but for wh= ich=0A= I don't have much current data (more recent than about five years ago) and= =0A= that's banking and medical EDI (so X12/HL7), where compression is a require= d=0A= feature, because you're moving potentially multi-megabyte text files via FT= P=0A= to/from mainframes over slow links.=0A= =0A= Outside of that rather specialised use, there's no reason to use compressio= n.=0A= =0A= >The compression inside of OpenPGP is also hard to implement correctly. The= =0A= >default compression, the =93DEFLATE=94 option is a modified implementation= of=0A= >ZIP-style programs from the era of the late 1980s. =0A= =0A= To give some background to this, the original PGP use LHarc because it was= =0A= sort-of free. When the first InfoZip implementations came out, Phil correc= tly=0A= guessed that it would become the universal standard based on the popularity= of=0A= MSDOS Pkzip. However, what went into PGP 2 was a pre-pre-pre-release of Zi= p,=0A= whose format didn't settle down completely until after PGP was released. I= =0A= think the only reason why deflateInit() still accepts -13 as a compression= =0A= parameter is to trigger the PGP 2-compatibility mode in the compressor.=0A= =0A= >The underlying reality is even worse. Go look at section 5.6 of 2440, and= =0A= >there are interoperability hints for working with PGP2 because it had furt= her=0A= >limitations in it for internal table sizes. =0A= =0A= That was due to 16-bit segments on the 8086, even then you had all sorts of= =0A= hacks to get things to work.=0A= =0A= Peter.=0A= From nobody Mon Mar 18 23:03:13 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834A11310C4 for ; Mon, 18 Mar 2019 23:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com 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 b_vpOFYkcHIk for ; Mon, 18 Mar 2019 23:03:09 -0700 (PDT) Received: from mr85p00im-hyfv06011401.me.com (mr85p00im-hyfv06011401.me.com [17.58.23.191]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC8B51277CE for ; Mon, 18 Mar 2019 23:03:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1552975389; bh=+EzDc0U4i859SK6cn2Hp6x3VwGLdBqYlg4vSuoO3bEQ=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=PQXKMtLIw9ZRtiFPiXdslVKEpcW9prKqORW25FqdV0Z++cJTmeQW5Rb+fKuiTy2xF CLUIBNm0wBfdlSqLCChDqgJRKJG/j5udpdmsGcupg4Rk0BxY3A0sAJ/L1269J8uATV +gVKjNvUNSDUd8QkhssepTyS6m955uTCsYsIahppDeoKcxExGB20Q+cHdhS4Jk/OgT nxaFOYoBeJYPrwYRJosoxMViQZEaueTJ7TrxZKavGJN7E98TSM8DgMti5fTWNXeGb4 gUBCezkKEZ0ZhMQARlbswnkF5DBFT9GcYQ33qytcGuWXpYXhquJN86N21dIET5WGaA 7Qr2dZg7FRlOQ== Received: from [192.168.7.69] (thing1.merrymeet.com [173.164.244.99]) by mr85p00im-hyfv06011401.me.com (Postfix) with ESMTPSA id C6315D2025E; Tue, 19 Mar 2019 06:03:08 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Jon Callas In-Reply-To: <1552957009760.34092@cs.auckland.ac.nz> Date: Mon, 18 Mar 2019 23:03:07 -0700 Cc: Jon Callas , Jon Callas , "openpgp@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <871s3475dy.fsf@europa.jade-hamburg.de> <96055353-B0EB-4E25-95CC-B25D9C5A0BA8@icloud.com> <1552957009760.34092@cs.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-19_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=2 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1903190046 Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 06:03:11 -0000 > On Mar 18, 2019, at 5:57 PM, Peter Gutmann = wrote: >=20 > Jon Callas writes: >=20 >> One of these differences is that zip-style compression is just not as = useful >> now.=20 >=20 > There is one situation in which PGP was at one point widely used but = for which > I don't have much current data (more recent than about five years ago) = and > that's banking and medical EDI (so X12/HL7), where compression is a = required > feature, because you're moving potentially multi-megabyte text files = via FTP > to/from mainframes over slow links. That=E2=80=99s precisely the use case I was thinking of when I mentioned = scripts that would be annoying to update. There=E2=80=99s likely a lot = of those still around. >=20 > Outside of that rather specialised use, there's no reason to use = compression. >=20 >> The compression inside of OpenPGP is also hard to implement = correctly. The >> default compression, the =E2=80=9CDEFLATE=E2=80=9D option is a = modified implementation of >> ZIP-style programs from the era of the late 1980s.=20 >=20 > To give some background to this, the original PGP use LHarc because it = was > sort-of free. When the first InfoZip implementations came out, Phil = correctly > guessed that it would become the universal standard based on the = popularity of > MSDOS Pkzip. However, what went into PGP 2 was a pre-pre-pre-release = of Zip, > whose format didn't settle down completely until after PGP was = released. I > think the only reason why deflateInit() still accepts -13 as a = compression > parameter is to trigger the PGP 2-compatibility mode in the = compressor. Thanks! That helps clarify the context. >=20 >> The underlying reality is even worse. Go look at section 5.6 of 2440, = and >> there are interoperability hints for working with PGP2 because it had = further >> limitations in it for internal table sizes.=20 >=20 > That was due to 16-bit segments on the 8086, even then you had all = sorts of > hacks to get things to work. Oh, I=E2=80=99m sure! There was so much cleverness and good technology in there at the time, = it=E2=80=99s just now we=E2=80=99re 28 years later, and we can move on. Jon From nobody Tue Mar 19 00:35:14 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1711311EF for ; Tue, 19 Mar 2019 00:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org 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 LbJWX47yLQXs for ; Tue, 19 Mar 2019 00:35:10 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACF3F1311EB for ; Tue, 19 Mar 2019 00:35:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=gSiHJNFmRdTeDQzkex1BJdfOMgQOBShGSvBDHOmD+Xo=; b=FFNKQmRIFZlJoU269I65gTgCU3 9e2BfDN3kTIxGYviCpmHziHBt5i/rD1tdCA9RVaFASnakW+6xOejcJse4xwD2GkwCnh6k7S6G54Jj 2JXpOpMgImm/e38q2YDGENEVkMJRPRng7wRgH2btKLAejdTG59BeAdpqQ1USlCg/WffY=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1h69HB-0004qf-Fh for ; Tue, 19 Mar 2019 08:35:09 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1h69CZ-000562-6H; Tue, 19 Mar 2019 08:30:23 +0100 From: Werner Koch To: Bill Frantz Cc: openpgp@ietf.org References: Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: Bill Frantz , openpgp@ietf.org Date: Tue, 19 Mar 2019 08:30:22 +0100 In-Reply-To: (Bill Frantz's message of "Mon, 18 Mar 2019 14:11:41 -0700") Message-ID: <87r2b348z5.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=Mahmoud_Ahmadinejad_dictionary_PPP_rhost_COSMOS_Cartel_de_Golfo_NATI"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 07:35:13 -0000 --=Mahmoud_Ahmadinejad_dictionary_PPP_rhost_COSMOS_Cartel_de_Golfo_NATI Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 18 Mar 2019 14:11, frantz@pwpconsult.com said: > To protect against truncation attacks you can borrow an idea from the > database people and not commit your changes until you have a complete > message. Right. And you need to do that anyway because authenticated encryption doesn't tell you anything about the origin of the message and thus you need to check the signature of the message after it has been completely decrypted (at least with OpenPGP and CMS). Anyone can send malicious content and AE doesn't protect against processsing such content. Salam-Shalom, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=Mahmoud_Ahmadinejad_dictionary_PPP_rhost_COSMOS_Cartel_de_Golfo_NATI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCXJCajgAKCRD/gK6dHew1 jfYiAP4khJrgi4+eFiZG6/KJoNnlxAlWyTLIH3w4YkysRy8YgwEA9QvguYpl4Gn2 w88mcv2tHITXwk69d9yQ4bkw/+pM1AM= =fCpe -----END PGP SIGNATURE----- --=Mahmoud_Ahmadinejad_dictionary_PPP_rhost_COSMOS_Cartel_de_Golfo_NATI-- From nobody Tue Mar 19 01:32:10 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A891E1311F8 for ; Tue, 19 Mar 2019 01:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 aIpzGEqvht8f for ; Tue, 19 Mar 2019 01:32:07 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 AEC931274A1 for ; Tue, 19 Mar 2019 01:32:07 -0700 (PDT) Received: from p57b22663.dip0.t-ipconnect.de ([87.178.38.99] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1h6AAG-0007Bp-R3; Tue, 19 Mar 2019 08:32:04 +0000 Date: Tue, 19 Mar 2019 09:32:04 +0100 Message-ID: <87ftrji7sr.wl-neal@walfield.org> From: "Neal H. Walfield" To: Bill Frantz , openpgp@ietf.org In-Reply-To: <87r2b348z5.fsf@wheatstone.g10code.de> References: <87r2b348z5.fsf@wheatstone.g10code.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 08:32:10 -0000 On Tue, 19 Mar 2019 08:30:22 +0100, Werner Koch wrote: > On Mon, 18 Mar 2019 14:11, frantz@pwpconsult.com said: > > > To protect against truncation attacks you can borrow an idea from the > > database people and not commit your changes until you have a complete > > message. > > Right. And you need to do that anyway because authenticated encryption > doesn't tell you anything about the origin of the message and thus you > need to check the signature of the message after it has been completely > decrypted (at least with OpenPGP and CMS). Anyone can send malicious > content and AE doesn't protect against processsing such content. I agree with you that AEAD + signed chunks is even better. But, streaming AEAD still provides a significant improvement relative to the status quo: it protects against EFAIL-style exfiltration attacks. From nobody Tue Mar 19 02:41:11 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526FB131212 for ; Tue, 19 Mar 2019 02:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=my.amazin.horse 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 pMvOEhIdOaVK for ; Tue, 19 Mar 2019 02:41:07 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B0CD130F05 for ; Tue, 19 Mar 2019 02:41:07 -0700 (PDT) Received: from localhost (dhcp229-087.wlan.rz.tu-bs.de [134.169.229.87]) by mail.mugenguild.com (Postfix) with ESMTPSA id 510F95FACB; Tue, 19 Mar 2019 10:41:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=my.amazin.horse; s=mail; t=1552988465; bh=fNMTYbFR/QhPtWk86k1tLxX5KAlqzObZeBLrUFzXGHA=; h=Date:From:To:Subject:Autocrypt:From; b=G4zTTfYAmQlazn/ZyaeHLSK5xnUjeQ7/aXkJFutVilEYMQKmUkBUHrICsQhUBD5y1 oVk97Qr4+UQJWuhlppDvXfqmq3vznQt7CllTwsnEYC/jU9q0fkao3E0ICvURjTUgq0 nBMkV5uBzvqJEqZ3TuTnJPoHvP6ejSvKGoF9qabg= Message-Id: <2RAT852LYMAQD.3U70IQJPU0VPO@my.amazin.horse> In-Reply-To: References: <871s3475dy.fsf@europa.jade-hamburg.de> <96055353-B0EB-4E25-95CC-B25D9C5A0BA8@icloud.com> Date: Tue, 19 Mar 2019 10:41:02 +0100 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Vincent Breitmoser To: Andrey Jivsov Cc: openpgp@ietf.org, Jon Callas Autocrypt: addr=look@my.amazin.horse; keydata=mQINBFAB3UABEADCyB/vbIBA3m1Bwc yjTieEMLySwYgt54EQ2hglOocdtIhqC+b05t6sLSkwx2ukxrU2cegnCBkdyF/FZ/+Et638CUEBbf 4bjplwpt2IPLazQgjkwjMuhz0OcYDpMhwimTvh3mIl+0wzpOts6mEmMw0QZdl3RXvIW+NSynOn7q mz/fAv4Htt6lv2Ka0s6R2voyi+5U7CcIqizPad5qZVn2uxmovcFreTzFt6nk37ZbbTfvA3e5F0bR RQeH3viT5XxpJF4Y76v/Ua+5N3Kd18K0sX85rD1G7cmxR2CZ5gW1X24sDqdYZdDbf10N39UIwjJH PTeuVMQqry792Ap0Etyj135YFCE0loDnZYKvy2Y1i0RuEdTUIonIHrLhe2J0bXQGbQImHIyMgB9/ lva8D+yvy2gyf2vjRhmJEEco7w9FdzP7p3PhKrUiTjRsjHw8iV8LOCFx9njZOq9mism9ZZ16tZpx 9mXOf11HcH1RtVuyyQRS/4ytQPzwshXdSDDW6Btkmo9AbZQKC54/hSyzpp3Br2T2xDH7ecnonDB/ jv8rWuKXSTbX3xWAIrNBNDcTYaNe4jkms4HF7jJE19eRlqsXMMx6Fxvrh4TtKICwJYJ3AUmXrK3X Ti/mjqYfJ1fpBn54rWs8nhSR1fuZPD+aMlcP8BDUPlNKPKtj0DGSh3/VlnnwARAQABtClWaW5jZW 50IEJyZWl0bW9zZXIgPGxvb2tAbXkuYW1hemluLmhvcnNlPokCOAQTAQIAIgUCVTNZmgIbAwYLCQ gHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQe9GDIN6t+hHcVg//aeiijNqsQ3pjbFQn3VvND7hNfJ vrVcLZ+U4kOzXPF818aVdOnDyNXyE17vBDDcvaZ730sCsZIRZJ3KhUJ+nPvdttKjUIGLARmx+pA3 Jl3IIv2uLtOb3I0TMuyfIGJVGF+q10/CeDMKVjKlmyOVrR0opkel+KEoN7VLq3Hf3zPKENO1HBgp LHeP31tlb9cgs+u4o2wLrVe9myHbuFBW7EjWbSvdz2zliwbsFeFVLMNcWrKAU0GkkiH69SgnwmXU RkhGma4L27GLtkHHufsxfbcPqPtmtCttsGZU4EmrghGUqVyDOxnn8ZqybzLrRfpin+OCIX+aHJz5 r2L8qtrP0LorNMX3Gopd26vfhNvq/wq8xk++bW1R5FmkaUhx9h+DhO2ybcg7p/E8JHc8zrWv+bb3 0o9lkrOaU8GxXrgtb1cjtbb+MxFvjm0Elw7MSZDG7sF/APFU6cwuIA9Nai/OGAUCSt/W2ecS8Zox cWWbGSEiDvjtEctkpmHjfVuGoL34966Olm41VdH+NjgoSYUJKx4Mty8DRcZxdyoXll84LvDkEEYK ZqOIACsJf8CDFvUkmhXc+moCj15Yxtj3/RslRVEiOUyrpDwB72zWcZG8YnzoyGxhcRIc/gFejO/y SI8bzCpYngeuTb5NjFG+ChGiInHbQcFeHBlaHtKi2o/B5axIO5Ag0EVDvOgQEQALJby/ztliToGE u1lslvWQUQ6teKZVUQ7hy9bM4N83G0AGLatUBHtY6PkJBe4XkIw3sK7LoFCV2W4GSt4zWp9l+kG3 /J8Ow7EFjN0F7DrCg0M0lMg9dQz9jYSoBR8skaH3BRzCq9AKIVKV94poL/G65289L7zKDHoZnnyF qbBtedYZir0SZx+kiouZ1qnmxRPaYmH2fkuiuvYEAyzLDLYM8F5gQhdZM4YVtuvSICYPet0z4CDi JX/vZmDi3AzzoEVaKeAM/0H9f9Ni547J2+8dZSllgTrA+fq0aMJVScAObIxTAQtEq0DoNBzPpVrm W10b4bmgePrAvNkifqSr5StymSBgwvoeW6GrJiyN4XhoLOadZzwgjqioR1nXw5tXtrr5sYdkZ06b 1WWHkxtu1hFTdLC7RYNxY07ytLNM+C2lplCwCwlWB7RwI9BL1Dhre4kv8uaaX2Gksaq9mDf9MSDW qQ0TJ/RAiwMGmFrzBEYI1J2Oyeshi/dqW4/OiZAukOIlxOnt6u8zU2KL6Qjxqqna0oTbS4Zv3fRd YkuUCL6CDEJdkuRAiW+Gw+lKcMjXqApEqixhaDkoB/kwtu+2gIFTzAxMfwFN1YtNc0kJZWnFkGIW MrrwTcOwAFzlFz7wn/EyMFtg+ERcqMX0+olXDwM8MODI2+BzulPuEDEteCw09hABEBAAGJAh8EGA ECAAkFAlQ7zoECGwwACgkQe9GDIN6t+hFjuQ//UQyg49f8TytUYQaBb8R0UfI+KhQFs1Nsz2z8a3 0CD1MeiHHYWdAcomVvTkg4g5LbnYHVDrj/XagY3FN/AIE97usFbsTG+rsWAOLi7N2dN2ehWZ634k MvrgyC9uTiOdkw31+B8K5MpyySgD8e6SAzRfiu06/bcQOUyJifw8Hudpj9by4uyGhSH+kHu4afrp OduUighbsGFtcuRwwQ/w/oSk68XvPUgiOQWMZh/pVoXdFyFvrt/hgArCi8dfy5UPK58nl7jPnu/I uQXrJ50nNAFIIxPVeo2/B83KAnEZPU+qWZsdba0V+FIIQQVizLtQFMuJJk4/UTAOfJ2tBpQ9PADX 6/scqDE7unXNWdxcHTjK7KmWjXC8CyhGOx8V/rb7Ial4mZo4cTED6SNlO7dV1XYwnSctL2HCYNM3 RUe4eJ7JWuu7/Nbf6yip2eq7BQKZ9hAH/se/OSZNYsEkZ4pxUc8W5U3uAZImUwC6L74SM0jBZIuD mQhOYX6sZZ6urIn/MYlj4/hqSBFS4vTK7nXRLmtr7+5T5U5srVseUiYc+l9pu9/XD8zGIu+M2xEd 41NwP44GDQTQm0bFljRv5fSblwmi56YHPFQUIh2RZNX3kOJgeyQ3enw5uY+7ocKRVP38hpnffliL lJcO6TtHWnElS3pACbTQM0RHJox3zqU3q6K3c= Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 09:41:10 -0000 Andrey Jivsov wrote: > I agree with deprecation at a reasonable pace. SHOULD looks right. I'm unsure why both Jon and you think we need a slower "reasonable pace", when we have not only one but two very sharp points to make this cut as clean as can be? Both AEAD and the v5 key format already break compatibility. Why pull something over the edge that we want to phase out anyways? - V From nobody Tue Mar 19 03:05:14 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9783C131228 for ; Tue, 19 Mar 2019 03:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org 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 6pxOq39C5gjy for ; Tue, 19 Mar 2019 03:05:11 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B164131227 for ; Tue, 19 Mar 2019 03:05:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=WpmjuYq1Pu63dLXT4wC91i0RbI77Dn4j0aWlh9x52p8=; b=UXvlE3H6nmWhRh530F4ffSoFVl RPOjfR34xvE4LJTm4ZtXM97kkzqk7hUxtamQIJvM4+syBc1NBGumHTYO9UW5Qn9iX353398StJRPl ias98lK084kruPqjFq/B+ECqJ0KtrVSNU7NjMoK1mqg3wczzUh1/MALcKym7Mi74+i7Y=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1h6BcL-0006RX-A4 for ; Tue, 19 Mar 2019 11:05:09 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1h6BYk-0006VH-Uk; Tue, 19 Mar 2019 11:01:26 +0100 From: Werner Koch To: "Neal H. Walfield" Cc: Bill Frantz , openpgp@ietf.org References: <87r2b348z5.fsf@wheatstone.g10code.de> <87ftrji7sr.wl-neal@walfield.org> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: "Neal H. Walfield" , Bill Frantz , openpgp@ietf.org Date: Tue, 19 Mar 2019 11:01:20 +0100 In-Reply-To: <87ftrji7sr.wl-neal@walfield.org> (Neal H. Walfield's message of "Tue, 19 Mar 2019 09:32:04 +0100") Message-ID: <87k1gv41zj.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=cdi_GEODSS_fundamentalist_genetic_kilderkin_S/Key_nitrate_AIMSX_BZ=I"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 10:05:13 -0000 --=cdi_GEODSS_fundamentalist_genetic_kilderkin_S/Key_nitrate_AIMSX_BZ=I Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 19 Mar 2019 09:32, neal@walfield.org said: > I agree with you that AEAD + signed chunks is even better. But, > streaming AEAD still provides a significant improvement relative to > the status quo: it protects against EFAIL-style exfiltration attacks. Neal: Please stop spreading false information. Our MDC already protects against this (old) kind of attack. We implemented the new AE algorithms merely for cryptographic cleanness and speed. Shalom-Salam, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=cdi_GEODSS_fundamentalist_genetic_kilderkin_S/Key_nitrate_AIMSX_BZ=I Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCXJC98QAKCRD/gK6dHew1 jXtAAQCJn0kDjsbAOiUbWG8q1pZT7hfB6dwMV59f+YODbUjmHQD+NkkxTqsYYUcv LTMBF8mI8khe+VI9HFbT3zJwbBMn7Ac= =KNbu -----END PGP SIGNATURE----- --=cdi_GEODSS_fundamentalist_genetic_kilderkin_S/Key_nitrate_AIMSX_BZ=I-- From nobody Tue Mar 19 03:09:57 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4243013121C for ; Tue, 19 Mar 2019 03:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 txn-Yd6Nu0sX for ; Tue, 19 Mar 2019 03:09:53 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 CBB3212716C for ; Tue, 19 Mar 2019 03:09:52 -0700 (PDT) Received: from p57b22663.dip0.t-ipconnect.de ([87.178.38.99] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1h6Bgr-0008JH-Sf; Tue, 19 Mar 2019 10:09:49 +0000 Date: Tue, 19 Mar 2019 11:09:49 +0100 Message-ID: <87a7hri39u.wl-neal@walfield.org> From: "Neal H. Walfield" To: "Neal H. Walfield" , Bill Frantz , openpgp@ietf.org In-Reply-To: <87k1gv41zj.fsf@wheatstone.g10code.de> References: <87r2b348z5.fsf@wheatstone.g10code.de> <87ftrji7sr.wl-neal@walfield.org> <87k1gv41zj.fsf@wheatstone.g10code.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 10:09:55 -0000 On Tue, 19 Mar 2019 11:01:20 +0100, Werner Koch wrote: > > I agree with you that AEAD + signed chunks is even better. But, > > streaming AEAD still provides a significant improvement relative to > > the status quo: it protects against EFAIL-style exfiltration attacks. > > Neal: Please stop spreading false information. Our MDC already protects > against this (old) kind of attack. We implemented the new AE algorithms > merely for cryptographic cleanness and speed. Thanks, I guess I've misunderstood the issue. Can you please explain how the MDC helps protect against ciphertext modification in the streaming case, as that it still not clear to me. Thanks! :) Neal From nobody Tue Mar 19 03:27:26 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7824131105 for ; Tue, 19 Mar 2019 03:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 QBfB2bvL3Ydj for ; Tue, 19 Mar 2019 03:27:22 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 5DB491310EE for ; Tue, 19 Mar 2019 03:27:22 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id p1so20367978wrs.8 for ; Tue, 19 Mar 2019 03:27:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:in-reply-to:references:date:message-id:mime-version; bh=7bBuAJzZRdVJqHUK1K8wsrTd304o7EEwBxCZ0SJXlq0=; b=E8EB9pra9usvbzey94pZdgDzgRvfKyZOdhdWuLctQXo6Hos5kOve6uA0i5/s+El1DL pE3VxU/868G4Z4WX0EkGDDT2+32y2K7ULtXTEODyJ4FDbxHRIM8hx5DMLjrU/hlG1c+0 Ked9tc6JJGc8y+jTu9XsWg+IYB8wrBYi996RIjNwRI3WBmxAwZM21MRmm3LSqKeujdUV W8x/+EyJc9ggKXCvRyoLrt1dGIFm33M+XP+0HZHOlUIFm57o3it4C8yay8yDfGuHOufQ RTL/mKOYHBp8Dt1ez3h7VZ7t5XLvfMQ0izoewmuX608kw+b+P62OhBLUbwGR1lkL/eMn uM/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version; bh=7bBuAJzZRdVJqHUK1K8wsrTd304o7EEwBxCZ0SJXlq0=; b=BCkoyLrilSMhW1JKkrde4sK146e6TIylENx6oyuNL05JVGVy0yO+xGYZw2FGCn6IDA c/vR5eqWMRhFlIOBBGMl/5zR/vM3CIy6Oln87Po310aOBEfhOlnKWLq8cuJ5RCDnhJHn iimkaTqTkieUff9VVgFh/GJbcPntGMUwBtcuhZL8oZfo2rfIBBzUZs8NFpdBvfGanr9h iyEcuBnCKAvfk6/6/J+mJw4AJZHYUAmQjC+umectFMbdNvWlZiiQkYaK+kn8wzUVsyQE rHU1170xY2EnqpPvDPqFQ96FH8FIu5xzqd+US9EymxsxdDbvz8OZlZ+Se9wP+HkTK1bM sehg== X-Gm-Message-State: APjAAAUJHsGMHD0xsz4xRLvN3ELO2R3iH659FNen270Ilt8waM3Q45xU AwCBuBdIbLmXfJ8NW+BuuX8d27dZ X-Google-Smtp-Source: APXvYqz9RLLPvO9NYfMw0PSKWdNwhcvhdKmA+3W6pmwVygsNGXyg1OMymDI2xTSHdQ1ZEo0JvzOzpg== X-Received: by 2002:adf:f709:: with SMTP id r9mr16273867wrp.301.1552991240961; Tue, 19 Mar 2019 03:27:20 -0700 (PDT) Received: from localhost (port-92-193-68-206.dynamic.qsc.de. [92.193.68.206]) by smtp.gmail.com with ESMTPSA id a9sm2082088wmb.30.2019.03.19.03.27.20 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 19 Mar 2019 03:27:20 -0700 (PDT) From: Justus Winter To: Vincent Breitmoser , openpgp@ietf.org In-Reply-To: <20180521200410.kxq7nj6gyki5yvhx@calamity> References: <20180305231951.GA21944@calamity> <20180521200410.kxq7nj6gyki5yvhx@calamity> Date: Tue, 19 Mar 2019 11:27:19 +0100 Message-ID: <87lg1bf9bs.fsf@europa.jade-hamburg.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Intended Recipient Fingerprint signature subpacket X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 10:27:24 -0000 --=-=-= Content-Type: text/plain Vincent Breitmoser writes: > No feedback on this at all? Should I maybe create a website and logo for > a surreptitious forwarding attack? I agree that it is a useful feature. It is implemented as proposed in Sequoia, you can designate recipients while encrypting a message, and during signature verification it constrains the validity of the signatures. > I'll add some more motivation: There is currently no way to distinguish > signatures made for plaintext messages from signatures made for encrypted > messages. > > This opens up a scenario where a message is sent as signed cleartext (which many > people do by default), and only encrypted at a later point, for example by an > inbound message encryption feature. At that point, there is no way for a mail > client to tell whether this was actually an e2e encrypted message, or sent in > the clear. > > As a straightforward fix, I propose an additional "sent in the clear" subpacket > that indicates when a signature was made over a message that is sent in the > clear, and wasn't intended to authenticate an encrypted message. I support this proposal. Thanks, Justus --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEJWpOVeSnLZetJGjniNx+MzhfeR0FAlyQxAcACgkQiNx+Mzhf eR24EAgApsa5VfQMGbsXTNDAgbog2UxMtBz3Ex6zvruYSlz1CT8kGCKrogjXtV9H dFBTlgBTEQD1MDta6Wu6pBDgkBtAKNaPgPs4vKn1zkGjE4OVOcZ1qhaLMDgYcljB BAv2QEx1MmqFIyt44hZas1wrCaYYD7CswKO8pNiR6I3jWdp6Uu0Le7HUMkobwLR9 sPArxgQM7DyS7WrCruCkWbAXfSXebZNpYT2nZ5DrjE1bLEiJsWygQ+wB3s33+bzI wwHj3ZjVbJ3ObB0yJaV0GXXp6h+q1xnsuHIeB7DYF/wDsjhP+nC5L2bLzb/YduUk CqSouZjdk1IN9xPoxLTK9/uFka8UZw== =/BhF -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Mar 19 08:21:33 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCED81313CA for ; Tue, 19 Mar 2019 08:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 HMU00danrvbn for ; Tue, 19 Mar 2019 08:21:28 -0700 (PDT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 5829B12872C for ; Tue, 19 Mar 2019 08:21:28 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id w1so15701649wrp.2 for ; Tue, 19 Mar 2019 08:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=bc8g5oJapB77UTm5eo1F2msSUHf+7/y2UCW1jB+3URc=; b=h8ktu44N2VfK16ftkdZS6af1qU6zYBsfbunN194RcRnXygrj44VEjNWX3t1VeTSQqH Ch1f98zTu58mUbkCUd1t70leZPSO7iowvszFYfUuaqp+pTzAIcUEFnKMnxGj2RofKZAw flnBghdgQ8Tv72Sj1sIPjzJb/2flmp9VYd45PRU23KZXeyeBQ0Diul2WfRZo5bQQNaaY uVCca9+LzNpYRCdnJMTuzWG97DdpvrHfN5U+yygQvbhpqpBeiKVMEA0+IAEM9++cnE1c tD0vSXcavEBhUXVgLjc9OBUAhL6D7mRUaGDVofINkpNWuXTxhWMier9Q/itQWKdHYnGF K4ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=bc8g5oJapB77UTm5eo1F2msSUHf+7/y2UCW1jB+3URc=; b=biiU8MNmIih+vX8bdquhuUJ8rBfj3JyP8gzDm8XfMffKPDCbTZRSKM8AMcYlBbfWK0 Sdbsm/+MOaxJ1h9LMQ3z9gW9r5bIprXTvCKUYsxdKse5PWyIQ64XCB2JVIbBK+LTq3fZ DhySvvBuHHbRJdgRfCn/QF545KcTL1Nqhnl1bN7FWnMSI2MGJHnRODVkm4wxC3Eu4SvN vh50CUUwoaNpMV4xqSwb5sYK9kniEcRMeD8ZIDH942Jy+Jgq4UphM+uehEO6+tgGrCLJ tFXBaTKyqaRjj92jZby79lJ0qgeHjmc/HMNhlIuduBvHoRbMDEVXbzsJaJ/qZ1C/PkOZ 4Ipg== X-Gm-Message-State: APjAAAX6xXyfigXc8eMgt7fMhNG/PgFbfst7EUEagxtv+usSyQg9wv1X MAzAnnZ6VGaBbXPqj1DTPBg= X-Google-Smtp-Source: APXvYqzSUqiW6JErK0lGhsy70ZQZJe1MUx8v6AVT21Zp9P8l92j+jGr1ys92EEyRPYlJa54TwhJJyQ== X-Received: by 2002:a5d:4606:: with SMTP id t6mr8854288wrq.43.1553008886943; Tue, 19 Mar 2019 08:21:26 -0700 (PDT) Received: from localhost (port-92-193-68-206.dynamic.qsc.de. [92.193.68.206]) by smtp.gmail.com with ESMTPSA id q24sm4691997wmq.5.2019.03.19.08.21.25 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 19 Mar 2019 08:21:26 -0700 (PDT) From: Justus Winter To: Vincent Breitmoser , Andrey Jivsov Cc: openpgp@ietf.org, Jon Callas In-Reply-To: <2RAT852LYMAQD.3U70IQJPU0VPO@my.amazin.horse> References: <871s3475dy.fsf@europa.jade-hamburg.de> <96055353-B0EB-4E25-95CC-B25D9C5A0BA8@icloud.com> <2RAT852LYMAQD.3U70IQJPU0VPO@my.amazin.horse> Date: Tue, 19 Mar 2019 16:21:24 +0100 Message-ID: <87h8bygaa3.fsf@europa.jade-hamburg.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 15:21:31 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Vincent Breitmoser writes: > Andrey Jivsov wrote: >> I agree with deprecation at a reasonable pace. SHOULD looks right. > > I'm unsure why both Jon and you think we need a slower "reasonable pace",= when > we have not only one but two very sharp points to make this cut as clean = as can > be? Both AEAD and the v5 key format already break compatibility. Why pull > something over the edge that we want to phase out anyways? Agreed. I prepared a patch: Author: Justus Winter Date: Tue Mar 19 16:11:03 2019 +0100 Deprecate compression support. =20=20=20=20 Forbid compression if encrypting a message to version 5 keys, or if AEAD is used. Discourage compression otherwise. Drop the dubious paragraph about security benefits of compression. =20=20=20=20 Motivations: =20=20=20=20 - Compression makes it impossible to reason about the size of a decrypted message, requiring the use of a streaming interface even for seemingly small messages, e.g. emails. Experience has shown that downstream users struggle with the correct use of streaming interfaces. =20=20=20=20 - Compression allows the construction of quines. =20=20=20=20 - Compression interacts badly with encryption, see e.g. CRIME, BREACH, and hiding of EFAIL-style CFB gadgets [0]. =20=20=20=20 - The downstream application is in a better position to decide whether and how to compress data that is then encrypted using OpenPGP. =20=20=20=20 - Compression make the standard more complex, and enlarges the trusted computing base of implementations. =20=20=20=20 0: Section 5.3 of https://efail.de/efail-attack-paper.pdf diff --git a/middle.mkd b/middle.mkd index 44d1246..4f88eb2 100644 =2D-- a/middle.mkd +++ b/middle.mkd @@ -129,21 +129,21 @@ and a public-key signature algorithm. The sequence i= s as follows: =20 ## Compression =20 =2DOpenPGP implementations SHOULD compress the message after applying the =2Dsignature but before encryption. +OpenPGP implementations MUST NOT compress the message if the list of +recipients includes a version 5 key, or the message is encrypted using +AEAD. + +Otherwise, OpenPGP implementations SHOULD NOT compress the message +after applying the signature but before encryption. + +For backwards compatibility, OpenPGP implementations MAY handle +compressed data packets. =20 If an implementation does not implement compression, its authors should be aware that most OpenPGP messages in the world are compressed. Thus, it may even be wise for a space-constrained implementation to implement decompression, but not compression. =20 =2DFurthermore, compression has the added side effect that some types of =2Dattacks can be thwarted by the fact that slightly altered, compressed =2Ddata rarely uncompresses without severe errors. This is hardly =2Drigorous, but it is operationally useful. These attacks can be =2Drigorously prevented by implementing and using Modification Detection =2DCodes as described in sections following. =2D ## Conversion to Radix-64 =20 OpenPGP's underlying native representation for encrypted messages, --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEJWpOVeSnLZetJGjniNx+MzhfeR0FAlyRCPQACgkQiNx+Mzhf eR2aTgf/UucN2FpFdRgoDE42J9snUc/VFJsj043DvesK2yU04cwPYGozIqRLXIst S4E2Bo8LEZI7S8bkH/QgYvAYQKv7cs3ZfcRCl73qMu4l59rwAkbn4sYC7HFLtcv1 V8udrtFw+/yXFjGqgHjoJW0q70/TYcIaAZ4F81J8tQ79FaNqDs5NyZsemzGfUkI3 EXThYICDxNTKXyuqGg2pvr4IjKIJW+ABruraTc3ambmPMTsmPoe9J5sSXcAp9llk 1xk+A4qIXyz9RCtILde7MMPRNRE+LidoSanSWFF3HC6znw4bgVpU4Y8MHPkuBW8n dCbPOKxrGOBymjkVAuIcEE2r3ns2eA== =vMx4 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Mar 19 09:24:16 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1601277DE for ; Tue, 19 Mar 2019 09:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com 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 JlAy1b3uUrjJ for ; Tue, 19 Mar 2019 09:24:12 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E49B2127A73 for ; Tue, 19 Mar 2019 09:24:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 2577EE2042; Tue, 19 Mar 2019 12:24:10 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 32294-02; Tue, 19 Mar 2019 12:24:07 -0400 (EDT) Received: from securerf.ihtfp.org (99-46-190-172.lightspeed.tukrga.sbcglobal.net [99.46.190.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 35C16E2040; Tue, 19 Mar 2019 12:23:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1553012647; bh=H6XXC9KtxVJApxLy/sihcMVVsdwTTHKa3lzJynMUps8=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=FvFMW1PU9NphN5ZiE052WpixFY/Ok6EHz6QoW8aE9ijtPHY4Jr1huOKbT2JE6BNnQ QCVe+Fxts+4SnjgC/gJqqnnLgoPoC0MXLBPcF2DS98Prq8AQRsBNaLHQyEWiL9j4Hu 0ZHCo21+bMP7a1pki6C8g0638skG1b6G/0w3MOO8= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id x2JGM3YX028641; Tue, 19 Mar 2019 12:22:03 -0400 From: Derek Atkins To: "Neal H. Walfield" Cc: openpgp@ietf.org, "Vincent Breitmoser" References: <87d0n174w6.fsf@wheatstone.g10code.de> <87mumh33nc.wl-neal@walfield.org> <3GFS71V7BTJNZ.29C5TO8OY0O44@my.amazin.horse> <87r2bax5u2.wl-neal@walfield.org> <87pnqtwot9.wl-neal@walfield.org> <87y35hy2i0.fsf@wheatstone.g10code.de> <87k1h0we7w.wl-neal@walfield.org> <87va0g65ht.fsf@wheatstone.g10code.de> <87va0gioae.wl-neal@walfield.org> <431ea8fdaca6b3d20e19cfe2a14f6c96.squirrel@mail2.ihtfp.org> <87mulsi7ms.wl-neal@walfield.org> Date: Tue, 19 Mar 2019 12:21:36 -0400 In-Reply-To: <87mulsi7ms.wl-neal@walfield.org> (Neal H. Walfield's message of "Mon, 18 Mar 2019 15:23:23 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 16:24:14 -0000 Neal, "Neal H. Walfield" writes: > Well, whatever :). As I understand Werner, he agrees that ciphertext > integrity while streaming is desirable, and, I guess, thinks that is > achievable with the current draft. I don't think it is possible, and > I've raised a few concerns in my prior mails. I hope Werner can > address those concerns. I admit that I have not studied the current draft closely, so my comments might be out of whack, but my expectation is that the AEAD and Chunking are done hand-in-hand. The chunk metadata (number/size/etc) should be protected by the AEAD. So let's say you have a message that gets processed as: [Chunk 1] [Chunk 2] [Chunk 3/final] In the normal case, the receiver will process Chunk 1, then Chunk 2, and then Chunk 3, and depending on the implementation MAY emit the Chunk 1 plaintext (which HAS BEEN AUTHENTICATED) before it processes Chunk 2 and/or Chunk 3. What can an attacker do? * If they modify the chunk size, the AEAD on that chunk will fail and therefore the data should not be emitted. Note that this COULD cause the receiver to emit Chunk 1 and then "stop". * If they cause Chunk 3 to disappear, they could get the receiver to emit Chunks 1 and 2 and then stop with. But again, Chunk1 and Chunk2 are still authenticated. * If they cause Chunk 2 to disappear, the numbering will be out of order and the receiver can emit an error. * They can insert fake chunks. Let's say they cause the following: [Chunk 1] [Chunk 2'] [Chunk 2] [Chunk 3'] [Chink 3/final] In this case, the attacker is inserting Chunk 2' and Chunk 3', claiming to be chunks 2 and 3 respectively. So the question is, what happens here? Well, the chunking here is expecting encryption (at least I think it should be expecting encryption). So they would authenticate Chunk 1 (and possibly emit it), but when processing Chunk 2' they would fail on the AEAD because the attacker doesn't know the key. The chunking should not allow any other type of data here. Am I missing another attack? [snip] >> Which implementation? The sender or the receiver? > > I'm assuming that the sender is using the best we have to offer, i.e., > chunked AEAD. > > I'm assuming that the receiver emits unauthenticated plaintext in some > situations. In what situations would the receiver emit unauthenticated plaintext? >> Also, who is the >> attacker? The Sender? Or a third party? > > I'm thinking of something like EFAIL. So, a third-party attacker who > modifies the ciphertext. EFAIL was more that that -- it was also leveraging the fact that USERS of OpenPGP would merge the contents of authenticated and non-authenticated data when presented in e.g. a MIME context, such that the processor could not differentiate between the protected and unprotected content. >> The only attack is a DoS if the end is >> truncated, and the earlier (valid) chunks have already been released. >> >> In other words, AEAD is used for each chunked block as a single, coherent >> piece. Also I don't see how an attacker (third party) could leverage this >> at all. They couldn't change the chunk size enroute. > > I hacked Sequoia to emit unauthenticated data, and I was able to > change the chunk size and still get the plaintext of at least the > first chunk of a message. So, my concern is: if a receiving > implementation releases unauthenticated plaintext for large chunks > rather than fail with ENOMEM, then a third-party attacker can change > the chunk size of an intercepted message, and cause the receiver to > process unauthenticated data, even though a small chunk size was > originally used. Sure, but the first chunk of the message was authenticated when it was emitted. The SECOND chunk failed, and I bet it stopped processing! This is what SHOULD happen. >> Each chunk is either >> authenticated, or an error occurs. On error, it wouldn't be released. > > The question for me is: what does an implementation do if it can't > buffer the message? Does it really throw an error? There already > exists at least one implementation written by an editor listed on > 4880bis that processes unauthenticated plaintext. I think we have different definitions of unauthenticated plaintext here. In a chunked message, plaintext is authenticated PER CHUNK. So once Chunk 1 is processed, it is considered authenticated, and the implementation is free to emit it, even if Chunk 2 fails. If Chunk 2 fails its AEAD check (but Chunk 1 processed successfully), do you consider the plaintext of Chunk 1 unauthenticated? If so, why? -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue Mar 19 11:10:29 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4BB31313BE for ; Tue, 19 Mar 2019 11:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 zwO_Bv9MQ-l7 for ; Tue, 19 Mar 2019 11:10:24 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 3065D131160 for ; Tue, 19 Mar 2019 11:10:24 -0700 (PDT) Received: from tmo-106-123.customers.d1-online.com ([80.187.106.123] helo=chu.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1h6JBs-0004oD-2u; Tue, 19 Mar 2019 18:10:21 +0000 Date: Tue, 19 Mar 2019 19:10:18 +0100 Message-ID: <87lg1a3fcl.wl-neal@walfield.org> From: "Neal H. Walfield" To: Derek Atkins Cc: openpgp@ietf.org, Vincent Breitmoser In-Reply-To: References: <87d0n174w6.fsf@wheatstone.g10code.de> <87mumh33nc.wl-neal@walfield.org> <3GFS71V7BTJNZ.29C5TO8OY0O44@my.amazin.horse> <87r2bax5u2.wl-neal@walfield.org> <87pnqtwot9.wl-neal@walfield.org> <87y35hy2i0.fsf@wheatstone.g10code.de> <87k1h0we7w.wl-neal@walfield.org> <87va0g65ht.fsf@wheatstone.g10code.de> <87va0gioae.wl-neal@walfield.org> <431ea8fdaca6b3d20e19cfe2a14f6c96.squirrel@mail2.ihtfp.org> <87mulsi7ms.wl-neal@walfield.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 18:10:27 -0000 Hi Derek, Thanks for your analysis. I think the AEAD chunking algorithm is sound, if it is used correctly. My issue is that I don't think it is possible to use the chunking algorithm correctly for large chunk sizes. For instance, what should an implementation do if it encounters a chunk size of 16 TB (and there really can be >16 TB of data using a small decompression bomb)? Should it be allowed to emit unauthenticated plaintext? Let's assume that we allow implementations to emit unauthenticated plaintext for large chunk sizes. An attacker who intercepts a message can change the chunk size to be above this limit. Now, clearly this will fail the authentication check, but we just allowed implementations to release the plaintext for large chunk sizes. So, if my analysis and experiments are correct, then using AEAD will never provide ciphertext integrity for the first chunk against an active attacker. Let's assume that we don't allow implementations to ever emit unauthenticated plaintext. Well, if they encounter a large chunk that they can't buffer, they MUST fail. Ouch! User's will work around that and implementations will help. (As I've pointed out, one already has. I don't know if it was an oversight.) So, my conclusion is, we must prohibit implementations from emitting unauthenticated plaintext *and* remove any incentives to do so. For me, this means a small, fixed chunk size. Does this clarify my concerns? Thanks! :) Neal At Tue, 19 Mar 2019 12:21:36 -0400, Derek Atkins wrote: > > Neal, > > "Neal H. Walfield" writes: > > > Well, whatever :). As I understand Werner, he agrees that ciphertext > > integrity while streaming is desirable, and, I guess, thinks that is > > achievable with the current draft. I don't think it is possible, and > > I've raised a few concerns in my prior mails. I hope Werner can > > address those concerns. > > I admit that I have not studied the current draft closely, so my > comments might be out of whack, but my expectation is that the AEAD and > Chunking are done hand-in-hand. The chunk metadata (number/size/etc) > should be protected by the AEAD. > > So let's say you have a message that gets processed as: > > [Chunk 1] [Chunk 2] [Chunk 3/final] > > In the normal case, the receiver will process Chunk 1, then Chunk 2, and > then Chunk 3, and depending on the implementation MAY emit the Chunk 1 > plaintext (which HAS BEEN AUTHENTICATED) before it processes Chunk 2 > and/or Chunk 3. > > What can an attacker do? > > * If they modify the chunk size, the AEAD on that chunk will fail and > therefore the data should not be emitted. Note that this COULD cause > the receiver to emit Chunk 1 and then "stop". > > * If they cause Chunk 3 to disappear, they could get the receiver to emit > Chunks 1 and 2 and then stop with. But again, Chunk1 and Chunk2 are > still authenticated. > > * If they cause Chunk 2 to disappear, the numbering will be out of order > and the receiver can emit an error. > > * They can insert fake chunks. Let's say they cause the following: > [Chunk 1] [Chunk 2'] [Chunk 2] [Chunk 3'] [Chink 3/final] > > In this case, the attacker is inserting Chunk 2' and Chunk 3', > claiming to be chunks 2 and 3 respectively. So the question is, what > happens here? Well, the chunking here is expecting encryption (at > least I think it should be expecting encryption). So they would > authenticate Chunk 1 (and possibly emit it), but when processing Chunk > 2' they would fail on the AEAD because the attacker doesn't know the > key. > > The chunking should not allow any other type of data here. > > Am I missing another attack? > > [snip] > >> Which implementation? The sender or the receiver? > > > > I'm assuming that the sender is using the best we have to offer, i.e., > > chunked AEAD. > > > > I'm assuming that the receiver emits unauthenticated plaintext in some > > situations. > > In what situations would the receiver emit unauthenticated plaintext? > > >> Also, who is the > >> attacker? The Sender? Or a third party? > > > > I'm thinking of something like EFAIL. So, a third-party attacker who > > modifies the ciphertext. > > EFAIL was more that that -- it was also leveraging the fact that USERS > of OpenPGP would merge the contents of authenticated and > non-authenticated data when presented in e.g. a MIME context, such that > the processor could not differentiate between the protected and > unprotected content. > > >> The only attack is a DoS if the end is > >> truncated, and the earlier (valid) chunks have already been released. > >> > >> In other words, AEAD is used for each chunked block as a single, coherent > >> piece. Also I don't see how an attacker (third party) could leverage this > >> at all. They couldn't change the chunk size enroute. > > > > I hacked Sequoia to emit unauthenticated data, and I was able to > > change the chunk size and still get the plaintext of at least the > > first chunk of a message. So, my concern is: if a receiving > > implementation releases unauthenticated plaintext for large chunks > > rather than fail with ENOMEM, then a third-party attacker can change > > the chunk size of an intercepted message, and cause the receiver to > > process unauthenticated data, even though a small chunk size was > > originally used. > > Sure, but the first chunk of the message was authenticated when it was > emitted. The SECOND chunk failed, and I bet it stopped processing! > > This is what SHOULD happen. > > >> Each chunk is either > >> authenticated, or an error occurs. On error, it wouldn't be released. > > > > The question for me is: what does an implementation do if it can't > > buffer the message? Does it really throw an error? There already > > exists at least one implementation written by an editor listed on > > 4880bis that processes unauthenticated plaintext. > > I think we have different definitions of unauthenticated plaintext here. > > In a chunked message, plaintext is authenticated PER CHUNK. So once > Chunk 1 is processed, it is considered authenticated, and the > implementation is free to emit it, even if Chunk 2 fails. > > If Chunk 2 fails its AEAD check (but Chunk 1 processed successfully), do > you consider the plaintext of Chunk 1 unauthenticated? If so, why? > > -derek > > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > From nobody Tue Mar 19 11:53:17 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48736131274 for ; Tue, 19 Mar 2019 11:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ruhr-uni-bochum.de 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 psBgwK0K8BZe for ; Tue, 19 Mar 2019 11:53:12 -0700 (PDT) Received: from out2.mail.ruhr-uni-bochum.de (out2.mail.ruhr-uni-bochum.de [IPv6:2a05:3e00:c:1001::8693:2ae5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CE70130EB3 for ; Tue, 19 Mar 2019 11:53:12 -0700 (PDT) Received: from mx2.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by out2.mail.ruhr-uni-bochum.de (Postfix mo-ext) with ESMTP id 44P2Hn2zWBz4xHR for ; Tue, 19 Mar 2019 19:53:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ruhr-uni-bochum.de; s=mail-2017; t=1553021589; bh=bszpCifG4R75scRjSY2ujiI2wcKrmJagPOiHt0rVBtc=; h=To:References:From:Subject:Date:In-Reply-To:From; b=LL02++HIkW2Y/0AI5di13HtM6AtRpfMObluZhrgI14aPeyUfsW1PV5Tprr4U0hUJ8 qSbtyNKn7forRf3fhnoELuOUC7aoZ0wujz6hcJ2c9mQ8lE+TsHQTy73Wa2FRrg0Aya FOvDQIUoP1CAs53sfY1RSuDl4pvZJaSV/6ZRqd7E= Received: from out2.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by mx2.mail.ruhr-uni-bochum.de (Postfix idis) with ESMTP id 44P2Hn27XJz4xMG for ; Tue, 19 Mar 2019 19:53:09 +0100 (CET) X-Envelope-Sender: X-RUB-Notes: Internal origin=134.147.42.227 Received: from mail1.mail.ruhr-uni-bochum.de (mail.ruhr-uni-bochum.de [134.147.42.227]) by out2.mail.ruhr-uni-bochum.de (Postfix mi-int) with ESMTP id 44P2Hn1jMKz4xHR for ; Tue, 19 Mar 2019 19:53:09 +0100 (CET) Received: from [10.117.4.150] (x-gn-ucopia.core.gelsen.net [217.70.175.75]) by mail1.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 44P2Hm6b1CzysC for ; Tue, 19 Mar 2019 19:53:08 +0100 (CET) To: openpgp@ietf.org References: <87d0n174w6.fsf@wheatstone.g10code.de> <87mumh33nc.wl-neal@walfield.org> <3GFS71V7BTJNZ.29C5TO8OY0O44@my.amazin.horse> <87r2bax5u2.wl-neal@walfield.org> <87pnqtwot9.wl-neal@walfield.org> <87y35hy2i0.fsf@wheatstone.g10code.de> <87k1h0we7w.wl-neal@walfield.org> <87va0g65ht.fsf@wheatstone.g10code.de> <87va0gioae.wl-neal@walfield.org> <431ea8fdaca6b3d20e19cfe2a14f6c96.squirrel@mail2.ihtfp.org> <87mulsi7ms.wl-neal@walfield.org> From: Marcus Brinkmann Openpgp: preference=signencrypt Autocrypt: addr=marcus.brinkmann@ruhr-uni-bochum.de; keydata= mQINBFZU6WABEADoVonKbB/tV0v25cm39DaSZyN7it70RhTZHLESbpDiHCwiAMi74MK/HB/q VR9LZDkTDF1x5xUnxxMHa2rpxO329dlk5dQFq1iELxIC/yBCEh5HMLT5MkWqwb8UkINYpaFU csQdPvdC2RzZ4Wt5/xX/6mvSnA4g7hSmUKwIiDX6489Fj5jHK3i0UQFnzKty3O7mqSbedTHs ym2q6fPcIlEOvU6unzxJRK4bgfW2NBM6aMqgLeQkKYIkd1Q/OXEWCXC4hQJepak+n34ChIrV RRHIBJ0GHRkEgHQgQUqPLS0fJlMYCaSZFmOAaqmigxVn1ErG3jTnFQPbPkfE5SCssFP2grNV N1ikJzOEpBLYA/4pOaJzSnZ0xx9aKPdUsyBksKmCsLQNiRt4ZTNFpJ2DJ8NbXYAFkrcu15og lrB//CVQj3CfkzUbpyfcwJHAho1K6XaPybI14znuorTJF3ml0qDd3XDkcmnF58s4hfvGHQtz +CEW+85gUF+T9jKLpwNGcNdBhbvdE6d3cSbR7dXeZsxiA4AmqqEhH6SnVmkSqmhX4+k6RksE MrHJnzefTyA4kXIR2QvD60nZXqta35VhhCzIcpkUpxcwABBR7C8nCxiGV7wNmGECgHv+Zl/O hQhWF1Ld1G93xCg7D+Nz0RerRdwtBOUatmCp+2HRTcRXNOW8jQARAQABtDZNYXJjdXMgQnJp bmttYW5uIDxtYXJjdXMuYnJpbmttYW5uQHJ1aHItdW5pLWJvY2h1bS5kZT6JAjgEEwECACIF AlZU6WACGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEIiwjVpXtiFAHDUP/0PuDwhn Cyn7b2S7Lrn0BBmi3LOS4ioalCZkV6BenkXydeGwJ9CVVix9WEbiLzCz/DHfvz97l/T9lxcM bACc1tX5a+qvqydzKd2eXFnVdH1JaihqdhG7sWYi22H1uWSyWbHd3rBZaDAts5Qialdg+WC0 kHh9pkmmlUE3BIkTaIOA9k4J93hz4QDOEO7xjB9XMOIRuasZ0lOOPraezS/pKLaQHlzPJZfo QEGL3ndn8U1FXZgR2DWhGtbClEvLaNXJ7RYhIlCeEwCwsTuGg48iDYC0+phvj/nwhZV60+Eb lR4Kux4DjY65s4Rp4kIzh51PRE+bLHtULPx1x9X1x5ZekYQdgwf6doBIIauARZFaxI6dt3i+ HSMjpga3k2Xn5iCaf6NeG1J2bh9sEAH7nntibOOp4sT8YR2SiQ5ab8PnDkydwbghUZcJ39a/ CZnN3f1RFeRX6d3zbfULPsf7o0LM/IvNKFvBoVzVb3AVYdhe5FNOE0DfhOe8lpE88ofu+es6 ECGumfR8UEcQc/O4dSyprngxZjjEdgdo5KqUkCEeGM8lVp+EFcmtLME3uqFhsUihk3YfF9Ni vZ0/0ZcLsmMp3zCZ9wS6HWr2UTkYrgc7Nr3YBClDs9W/jurcSPMmpwwhq2ycWaMMMPqULS4c U2vhGKh6JDPqfIfXFQIfhiVwCMx1uQINBFZU6WABEAC3meKoeQn4r37Z1WCvl/lRVgwYLIEw GX94WCZODxPPEy2zTWStj45yv1ZrSI0HyAqssZzXPelOFJzlM8M+iccxIMRgjnnGJJR0YqYU draf1Z2YQk/x2WjYNUg0blChdyeqwBhLAQKtnPOKkTPZBBGzPjsS+JeB8yN5r4vouFGMG+Cm YFUy4oCmcmuUrdLm9NlzM5ituyTJsPG9CDO834e4qlZsNW/yEzyPsYDW0PxJxgEe/WjLsDJ0 aiwaDhBpR8/i2FfEUTGXl+6wvdXR9lhddBoiUCVlNRu9jiKVxv2JVJepcZa9B/atJwcsDAkZ JgnjP0qRybixx/wo14KromgWVBGwpZ89sFEgZF6HcxPMKuWtieIORzs9kb0jpMFi1hW9xi60 UBHikrpDG9MnwA35d1lg/9kUlrF1nqTnyoz43UxntlgQejl6JcBR2Poaaib3ZtCR34yxslFz 4znXBermA2eEvusEmjYJlxPWozW18grbSYUr1tCmjvKZAIMrspVx37+WSm/4fy8Mq9iqhkIw eFQM10GL+fRQOGJTpSY/KiGxmkaTPtj9iaovJOcGAjUzzreGhi4toIrWWULPNKS6vuV4VgMB F4XxIcVqC9I43yzJ6/cYciwL9bxoWQ4EpHuIG3sewvOWbceeDO9j9DRSd9E6GX67NzrruDPX Ooge2QARAQABiQIfBBgBAgAJBQJWVOlgAhsMAAoJEIiwjVpXtiFAHBwP/3x5953X/1jR2Aeg R6oHSF0HAD8kMnKLP5cwLqrOzUpCwqzFGBCbYdvxrWG106jyvcZdUvtBSGd8n1FuE2WrpQrK gNjdRG65cN2kduk/w66Oq57EqSuO/r6OnadG9hgVZ1YP/QUsL6n4oF7coD0CJiH98UyLw1yP 3Em1ONX8ditvMVHNudVC1VoEN1BFjIX9VWqWoU843vPct9wKi6jLYHHAX3UpnEJtfqLHCj55 4s+0yhMhoaAIfNQZWU9iKzldM6Y0j8DJ/YBSThhw9S/TX7mClhXArJ/iPJSr6FPhlQMMcZRQ aSiQu1gDL76I5G03SkBWCnXbSpeNtTeMiSpsA58c8rpr2T4giCiV29FPgEj4We2/jBrBcwWA /XjSLE2RNOnF2G65dVxHAlaCc84lC2+bh9kVU+Tb+9YDWfHyNO+pNk/Lpaef2Kg6ScKmte6+ wVkWQZFTU8mgkHZqFvQk29RnV02phRTM0ryvWWldNgf3vzztS3iyD3GrJCPcxjm24cAflp+7 JfQ4qV/ec598k++HI4r3SfmSFKFcsxh+073p+oVjs5kIHxM0SExdjKewLOE3BKQYjn1r17xW XogKlIGbTEluQ4Odyh4n88/iA8ZLNPKjvjno7UuwBsZyJxdaTOXlQYt+ZRZNfIBSWqv0U9fY tp9qPuy4vCfkycCucIgO Message-ID: <2bc41b4b-c382-05cb-269d-d7e5babad388@ruhr-uni-bochum.de> Date: Tue, 19 Mar 2019 19:53:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.4 at mail1.mail.ruhr-uni-bochum.de X-Virus-Status: Clean Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 18:53:15 -0000 On 3/19/19 5:21 PM, Derek Atkins wrote: > In what situations would the receiver emit unauthenticated plaintext? (Neal will probably respond, but let me just state that the current implementation in GnuPG actually manages the output buffer asynchronously from AEAD chunk processing, so that it will emit plaintext from unauthenticated, partially processed chunks.) >>> Also, who is the >>> attacker? The Sender? Or a third party? >> >> I'm thinking of something like EFAIL. So, a third-party attacker who >> modifies the ciphertext. > > EFAIL was more that that -- it was also leveraging the fact that USERS > of OpenPGP would merge the contents of authenticated and > non-authenticated data when presented in e.g. a MIME context, such that > the processor could not differentiate between the protected and > unprotected content. That's true for some variants of the EFAIL attack (direct exfiltration of unmodified ciphertexts with MIME wrapping), but not for all (crypto gadgets exploiting ciphertext malleability and MDC error tolerance). Thanks, Marcus From nobody Tue Mar 19 11:58:43 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBBE11314D1 for ; Tue, 19 Mar 2019 11:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7qqPRykvocLu for ; Tue, 19 Mar 2019 11:58:30 -0700 (PDT) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 6ABD51314D3 for ; Tue, 19 Mar 2019 11:58:30 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id s15so9623wra.12 for ; Tue, 19 Mar 2019 11:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Lgo58S3D8Tp6f6IJgW/OzoKUUQd9HyL8TMUzG/eA5Mc=; b=A5aIHT+62cBS0Qdp8aCw+0hP0w8JH1Bc+7dNYVY60s5fAVTbRylEMr5nzVrzuPzupY nvqqykslVDDOdr189l+oc4OKyKDscs7T8lbMx4hymEZY4zlU9qvDFUJ9MjTfrrp0TgM9 SRz/eNLpDODNK16iBsn9PihFYq/76hHGvjBsQ1wgh0PZSwC5JJRBN3PNhFbs+Pk0bZM2 W9emlHDRthBXtm1O79c17ylJHlkAh7im5JHAh8R3qfWE9KS6D9+vPR5P9TpV8ehGS5YF tc3WG/UtHPsvxrsTUyulKqYl0ZdK32MIinniZOjl7LyiAQ1IjgUyBfPFo3fIT/gJiGAp u8Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=Lgo58S3D8Tp6f6IJgW/OzoKUUQd9HyL8TMUzG/eA5Mc=; b=g0rsFSlCsG5M2R0QKdgGzVBU5lOUN1GZx2MBriiutmzppPSpTnsupPYVMXDhiqPmKB Wbvbme6MXJ3mjEAYPUEFNqaV9tJvLDrOtkVz+Ge1YP0PdIGjVQvigwSSkChOOzSJRxgM D/EFGJBMf26/YGTjyRFGpqSQOAfixfV/uurPVyN3/CsmrbCDHSUbyTW3HjZWa5XWzo3E uDYXTguSRDROFaWR5kcr6cuZ62qdm2ASUe+tM8p7gxz8vEtN4KSN7onyebQ5YnlDxRbY cJM/O9R5kRQlWM97C7FjQTmJL8NaWoyo9gvWnRNVRtriDrM62QJqnycZ1MgSo4kCykfB ZYEg== X-Gm-Message-State: APjAAAWg6bgdCXuENvMWv5hiJbiUppOgRNIByBJIFiL5vFTIMrvxffLX hcW7y6hMVbuK7+WiaSiJNJT4BdTl X-Google-Smtp-Source: APXvYqy47VygdsrYpuhJrP45wp9cKiZ4ryfeTUEsGjFzu/0dh6+IqcVSZ97T+V9h4s/nAtyQqTMS1w== X-Received: by 2002:adf:fb82:: with SMTP id a2mr9262613wrr.214.1553021908928; Tue, 19 Mar 2019 11:58:28 -0700 (PDT) Received: from [192.168.1.11] ([134.17.139.150]) by smtp.gmail.com with ESMTPSA id t15sm9996072wrr.16.2019.03.19.11.58.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Mar 2019 11:58:28 -0700 (PDT) Sender: Nickolay Olshevsky Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Nickolay Olshevsky In-Reply-To: <87lg1a3fcl.wl-neal@walfield.org> Date: Tue, 19 Mar 2019 21:57:56 +0300 Cc: IETF OpenPGP Content-Transfer-Encoding: quoted-printable Message-Id: References: <87d0n174w6.fsf@wheatstone.g10code.de> <87mumh33nc.wl-neal@walfield.org> <3GFS71V7BTJNZ.29C5TO8OY0O44@my.amazin.horse> <87r2bax5u2.wl-neal@walfield.org> <87pnqtwot9.wl-neal@walfield.org> <87y35hy2i0.fsf@wheatstone.g10code.de> <87k1h0we7w.wl-neal@walfield.org> <87va0g65ht.fsf@wheatstone.g10code.de> <87va0gioae.wl-neal@walfield.org> <431ea8fdaca6b3d20e19cfe2a14f6c96.squirrel@mail2.ihtfp.org> <87mulsi7ms.wl-neal@walfield.org> <87lg1a3fcl.wl-neal@walfield.org> To: "Neal H. Walfield" X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 18:58:41 -0000 Hi Neal & others, Tried to follow the discussion as much as possible, but probably missed = some pages. Independent on chunk size, we get to the issue of large message = transfer, which in practice is used widely (large corporations, banks, = media companies, whatever else). The case with small chunk size and damaged last chunk is actually = (almost) the same as the case with the single large chunk - you output, = say, 20GB of data and then realize that it is broken. The same would = happen with streamed transfer of large signed objects. If you have data stored in file/memory/database you may first check it, = and then decide whether it is ok or not, spending resources on two = passes. But while streaming large amounts of data which doesn=E2=80=99t fit to = memory there is no choice - you still need to process it in smaller = blocks, without guarantee that error will not come later on. Underlying = compression or other known data structure comes in handy - it will serve = as additional layer of security (not 100% of course) for transmission = errors or transfer intervention. In any case you first output a load of data and then must discard it. So, my opinion is that we may leave things as they are, or just extend = with recommendations based on performance.=20 Given the fact that now not 100% of implementations support AEAD even = partially. > On Mar 19, 2019, at 21:10, Neal H. Walfield wrote: >=20 > Hi Derek, >=20 > Thanks for your analysis. I think the AEAD chunking algorithm is > sound, if it is used correctly. >=20 > My issue is that I don't think it is possible to use the chunking > algorithm correctly for large chunk sizes. For instance, what should > an implementation do if it encounters a chunk size of 16 TB (and there > really can be >16 TB of data using a small decompression bomb)? > Should it be allowed to emit unauthenticated plaintext? >=20 > Let's assume that we allow implementations to emit unauthenticated > plaintext for large chunk sizes. An attacker who intercepts a message > can change the chunk size to be above this limit. Now, clearly this > will fail the authentication check, but we just allowed > implementations to release the plaintext for large chunk sizes. So, > if my analysis and experiments are correct, then using AEAD will never > provide ciphertext integrity for the first chunk against an active > attacker. >=20 > Let's assume that we don't allow implementations to ever emit > unauthenticated plaintext. Well, if they encounter a large chunk that > they can't buffer, they MUST fail. Ouch! User's will work around > that and implementations will help. (As I've pointed out, one already > has. I don't know if it was an oversight.) >=20 > So, my conclusion is, we must prohibit implementations from emitting > unauthenticated plaintext *and* remove any incentives to do so. For > me, this means a small, fixed chunk size. >=20 >=20 > Does this clarify my concerns? >=20 > Thanks! >=20 > :) Neal >=20 > At Tue, 19 Mar 2019 12:21:36 -0400, > Derek Atkins wrote: >>=20 >> Neal, >>=20 >> "Neal H. Walfield" writes: >>=20 >>> Well, whatever :). As I understand Werner, he agrees that = ciphertext >>> integrity while streaming is desirable, and, I guess, thinks that is >>> achievable with the current draft. I don't think it is possible, = and >>> I've raised a few concerns in my prior mails. I hope Werner can >>> address those concerns. >>=20 >> I admit that I have not studied the current draft closely, so my >> comments might be out of whack, but my expectation is that the AEAD = and >> Chunking are done hand-in-hand. The chunk metadata (number/size/etc) >> should be protected by the AEAD. >>=20 >> So let's say you have a message that gets processed as: >>=20 >> [Chunk 1] [Chunk 2] [Chunk 3/final] >>=20 >> In the normal case, the receiver will process Chunk 1, then Chunk 2, = and >> then Chunk 3, and depending on the implementation MAY emit the Chunk = 1 >> plaintext (which HAS BEEN AUTHENTICATED) before it processes Chunk 2 >> and/or Chunk 3. >>=20 >> What can an attacker do? >>=20 >> * If they modify the chunk size, the AEAD on that chunk will fail and >> therefore the data should not be emitted. Note that this COULD = cause >> the receiver to emit Chunk 1 and then "stop". >>=20 >> * If they cause Chunk 3 to disappear, they could get the receiver to = emit >> Chunks 1 and 2 and then stop with. But again, Chunk1 and Chunk2 are >> still authenticated. >>=20 >> * If they cause Chunk 2 to disappear, the numbering will be out of = order >> and the receiver can emit an error. >>=20 >> * They can insert fake chunks. Let's say they cause the following: >> [Chunk 1] [Chunk 2'] [Chunk 2] [Chunk 3'] [Chink 3/final] >>=20 >> In this case, the attacker is inserting Chunk 2' and Chunk 3', >> claiming to be chunks 2 and 3 respectively. So the question is, = what >> happens here? Well, the chunking here is expecting encryption (at >> least I think it should be expecting encryption). So they would >> authenticate Chunk 1 (and possibly emit it), but when processing = Chunk >> 2' they would fail on the AEAD because the attacker doesn't know the >> key. >>=20 >> The chunking should not allow any other type of data here. >>=20 >> Am I missing another attack? >>=20 >> [snip] >>>> Which implementation? The sender or the receiver? >>>=20 >>> I'm assuming that the sender is using the best we have to offer, = i.e., >>> chunked AEAD. >>>=20 >>> I'm assuming that the receiver emits unauthenticated plaintext in = some >>> situations. >>=20 >> In what situations would the receiver emit unauthenticated plaintext? >>=20 >>>> Also, who is the >>>> attacker? The Sender? Or a third party? >>>=20 >>> I'm thinking of something like EFAIL. So, a third-party attacker = who >>> modifies the ciphertext. >>=20 >> EFAIL was more that that -- it was also leveraging the fact that = USERS >> of OpenPGP would merge the contents of authenticated and >> non-authenticated data when presented in e.g. a MIME context, such = that >> the processor could not differentiate between the protected and >> unprotected content. >>=20 >>>> The only attack is a DoS if the end is >>>> truncated, and the earlier (valid) chunks have already been = released. >>>>=20 >>>> In other words, AEAD is used for each chunked block as a single, = coherent >>>> piece. Also I don't see how an attacker (third party) could = leverage this >>>> at all. They couldn't change the chunk size enroute. >>>=20 >>> I hacked Sequoia to emit unauthenticated data, and I was able to >>> change the chunk size and still get the plaintext of at least the >>> first chunk of a message. So, my concern is: if a receiving >>> implementation releases unauthenticated plaintext for large chunks >>> rather than fail with ENOMEM, then a third-party attacker can change >>> the chunk size of an intercepted message, and cause the receiver to >>> process unauthenticated data, even though a small chunk size was >>> originally used. >>=20 >> Sure, but the first chunk of the message was authenticated when it = was >> emitted. The SECOND chunk failed, and I bet it stopped processing! >>=20 >> This is what SHOULD happen. >>=20 >>>> Each chunk is either >>>> authenticated, or an error occurs. On error, it wouldn't be = released. >>>=20 >>> The question for me is: what does an implementation do if it can't >>> buffer the message? Does it really throw an error? There already >>> exists at least one implementation written by an editor listed on >>> 4880bis that processes unauthenticated plaintext. >>=20 >> I think we have different definitions of unauthenticated plaintext = here. >>=20 >> In a chunked message, plaintext is authenticated PER CHUNK. So once >> Chunk 1 is processed, it is considered authenticated, and the >> implementation is free to emit it, even if Chunk 2 fails. >>=20 >> If Chunk 2 fails its AEAD check (but Chunk 1 processed successfully), = do >> you consider the plaintext of Chunk 1 unauthenticated? If so, why? >>=20 >> -derek >>=20 >> --=20 >> Derek Atkins 617-623-3745 >> derek@ihtfp.com www.ihtfp.com >> Computer and Internet Security Consultant >>=20 >> _______________________________________________ >> openpgp mailing list >> openpgp@ietf.org >> https://www.ietf.org/mailman/listinfo/openpgp >>=20 >=20 > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp From nobody Tue Mar 19 16:47:34 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C3913128B for ; Tue, 19 Mar 2019 16:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 NYBpXdaiCcEq for ; Tue, 19 Mar 2019 16:47:28 -0700 (PDT) Received: from mail.heinecke.or.at (mail.heinecke.or.at [159.69.149.236]) by ietfa.amsl.com (Postfix) with ESMTP id AF2611311C0 for ; Tue, 19 Mar 2019 16:47:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.heinecke.or.at (Postfix) with ESMTP id DD1693ED45; Wed, 20 Mar 2019 00:47:27 +0100 (CET) Received: from mail.heinecke.or.at ([127.0.0.1]) by localhost (mail.heinecke.or.at [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hBPZMgwG7_P; Wed, 20 Mar 2019 00:47:26 +0100 (CET) Received: from esus.localnet (193-80-87-252.hdsl.highway.telekom.at [193.80.87.252]) (Authenticated sender: andre@heinecke.or.at) by mail.heinecke.or.at (Postfix) with ESMTPSA id 18FC13E8A9; Wed, 20 Mar 2019 00:47:26 +0100 (CET) From: Andre Heinecke To: openpgp@ietf.org Cc: Justus Winter Date: Wed, 20 Mar 2019 00:47:25 +0100 Message-ID: <2301148.obROdnegVN@esus> In-Reply-To: <871s3475dy.fsf@europa.jade-hamburg.de> References: <871s3475dy.fsf@europa.jade-hamburg.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6266008.WZM8d6r4oB"; micalg="pgp-sha256"; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 23:47:33 -0000 --nextPart6266008.WZM8d6r4oB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hi, On Monday 18 March 2019 13:07:21 CET Justus Winter wrote: > Hello, Hello to you, too. Here is a parable: Kleopatra goes into a Bar: Kleo (linux): Hey look how small my archives are now using LZMA!! Kleo (win): Uhm LZMA is that a disease? I don't know it! KMail (linux): Ha, I have KArchive. K7Zip is the Best! GpgOl (win): Uhm 7zip, does that mean that I have to unzip it seven times? KMail (linux): No stupid, you just have to get your user to install additio= nal=20 software. GpgOL (win): Awww. shucks. I thought we were user friendly nowadays. GpgOL (win): Haha! But now! I have winrar. Kleo (linux): What? Winrar? "Win" and rar? go @!=A713 yoursellf. KMail (linux): Yeah KArchive can handle that.. *sunglasses* Enigmail (win): Eh, guys I'm a crypto plugin, what are you talking about? I= =09 can no longer decrypt your messages! What are you doing?!! Kleo (win): I can do ZIP! (Imagine Ralph Wiggum) And even in this scenario how would they even communicate which compression= =20 algos are used. Because it is _not standartized_ OpenPGP has been around for ages. Software relies on the pecularities of it. If I would have to design a cryptographic message format from scratch I=20 probably also would not include compression in there. But the existing software relies on that. We are not designing a new standa= rd.=20 We are designing an improvement on RFC4880. I don't want to rewrite major parts of KMail / GpgOL / Kleopatra with some= =20 weird unstandartized custom compression stuff. It's a part of OpenPGP. IMO = it's=20 a good part. It's nice that you guys have new ideas but we have literally millions and=20 possibly billions of users already and we have to be f'''ing rock solid in = our=20 implementations and in our standards. Best Regards, Andre =2D-=20 GnuPG.com - a brand of g10 Code, the GnuPG experts. g10 Code GmbH, Erkrath/Germany, AG Wuppertal HRB14459 GF Werner Koch, USt-Id DE215605608, www.g10code.com. --nextPart6266008.WZM8d6r4oB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRwkxlKrbuKLRTTyRcpeOnUDLq6XAUCXJF/jQAKCRApeOnUDLq6 XFJYAQDGm5j5boLrwTU5psATSHsL1sp7FO6BIuPcXg1RQIRXJQEAr4w2zj1shs8o Xl5BDXphU650YRVc4H2/npLgTZZttws= =FjvS -----END PGP SIGNATURE----- --nextPart6266008.WZM8d6r4oB-- From nobody Wed Mar 20 06:15:16 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47029127887 for ; Wed, 20 Mar 2019 06:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=my.amazin.horse 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 d-xoY0hOSGn8 for ; Wed, 20 Mar 2019 06:15:13 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAA25120106 for ; Wed, 20 Mar 2019 06:15:12 -0700 (PDT) Received: from localhost (dhcp231-163.wlan.rz.tu-bs.de [134.169.231.163]) by mail.mugenguild.com (Postfix) with ESMTPSA id 08DB75FACC; Wed, 20 Mar 2019 14:15:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=my.amazin.horse; s=mail; t=1553087711; bh=BfXHFZj50I/IJqMIB3JyP7DKWoHQ4JdmB3t61c5xcsw=; h=Date:From:To:Subject:Autocrypt:From; b=O3JPxUou3gaJ2fK65itgAgOl2sbGwlBCo4yAyJFDwiTl8Taq4Lk34ZxXpTOOiD2pZ LfTRuPWg30laUIVBju8HAl1YuQFkcCtPw6GItE4cOKg4TyhC2zBAbfJuhINNqjbWs2 zracrqHKwDtdWYuMCLFfrI+WYgRlfJei2+1JMUWg= Message-Id: <32M8VBNV00C3O.2R23SQ96PJPG3@my.amazin.horse> In-Reply-To: <2301148.obROdnegVN@esus> References: <2301148.obROdnegVN@esus> <871s3475dy.fsf@europa.jade-hamburg.de> Date: Wed, 20 Mar 2019 14:14:49 +0100 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Vincent Breitmoser To: Andre Heinecke Cc: openpgp@ietf.org, Justus Winter Autocrypt: addr=look@my.amazin.horse; keydata=mQINBFAB3UABEADCyB/vbIBA3m1Bwc yjTieEMLySwYgt54EQ2hglOocdtIhqC+b05t6sLSkwx2ukxrU2cegnCBkdyF/FZ/+Et638CUEBbf 4bjplwpt2IPLazQgjkwjMuhz0OcYDpMhwimTvh3mIl+0wzpOts6mEmMw0QZdl3RXvIW+NSynOn7q mz/fAv4Htt6lv2Ka0s6R2voyi+5U7CcIqizPad5qZVn2uxmovcFreTzFt6nk37ZbbTfvA3e5F0bR RQeH3viT5XxpJF4Y76v/Ua+5N3Kd18K0sX85rD1G7cmxR2CZ5gW1X24sDqdYZdDbf10N39UIwjJH PTeuVMQqry792Ap0Etyj135YFCE0loDnZYKvy2Y1i0RuEdTUIonIHrLhe2J0bXQGbQImHIyMgB9/ lva8D+yvy2gyf2vjRhmJEEco7w9FdzP7p3PhKrUiTjRsjHw8iV8LOCFx9njZOq9mism9ZZ16tZpx 9mXOf11HcH1RtVuyyQRS/4ytQPzwshXdSDDW6Btkmo9AbZQKC54/hSyzpp3Br2T2xDH7ecnonDB/ jv8rWuKXSTbX3xWAIrNBNDcTYaNe4jkms4HF7jJE19eRlqsXMMx6Fxvrh4TtKICwJYJ3AUmXrK3X Ti/mjqYfJ1fpBn54rWs8nhSR1fuZPD+aMlcP8BDUPlNKPKtj0DGSh3/VlnnwARAQABtClWaW5jZW 50IEJyZWl0bW9zZXIgPGxvb2tAbXkuYW1hemluLmhvcnNlPokCOAQTAQIAIgUCVTNZmgIbAwYLCQ gHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQe9GDIN6t+hHcVg//aeiijNqsQ3pjbFQn3VvND7hNfJ vrVcLZ+U4kOzXPF818aVdOnDyNXyE17vBDDcvaZ730sCsZIRZJ3KhUJ+nPvdttKjUIGLARmx+pA3 Jl3IIv2uLtOb3I0TMuyfIGJVGF+q10/CeDMKVjKlmyOVrR0opkel+KEoN7VLq3Hf3zPKENO1HBgp LHeP31tlb9cgs+u4o2wLrVe9myHbuFBW7EjWbSvdz2zliwbsFeFVLMNcWrKAU0GkkiH69SgnwmXU RkhGma4L27GLtkHHufsxfbcPqPtmtCttsGZU4EmrghGUqVyDOxnn8ZqybzLrRfpin+OCIX+aHJz5 r2L8qtrP0LorNMX3Gopd26vfhNvq/wq8xk++bW1R5FmkaUhx9h+DhO2ybcg7p/E8JHc8zrWv+bb3 0o9lkrOaU8GxXrgtb1cjtbb+MxFvjm0Elw7MSZDG7sF/APFU6cwuIA9Nai/OGAUCSt/W2ecS8Zox cWWbGSEiDvjtEctkpmHjfVuGoL34966Olm41VdH+NjgoSYUJKx4Mty8DRcZxdyoXll84LvDkEEYK ZqOIACsJf8CDFvUkmhXc+moCj15Yxtj3/RslRVEiOUyrpDwB72zWcZG8YnzoyGxhcRIc/gFejO/y SI8bzCpYngeuTb5NjFG+ChGiInHbQcFeHBlaHtKi2o/B5axIO5Ag0EVDvOgQEQALJby/ztliToGE u1lslvWQUQ6teKZVUQ7hy9bM4N83G0AGLatUBHtY6PkJBe4XkIw3sK7LoFCV2W4GSt4zWp9l+kG3 /J8Ow7EFjN0F7DrCg0M0lMg9dQz9jYSoBR8skaH3BRzCq9AKIVKV94poL/G65289L7zKDHoZnnyF qbBtedYZir0SZx+kiouZ1qnmxRPaYmH2fkuiuvYEAyzLDLYM8F5gQhdZM4YVtuvSICYPet0z4CDi JX/vZmDi3AzzoEVaKeAM/0H9f9Ni547J2+8dZSllgTrA+fq0aMJVScAObIxTAQtEq0DoNBzPpVrm W10b4bmgePrAvNkifqSr5StymSBgwvoeW6GrJiyN4XhoLOadZzwgjqioR1nXw5tXtrr5sYdkZ06b 1WWHkxtu1hFTdLC7RYNxY07ytLNM+C2lplCwCwlWB7RwI9BL1Dhre4kv8uaaX2Gksaq9mDf9MSDW qQ0TJ/RAiwMGmFrzBEYI1J2Oyeshi/dqW4/OiZAukOIlxOnt6u8zU2KL6Qjxqqna0oTbS4Zv3fRd YkuUCL6CDEJdkuRAiW+Gw+lKcMjXqApEqixhaDkoB/kwtu+2gIFTzAxMfwFN1YtNc0kJZWnFkGIW MrrwTcOwAFzlFz7wn/EyMFtg+ERcqMX0+olXDwM8MODI2+BzulPuEDEteCw09hABEBAAGJAh8EGA ECAAkFAlQ7zoECGwwACgkQe9GDIN6t+hFjuQ//UQyg49f8TytUYQaBb8R0UfI+KhQFs1Nsz2z8a3 0CD1MeiHHYWdAcomVvTkg4g5LbnYHVDrj/XagY3FN/AIE97usFbsTG+rsWAOLi7N2dN2ehWZ634k MvrgyC9uTiOdkw31+B8K5MpyySgD8e6SAzRfiu06/bcQOUyJifw8Hudpj9by4uyGhSH+kHu4afrp OduUighbsGFtcuRwwQ/w/oSk68XvPUgiOQWMZh/pVoXdFyFvrt/hgArCi8dfy5UPK58nl7jPnu/I uQXrJ50nNAFIIxPVeo2/B83KAnEZPU+qWZsdba0V+FIIQQVizLtQFMuJJk4/UTAOfJ2tBpQ9PADX 6/scqDE7unXNWdxcHTjK7KmWjXC8CyhGOx8V/rb7Ial4mZo4cTED6SNlO7dV1XYwnSctL2HCYNM3 RUe4eJ7JWuu7/Nbf6yip2eq7BQKZ9hAH/se/OSZNYsEkZ4pxUc8W5U3uAZImUwC6L74SM0jBZIuD mQhOYX6sZZ6urIn/MYlj4/hqSBFS4vTK7nXRLmtr7+5T5U5srVseUiYc+l9pu9/XD8zGIu+M2xEd 41NwP44GDQTQm0bFljRv5fSblwmi56YHPFQUIh2RZNX3kOJgeyQ3enw5uY+7ocKRVP38hpnffliL lJcO6TtHWnElS3pACbTQM0RHJox3zqU3q6K3c= Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 13:15:14 -0000 > I don't want to rewrite major parts of KMail / GpgOL / Kleopatra with some > weird unstandartized custom compression stuff. I'm confused. This thread is about deprecating compression algorithms, noone mentioned adding "custom compression stuff". Is your point that you would want to keep compression as a feature in those applications, hence removing it from OpenPGP would mean you'd have to keep it around unstandardized / on a different layer? - V From nobody Wed Mar 20 06:18:01 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6E3D127887 for ; Wed, 20 Mar 2019 06:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 7WMWlvHhQRT1 for ; Wed, 20 Mar 2019 06:17:57 -0700 (PDT) Received: from mail.heinecke.or.at (mail.heinecke.or.at [159.69.149.236]) by ietfa.amsl.com (Postfix) with ESMTP id F376A120106 for ; Wed, 20 Mar 2019 06:17:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.heinecke.or.at (Postfix) with ESMTP id 4262E3ED45; Wed, 20 Mar 2019 14:17:56 +0100 (CET) Received: from mail.heinecke.or.at ([127.0.0.1]) by localhost (mail.heinecke.or.at [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTLrXzM8weHv; Wed, 20 Mar 2019 14:17:54 +0100 (CET) Received: from esus.localnet (193-80-87-252.hdsl.highway.telekom.at [193.80.87.252]) (Authenticated sender: andre@heinecke.or.at) by mail.heinecke.or.at (Postfix) with ESMTPSA id 6AC423E8A9; Wed, 20 Mar 2019 14:17:54 +0100 (CET) From: Andre Heinecke To: openpgp@ietf.org Cc: Vincent Breitmoser , Justus Winter Date: Wed, 20 Mar 2019 14:17:53 +0100 Message-ID: <2020697.uNjeE9oTgC@esus> In-Reply-To: <32M8VBNV00C3O.2R23SQ96PJPG3@my.amazin.horse> References: <2301148.obROdnegVN@esus> <871s3475dy.fsf@europa.jade-hamburg.de> <32M8VBNV00C3O.2R23SQ96PJPG3@my.amazin.horse> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2181943.nLMjEMmTtq"; micalg="pgp-sha256"; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 13:17:59 -0000 --nextPart2181943.nLMjEMmTtq Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" On Wednesday 20 March 2019 14:14:49 CET Vincent Breitmoser wrote: > Is your point that you would want to keep compression as a feature in tho= se > applications, hence removing it from OpenPGP would mean you'd have to kee= p=20 it > around unstandardized / on a different layer? Exactly. The User Experience of Kleopatra on Windows is that you right clic= k a=20 folder and encrypt that folder. You need compression there. Currently it is standardized. You propose to remove the standard so it will= be=20 unstandartized and no longer interoperable. Regards, Andre =2D-=20 GnuPG.com - a brand of g10 Code, the GnuPG experts. g10 Code GmbH, Erkrath/Germany, AG Wuppertal HRB14459 GF Werner Koch, USt-Id DE215605608, www.g10code.com. GnuPG e.V., Rochusstr. 44, D-40479 D=FCsseldorf. VR 11482 D=FCsseldorf Vorstand: W.Koch, M.Gollowitzer, A.Heinecke. Mail: board@gnupg.org =46inanzamt D-Altstadt, St-Nr: 103/5923/1779. Tel: +49-2104-4938799 --nextPart2181943.nLMjEMmTtq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRwkxlKrbuKLRTTyRcpeOnUDLq6XAUCXJI9gQAKCRApeOnUDLq6 XMwwAQCoCTwrrYL3xI6pChol0DkU7ph63TAfvBiPtJXTWsBGjQD9FeRLNqRxQ1yw gPzG+nyMAdK4HuI158hEDX0cZYJYpAg= =XeXJ -----END PGP SIGNATURE----- --nextPart2181943.nLMjEMmTtq-- From nobody Wed Mar 20 06:24:36 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 791D7127B50 for ; Wed, 20 Mar 2019 06:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com 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 D1xy5jIUz0TB for ; Wed, 20 Mar 2019 06:24:33 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FEC0127963 for ; Wed, 20 Mar 2019 06:24:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 28F41E2044; Wed, 20 Mar 2019 09:24:31 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 20162-10; Wed, 20 Mar 2019 09:24:30 -0400 (EDT) Received: from securerf.ihtfp.org (99-46-190-172.lightspeed.tukrga.sbcglobal.net [99.46.190.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 22F4CE2040; Wed, 20 Mar 2019 09:24:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1553088270; bh=h4lAfCNHwyJLm+nabDjB560d+RvQG7CBDRO6YRoQi7c=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=PtmUykKvm52w/w+YK4s7w3i4yrkNLEYn8EkdlX9fR9JjFkmBpZZ4MDH7E8UkUghcB QKu7dWoKMevJrwuPvL+V4HvHbLW8wudqnY7AT7H5lOi0JgyX6rq8+zA9MWLrab6XER GBBzkzjeXBRTanUqZ2XiA0/Csa+ZZIjC1BZcDnoo= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id x2KDONBY008937; Wed, 20 Mar 2019 09:24:23 -0400 From: Derek Atkins To: "Neal H. Walfield" Cc: openpgp@ietf.org, Vincent Breitmoser References: <87d0n174w6.fsf@wheatstone.g10code.de> <87mumh33nc.wl-neal@walfield.org> <3GFS71V7BTJNZ.29C5TO8OY0O44@my.amazin.horse> <87r2bax5u2.wl-neal@walfield.org> <87pnqtwot9.wl-neal@walfield.org> <87y35hy2i0.fsf@wheatstone.g10code.de> <87k1h0we7w.wl-neal@walfield.org> <87va0g65ht.fsf@wheatstone.g10code.de> <87va0gioae.wl-neal@walfield.org> <431ea8fdaca6b3d20e19cfe2a14f6c96.squirrel@mail2.ihtfp.org> <87mulsi7ms.wl-neal@walfield.org> <87lg1a3fcl.wl-neal@walfield.org> Date: Wed, 20 Mar 2019 09:24:22 -0400 In-Reply-To: <87lg1a3fcl.wl-neal@walfield.org> (Neal H. Walfield's message of "Tue, 19 Mar 2019 19:10:18 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 13:24:36 -0000 Hi, "Neal H. Walfield" writes: > Hi Derek, > > Thanks for your analysis. I think the AEAD chunking algorithm is > sound, if it is used correctly. > > My issue is that I don't think it is possible to use the chunking > algorithm correctly for large chunk sizes. For instance, what should > an implementation do if it encounters a chunk size of 16 TB (and there > really can be >16 TB of data using a small decompression bomb)? > Should it be allowed to emit unauthenticated plaintext? Aha, and we have come around full circle again. The chunk size needs to be small enough that the receiver can process it. If it's too big, then it cannot be processed and the receiver either must buffer it or will decide to release the plaintext prior to the chunk being completed. [snip] > So, my conclusion is, we must prohibit implementations from emitting > unauthenticated plaintext *and* remove any incentives to do so. For > me, this means a small, fixed chunk size. There is no way to prohibit the implementation from emitting unauthenticated plaintext. Implementations will do what they want/need to do. I still don't think we need a fixed chunk size. Different use cases may dictate different ideas. It's a tradeoff, of course. The hope would be the receiver can signal to the sender what it should do. I DO believe that recommended chunk sizes should be smaller than, say 4TB (let alone exabytes). I am happy to have the range be anywhere from 1KB to 128MB (give or take), but I still don't think we should outright prohibit smaller or larger. Considering the chunk size should be part of the protected data, I don't see how an attacker could modify it, only a sender that doesn't pay attention. Specifically, if the sender and receiver have some out-of-band knowledge about each other I still think it's perfectly reasonable for them to make their own choices. > Does this clarify my concerns? I think so, and we ARE on the same page, I think. > Thanks! > > :) Neal -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Mar 20 07:40:22 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E9A130EBB for ; Wed, 20 Mar 2019 07:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org 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 zutvq7ES8xBN for ; Wed, 20 Mar 2019 07:40:11 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31231130ECE for ; Wed, 20 Mar 2019 07:40:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From: Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=DTlbCGhGi/fllur6OJBpQ7fNDkZsD8W4avhhle22rZo=; b=iIF2Eypo1uQHBJoGCFnTvh1DeR 9lECLddBlCTiPOOMF1yWD4V4B20Fs1bMVpUTSeW8nJ0ScVwO//EnACDB7ZIzOy8/aNT1eq50y5hqy gIy3lV8yEPikk/0Vledb81LDt38xewUhQDbLghndxPcJhsTaZhS46WFX4ckkf9TGTelg=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1h6cO1-0007xL-MM for ; Wed, 20 Mar 2019 15:40:09 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1h6cMo-0004SJ-6S for ; Wed, 20 Mar 2019 15:38:54 +0100 From: Werner Koch To: openpgp@ietf.org Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: openpgp@ietf.org Date: Wed, 20 Mar 2019 15:38:53 +0100 Message-ID: <87sgvh1ugy.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=Meth_Lab_Bosnia_Honduras_Osama_UHF_Fax_encryption_Chemical_burn=Al-Q"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: [openpgp] v5 sample key X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 14:40:21 -0000 --=Meth_Lab_Bosnia_Honduras_Osama_UHF_Fax_encryption_Chemical_burn=Al-Q Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi! I recently implemented v5 key support in gpg. I include a sample secret key and would be interested to see whether other implementations can parse it, verify the signatures and that the fingerprints match. The key is not protected but the dash lines are indented to stop MUAs from processing the key. Shalom-Salam, Werner =2D-8<---------------cut here---------------start------------->8--- sec ed25519 2019-03-20 [SC] 19347BC9872464025F99DF3EC2E0000ED9884892E1F7B3EA4C94009159569B54 uid emma.goldman@example.net ssb cv25519 2019-03-20 [E] E4557C2B02FFBF4B04F87401EC336AF7133D0F85BE7FD09BAEFD9CAEB8C93965 -----BEGIN PGP PRIVATE KEY BLOCK----- lGEFXJH05BYAAAAtCSsGAQQB2kcPAQEHQFhZlVcVVtwf+21xNQPX+ecMJJBL0MPd fj75iux+my8QAAAAAAAiAQCHZ1SnSUmWqxEsoI6facIVZQu6mph3cBFzzTvcm5lA Ng5ctBhlbW1hLmdvbGRtYW5AZXhhbXBsZS5uZXSIlgUTFggASCIhBRk0e8mHJGQC X5nfPsLgAA7ZiEiS4fez6kyUAJFZVptUBQJckfTkAhsDBQsJCAcCAyICAQYVCgkI CwIEFgIDAQIeBwIXgAAA9cAA/jiR3yMsZMeEQ40u6uzEoXa6UXeV/S3wwJAXRJy9 M8s0AP9vuL/7AyTfFXwwzSjDnYmzS0qAhbLDQ643N+MXGBJ2BZxmBVyR9OQSAAAA MgorBgEEAZdVAQUBAQdA+nysrzml2UCweAqtpDuncSPlvrcBWKU0yfU0YvYWWAoD AQgHAAAAAAAiAP9OdAPppjU1WwpqjIItkxr+VPQRT8Zm/Riw7U3F6v3OiBFHiHoF GBYIACwiIQUZNHvJhyRkAl+Z3z7C4AAO2YhIkuH3s+pMlACRWVabVAUCXJH05AIb DAAAOSQBAP4BOOIR/sGLNMOfeb5fPs/02QMieoiSjIBnijhob2U5AQC+RtOHCHx7 TcIYl5/Uyoi+FOvPLcNw4hOv2nwUzSSVAw=3D=3D =3DIiS2 -----END PGP PRIVATE KEY BLOCK----- =2D-8<---------------cut here---------------end--------------->8--- =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=Meth_Lab_Bosnia_Honduras_Osama_UHF_Fax_encryption_Chemical_burn=Al-Q Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCXJJQfQAKCRD/gK6dHew1 jUlkAPwIEzOMP+M1THAF3GP4NWI/OpfwBRmFbB4KX2P2SyH4TAEAskrowBmu+Zx1 qcPwzcxiz8H2vluuDGkhTE0gEp/C5AM= =n9eK -----END PGP SIGNATURE----- --=Meth_Lab_Bosnia_Honduras_Osama_UHF_Fax_encryption_Chemical_burn=Al-Q-- From nobody Wed Mar 20 07:54:09 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61FE31295D8 for ; Wed, 20 Mar 2019 07:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 xeYgUxg-cbL6 for ; Wed, 20 Mar 2019 07:54:02 -0700 (PDT) Received: from mail.heinecke.or.at (mail.heinecke.or.at [159.69.149.236]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0171310FC for ; Wed, 20 Mar 2019 07:54:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.heinecke.or.at (Postfix) with ESMTP id 406903ED45; Wed, 20 Mar 2019 15:54:00 +0100 (CET) Received: from mail.heinecke.or.at ([127.0.0.1]) by localhost (mail.heinecke.or.at [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W_TxGO9BRNnC; Wed, 20 Mar 2019 15:53:59 +0100 (CET) Received: from esus.localnet (193-80-87-252.hdsl.highway.telekom.at [193.80.87.252]) (Authenticated sender: andre@heinecke.or.at) by mail.heinecke.or.at (Postfix) with ESMTPSA id 0723F3E8A9; Wed, 20 Mar 2019 15:53:58 +0100 (CET) From: Andre Heinecke To: openpgp@ietf.org Cc: Justus Winter Date: Wed, 20 Mar 2019 15:53:58 +0100 Message-ID: <2181951.mQFCbn3PMz@esus> In-Reply-To: <871s3475dy.fsf@europa.jade-hamburg.de> References: <871s3475dy.fsf@europa.jade-hamburg.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1902347.Q2Mb2DpkOF"; micalg="pgp-sha256"; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 14:54:08 -0000 --nextPart1902347.Q2Mb2DpkOF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hi, Vincent said that my mail was too rambling. I agree. Here is the short=20 Version: * Compression is good and necessary. * Standardized compression is good. * I don't want to use unstandardized compression only because you do not wa= nt=20 to implement compression in sequoia. * There is no reason the change the standard. Compression has been around f= or=20 ages. It is _standard_ and working well. =2D---------- Here is where annoyed rambling about unproductive suggestions starts: > - Compression makes it impossible to reason about the size of a > decrypted message, requiring the use of a streaming interface even > for seemingly small messages, e.g. emails. Experience has shown > that downstream users struggle with the correct use of streaming > interfaces. Whose expericence? Not mine. It's OpenPGP and S/MIME. You have to handle th= is=20 even if you don't like it. Compression does not change this. > - Compression allows the construction of quines. Yeah that sucks. But a downstream application would still be affected. e.g.= a=20 MUA or Kleopatra if you move compresssion out of the standard. > - Compression interacts badly with encryption, see e.g. CRIME, > BREACH, and hiding of EFAIL-style CFB gadgets [0]. *rolleyes* Was OpenPGP affected? Nope. > - The downstream application is in a better position to decide whether > and how to compress data that is then encrypted using OpenPGP. Nope. Because the downstream application does not know anything about the=20 sending application because it is not standardized in you proposal. >- Compression make the standard more complex, and enlarges the > trusted computing base of implementations. Nope. Removing it makes handling it more complex because we are working wit= h a=20 well established standard. So you still need to handle old messages so you= =20 still need to handle compression. But Oh! Now you also have to handle non- standard compression. Fun! Complexity -> Increase! Regards, Andre =2D-=20 GnuPG.com - a brand of g10 Code, the GnuPG experts. g10 Code GmbH, Erkrath/Germany, AG Wuppertal HRB14459 GF Werner Koch, USt-Id DE215605608, www.g10code.com. GnuPG e.V., Rochusstr. 44, D-40479 D=FCsseldorf. VR 11482 D=FCsseldorf Vorstand: W.Koch, M.Gollowitzer, A.Heinecke. Mail: board@gnupg.org =46inanzamt D-Altstadt, St-Nr: 103/5923/1779. Tel: +49-2104-4938799 --nextPart1902347.Q2Mb2DpkOF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRwkxlKrbuKLRTTyRcpeOnUDLq6XAUCXJJUBgAKCRApeOnUDLq6 XAfGAQCtajA94qqNf8o+l0stBqXf61SCCDq2+rqwZY2FL39KGAD/bn/w+o/etCor GM02zmG7ikvMp/ZBhnAIgfs8p8tDdwg= =aX/s -----END PGP SIGNATURE----- --nextPart1902347.Q2Mb2DpkOF-- From nobody Wed Mar 20 11:18:32 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07105131160 for ; Wed, 20 Mar 2019 11:18:30 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=epointsystem-org.20150623.gappssmtp.com 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 pvmHMUU4PFPM for ; Wed, 20 Mar 2019 11:18:28 -0700 (PDT) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 2DAFC131135 for ; Wed, 20 Mar 2019 11:18:28 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id 4so188889wmf.5 for ; Wed, 20 Mar 2019 11:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epointsystem-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=GBkcIaXqXJxKgh3zGOwpoHzYPBInhOnoXXY5eqszgyw=; b=pUQ4vmjOyAkTM4aXxQSGmVu3kwfLwSzyh8AGJ3uVSsk7qfDdYQvnXcs63ateBVrDzU JLRmFOAr6YWHnoYSDIu1ysR6lhZgeSKJRvyADfOCEDilAf2bN7L1bAA9QWRvweqZQF5e FkDiZbr8YNljFMKdbWOQMx/xtl1T39kyB/VjNoBwORfW+sRpfnqEfIUBBe+gVCQsGnjZ Q6yf7moRmk0Ut7nzmWoq/4dN6S0SvGzlSO8q+2EQo305kbRbyWcpAf5HwDtGDCXNENVP xrJsUBTu18cYDVuOaQY4LNHpPqOTF++Jj4SkAnmxd+JhtQDqKhYOsvFEv+3ifXevbng6 WsCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=GBkcIaXqXJxKgh3zGOwpoHzYPBInhOnoXXY5eqszgyw=; b=o+7Wf1De8ozM/XxlvDgGfSvv26Y9djeRijBYhs+TOHC+wh0YyaZKyC3hkOPxcOK58z CvrV5jD6ghgKhcP6jIP/gtXqjP60bUwLP4tvlyVuwfeyUWN9FQZ9w4fBGe6W4XzUVjX9 1g+c/Sg2oYytnF3IjADHwcyn2dvBiCNDjZeEhxzGFQbR6GGUVkpPaEU6OctwHwtV7mZ+ beDhKZd4WlpWOXInjHwS2LvIM8HEQNwYukayKew4ZIUbqGqcL9+RaibJ8FJ/S5MZs0an MMEbyKQie0ZztFKRswwQJKSsRW9ApNTMGRicITf0ZiutZEALnBchgsTJqcDKf1Fxh6AG Ngeg== X-Gm-Message-State: APjAAAVIL12mKiqrkMX8kWEIP0EpchE64cYGazzJQ6W/pz6diVGdmW/c SVrVl9MMfawo8yhUFv1zhBNjonfSs1E= X-Google-Smtp-Source: APXvYqx9S0R6ijR28h6CQ0cnVmOdmmtnsrmRkSutyAeo55GdMPoMXEiE8W1J8Ym8svJyOfUufsMxRQ== X-Received: by 2002:a1c:9d4c:: with SMTP id g73mr9886616wme.48.1553105906245; Wed, 20 Mar 2019 11:18:26 -0700 (PDT) Received: from [192.168.5.71] (business-37-191-42-237.business.broadband.hu. [37.191.42.237]) by smtp.googlemail.com with ESMTPSA id e16sm5553389wrs.0.2019.03.20.11.18.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Mar 2019 11:18:22 -0700 (PDT) To: openpgp@ietf.org References: <871s3475dy.fsf@europa.jade-hamburg.de> <2181951.mQFCbn3PMz@esus> From: "Daniel A. Nagy" Openpgp: preference=signencrypt Autocrypt: addr=nagydani@epointsystem.org; prefer-encrypt=mutual; keydata= mQENBFTY7VQBCADH9qbwZXTQqd0l1G3dkq6GCzsa22DSPQYTeP26WybZAoz7wnUXryM1Uktv IiNF8ufXcR4c213Dksefxs9eWOgLF+6c+iIAMc5WRp/4Rj3uoszTiYF1qFxozMLmMWQi44Vq kSnA3vWeJfwDzPgh2p6qQnV2IhQ22yaFh0gKJIMMs3Ic5cj4WIm/I6TjwbuQSpiilInuJtUh hZTn1Qt7yjmVN7ahn/NNSsN4veDhpzRxVk7oNjq/OmzMzs+XYo9Ztk4EqzWq0ghK0Mc5A/+K RdHhYrMkrjRkC8gXpGIogcltq1N1m3lOFeCG1MEViPyH8/i+zkNk5vuPJ+5QXanh1rq5ABEB AAG0KkRhbmllbCBBLiBOYWd5IDxuYWd5ZGFuaUBlcG9pbnRzeXN0ZW0ub3JnPokBPgQTAQIA KAIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AFAlp6xhUFCQlkP7QACgkQgsp/Cl6lyvQI 2wf+K53F0L6bZKhC2J9CdLLBSBhGKLCiBBfZeKE4MJolWUy5zSUt8SiQboRIhqPdb9TgqVTs o+J2z0asI8lo1ZWylghqQ3j5fI4XI0SCxSgS4DXNWpfiCjDAXuXUomZuun61nCmEv1vxQkPf CVGHVt20caSawdcX1m4bQrugF1wEFfdRPMGjJqaIRXx68/gyMdYCVYHOfxohXYJRVHloNwCH aC+MQRHLk7XIWJDmFV2uFRxSmSQWiLQQ7/PxWyARP+6P706IBcwNa7TBPgwBoaDDN+yQw5jy tbs5IMLWKuiRwo5pBCv74RYrvOFi5V38TYIthft59Z/RGWvpaxmbX7O9FrkBDQRcbS7/AQgA ulcxTt8sq/WhBBSmRDrte2O4ZT4IgAoOKLz4WkJViEpbsMPkzXmoJEYIiTQPcEC+HsZrgLGb 3Ca/PXq+asKMmK3bqHWjHhqdE77kAs4BP++ljloRIK/qwv9GxWeRIBch12zqIA/G9E5irD6/ TuogXS6i2cCWibLPRsexzci7of8IJBpB8sgzUHV1AM/UWAWOTkCsQViSnh1xaVWauPXUbThs mu++ojuVSVBnNQfWpjC1Z4u7eNWe5ybYl/OMZABnhgbVHzFhFjq1VqZe7HWDTwY+gv3xwarm vgTvZt8hy3hLEnqW/HDc1wj+ar9+RtzjuXKQjZ0lulFAUpdKUPCXZwARAQABiQE8BBgBCgAm FiEE4sNk2ox2saZE0NUTgsp/Cl6lyvQFAlxtLv8CGwwFCQHhM4AACgkQgsp/Cl6lyvQ7Rwf9 GsmQ5yQk5E5PVZN3QLMR4fZILd9kxEoLeiZjOfOBvFRiKSJaMUX88bydGj0JJZze65XCFj9A dzPJP+Aw2X7X4fFq46BZ+1N+LUZjiyqyggf8Bm4SEk0Yw+NdaFOsKLFQpmRdHgvdBTmKLa5s Vp1zXCvB7TKYMciWY6WkV1cS/pReFVFvp1chTeOWHAKUVCqgw0gYg8Gh2qqaXNuG5cIeD/l2 txKC5VH7ww0ZxqvyvcQs1N9fB1yPq1QObpiOwqVkjPzgAYZekaIUrzgETsFuboRPLAsy1Xkv bn+D3vEMMTDpC735rKqcE3mpZLXKKQ1CFEK9c2BFk9ijKsj27fL5nw== Message-ID: Date: Wed, 20 Mar 2019 19:18:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <2181951.mQFCbn3PMz@esus> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LVwtTakF6EpQYaRhT2vxrb1ZdJzEr58US" Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 18:18:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LVwtTakF6EpQYaRhT2vxrb1ZdJzEr58US Content-Type: multipart/mixed; boundary="YcNDVxlzLVFoVhVNaYmDXhIZSgciAHoQN"; protected-headers="v1" From: "Daniel A. Nagy" To: openpgp@ietf.org Message-ID: Subject: Re: [openpgp] Deprecating compression support References: <871s3475dy.fsf@europa.jade-hamburg.de> <2181951.mQFCbn3PMz@esus> In-Reply-To: <2181951.mQFCbn3PMz@esus> --YcNDVxlzLVFoVhVNaYmDXhIZSgciAHoQN Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi, I strongly agree with this. Compression is a very useful safety belt making statistical cryptanalysis substantially harder even if the used cipher begins showing weakness. Cheers, Daniel On 3/20/19 3:53 PM, Andre Heinecke wrote: > Hi, >=20 > Vincent said that my mail was too rambling. I agree. Here is the short = > Version: >=20 > * Compression is good and necessary. > * Standardized compression is good. > * I don't want to use unstandardized compression only because you do no= t want=20 > to implement compression in sequoia. > * There is no reason the change the standard. Compression has been arou= nd for=20 > ages. It is _standard_ and working well. >=20 --YcNDVxlzLVFoVhVNaYmDXhIZSgciAHoQN-- --LVwtTakF6EpQYaRhT2vxrb1ZdJzEr58US Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE4sNk2ox2saZE0NUTgsp/Cl6lyvQFAlySg+0ACgkQgsp/Cl6l yvRIkwf8DRFdMERDz3n48E4lKstzC/mmMiIzfrLFS8zAjw+X6tYS63j1pIIZwp3e oSX3MPxv935zVu+NrYBg6mYbSUo4hkBRYte1zmvJHK3T0dgVsOYYX8zc4ErZWfJw vlHkQvylPmm+au3zDOHjzwtxIyivZ1PcLTTFBZwJh47PP6+Fr+OMIHII6HKe8+Eq B0XOdY36AWv5zHbCuSrp8FwaurryBcYPwQObrkfzZsAfeD2Bvix9dVP0H5ncPsyn 8HQsiYVmeUKM7HRCKAsPshLq+VzC9cW1H+ppGdSlcYV0B4nnCwdKRk1w1fV5VHdf g4eJ0poSI4MFHUqZ6ccWIxIvDx1zrA== =BSXH -----END PGP SIGNATURE----- --LVwtTakF6EpQYaRhT2vxrb1ZdJzEr58US-- From nobody Wed Mar 20 11:47:37 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EECD1200B3 for ; Wed, 20 Mar 2019 11:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com 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 Vu6BF7zXoiqh for ; Wed, 20 Mar 2019 11:47:31 -0700 (PDT) Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 890E613115F for ; Wed, 20 Mar 2019 11:47:31 -0700 (PDT) Date: Wed, 20 Mar 2019 18:47:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1553107649; bh=2o0OBgBY3B8SUhnOpHVAomWoWA4P/ruI/gEQW46BYhs=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=ktwV+W7CRu8oXNGKbx0c9Ugyjx2mCW+ET9h/cbikWOYIbIQqaWF89CQ+C/kbwfjiv Bn4yDcV3CCH8BWydnNGm1tgQJx5KnU6ODA6GI4NPrl17aO0BzKU2Em4GGCpVdgI1A4 wUiyRfCthMlHXyNnNEQEix1NYLptUH0cfQbYnNv8= To: Andre Heinecke From: Bart Butler Cc: "openpgp@ietf.org" , Justus Winter Reply-To: Bart Butler Message-ID: In-Reply-To: <2181951.mQFCbn3PMz@esus> References: <871s3475dy.fsf@europa.jade-hamburg.de> <2181951.mQFCbn3PMz@esus> Feedback-ID: XShtE-_o2KLy9dSshc6ANALRnvTQ9U24aqXW2ympbGschdpHbU6GYCTUCtfmGhY9HmOyP1Uweyandwh1AVDFrQ==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="---------------------0adde572306aa4a1b04d254010698af2"; charset=UTF-8 Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 18:47:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------0adde572306aa4a1b04d254010698af2 Content-Type: multipart/mixed;boundary=---------------------e28412cdda459dda8d66ac951d6ea15d -----------------------e28412cdda459dda8d66ac951d6ea15d Content-Transfer-Encoding: quoted-printable Content-Type: text/plain;charset=utf-8 I tend to agree with Andre. Compression still has its place. For example, = we are an email provider and receive millions of email per day, most of wh= ich are text and thus highly compressible, and due to the volume it's actu= ally an appreciable amount of storage space (read: money) that we save via= compression. There's also no BREACH/CRIME risk in this particular use cas= e and in many other use cases for PGP. >From the library perspective decompression support is certainly here to st= ay basically forever for legacy messages at the very least, so I don't see= a lot of benefit to implementation developers from dropping support eithe= r. If you have a streaming interface, you'll still need to support streami= ng decompression. One thing we could add to the compression section would be a SHOULD for ZL= IB as opposed to the legacy ZIP and bzip2, which is slow and doesn't have = much of a reason to exist in my opinion. There's no real guidance right no= w to which is preferred. I'd also be happy deprecating creation of new mes= sages with ZIP and bzip2 if we wanted to go there, though maybe someone ha= s a use case that I'm not aware of. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original M= essage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Wednesday, March 20, 2019 7:53 AM, Andre Heinecke = wrote: > Hi, > = > Vincent said that my mail was too rambling. I agree. Here is the short > Version: > = > - Compression is good and necessary. > - Standardized compression is good. > - I don't want to use unstandardized compression only because you do n= ot want > to implement compression in sequoia. > = > - There is no reason the change the standard. Compression has been aro= und for > ages. It is standard and working well. > = > = > Here is where annoyed rambling about unproductive suggestions starts: > = > > - Compression makes it impossible to reason about the size of a > > decrypted message, requiring the use of a streaming interface even > > = > = > > for seemingly small messages, e.g. emails. Experience has shown > > that downstream users struggle with the correct use of streaming > = > > interfaces. > = > Whose expericence? Not mine. It's OpenPGP and S/MIME. You have to handle= this > even if you don't like it. Compression does not change this. > = > > - Compression allows the construction of quines. > = > Yeah that sucks. But a downstream application would still be affected. e= .g. a > MUA or Kleopatra if you move compresssion out of the standard. > = > > - Compression interacts badly with encryption, see e.g. CRIME, > > BREACH, and hiding of EFAIL-style CFB gadgets [0]. > > = > = > rolleyes Was OpenPGP affected? Nope. > = > > - The downstream application is in a better position to decide wheth= er > > and how to compress data that is then encrypted using OpenPGP. > > = > = > Nope. Because the downstream application does not know anything about th= e > sending application because it is not standardized in you proposal. > = > > - Compression make the standard more complex, and enlarges the > = > > trusted computing base of implementations. > = > Nope. Removing it makes handling it more complex because we are working = with a > well established standard. So you still need to handle old messages so y= ou > still need to handle compression. But Oh! Now you also have to handle no= n- > standard compression. Fun! Complexity -> Increase! > = > Regards, > Andre > = > ----------------- > = > GnuPG.com - a brand of g10 Code, the GnuPG experts. > = > g10 Code GmbH, Erkrath/Germany, AG Wuppertal HRB14459 > GF Werner Koch, USt-Id DE215605608, www.g10code.com. > = > GnuPG e.V., Rochusstr. 44, D-40479 D=C3=BCsseldorf. VR 11482 D=C3=BCssel= dorf > Vorstand: W.Koch, M.Gollowitzer, A.Heinecke. Mail: board@gnupg.org > Finanzamt D-Altstadt, St-Nr: 103/5923/1779. Tel: +49-2104-4938799_______= ________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp -----------------------e28412cdda459dda8d66ac951d6ea15d-- -----------------------0adde572306aa4a1b04d254010698af2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail Comment: https://protonmail.com wl4EARYKAAYFAlySir4ACgkQmQVEZe8zHkRGOAD/V8GeOd/ngqgVgpBoY2T2 KmnwXblCTGo/Z0/MIxAOHmIBANq04xbxRX383fJqm3VO37VZ3gKfdm+pNBOW e5XeG8gF =xJHo -----END PGP SIGNATURE----- -----------------------0adde572306aa4a1b04d254010698af2-- From nobody Wed Mar 20 12:36:40 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A086130FC7 for ; Wed, 20 Mar 2019 12:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.45 X-Spam-Level: X-Spam-Status: No, score=-3.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com 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 tBkdJR7JgFak for ; Wed, 20 Mar 2019 12:36:36 -0700 (PDT) Received: from mr85p00im-ztdg06011101.me.com (mr85p00im-ztdg06011101.me.com [17.58.23.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABF61129508 for ; Wed, 20 Mar 2019 12:36:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1553110596; bh=sSqagz25fqHmCQWwQLoxQH45Os3tY4uNpWrKoUD4t5A=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=mF8xaR3pNHqinI8yrOJXbeCieDlEpIfBDpWD9005nKuGtMgo5P6fVA43GtbpwioDv vzFHCqB+U7vEYVJbRCDsrN08xpiUlBu5HA+pzeTFjv5GNP1QZHBSUd8zQwRICyart5 iwumysX3IelUVx9JtlE9M9x9t80Nfk3E4705reKYBszMkrS8tpJY43gUJqWJC3z8JG ABlLLB9tREZWEU/ikYbJbeQPP3wlqG5Xdpa7Wnsw2RW9xrjhJRsU6KWdNoNnsyvN+c 27udEBlOI5cd0GLzrvNLrrJQ6Cbo7StFvgocz2+M1Jz9mA0JmhyqxhH2mUC2O7mtHV Yf++TO3VrkL+A== Received: from [10.125.12.153] (67-207-120-150.static.wiline.com [67.207.120.150]) by mr85p00im-ztdg06011101.me.com (Postfix) with ESMTPSA id BC5484A0158; Wed, 20 Mar 2019 19:36:35 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Jon Callas In-Reply-To: <2RAT852LYMAQD.3U70IQJPU0VPO@my.amazin.horse> Date: Wed, 20 Mar 2019 12:36:34 -0700 Cc: Jon Callas , Andrey Jivsov , openpgp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0092256D-94EB-4FE5-9560-FEB0B8E3769E@icloud.com> References: <871s3475dy.fsf@europa.jade-hamburg.de> <96055353-B0EB-4E25-95CC-B25D9C5A0BA8@icloud.com> <2RAT852LYMAQD.3U70IQJPU0VPO@my.amazin.horse> To: Vincent Breitmoser X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-20_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1903200142 Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 19:36:38 -0000 > On Mar 19, 2019, at 2:41 AM, Vincent Breitmoser = wrote: >=20 > I'm unsure why both Jon and you think we need a slower "reasonable = pace", when > we have not only one but two very sharp points to make this cut as = clean as can > be? Both AEAD and the v5 key format already break compatibility. Why = pull > something over the edge that we want to phase out anyways? I=E2=80=99m going to quibble over =E2=80=9Ctwo=E2=80=9D and say that we = have one =E2=80=94 simplification of an overall implementation. The second one has had comments on before. I=E2=80=99ll pick up some = more in another missive relating to things people have said today. To address your point, as I said in my long missive, you can do this = today. No changes are needed to the protocol. All you have to do is put = a compression preference on your key that says no compression, and then = you won=E2=80=99t get compression. (Well, to be completely correct, if = someone compresses then they=E2=80=99re non-compliant to the standard.) = Repeating myself, I support and encourage implementations to do that by = default. Since you can do it today, there=E2=80=99s no need to rush. There are = other people who have their own legitimate needs for it. Does this make sense? Jon= From nobody Wed Mar 20 13:57:29 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C346C124BF6 for ; Wed, 20 Mar 2019 13:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com 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 adN0F98Nf4mE for ; Wed, 20 Mar 2019 13:57:24 -0700 (PDT) Received: from mr85p00im-ztdg06021801.me.com (mr85p00im-ztdg06021801.me.com [17.58.23.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C100A131288 for ; Wed, 20 Mar 2019 13:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1553115432; bh=Mc3z0RZ0zN2eo2TGwhmjqSKruLTWh+lNdBV9CLI1K+E=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=ZI8YRipsfp4/PJaHGU94n/DoNcjgYXcPJeOOJspWAR9jNPRQV51Xv49uqtvGG+UbR 4u+GhJtMbDuZ4jSjZC+Hvvw+NVXveG3SouSSzRz8IJLmr7SaI4+vni52MXNnvAViKt 8bjIVn4L2HBxPGap8sj92cWO83NqC3sPXfdzCsBWQbKsdzOyklNMMjcjWFTQpbxChZ vQndsAv0hEvqmIUkglwhV5rRbVtelP7TDxprB1+j3BLUWgSxgAAU1fgFhcdbrA0nu0 dcF75wJD0szlq5WI89jjTfeJPHVEXVXj5gCCJ3/+ChRoSaXm1RvW0BtXgQOW3iDYcU 9kSSe9/q3KizA== Received: from [10.125.12.153] (67-207-120-150.static.wiline.com [67.207.120.150]) by mr85p00im-ztdg06021801.me.com (Postfix) with ESMTPSA id 13F3D1800E5; Wed, 20 Mar 2019 20:57:11 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Jon Callas In-Reply-To: <871s3475dy.fsf@europa.jade-hamburg.de> Date: Wed, 20 Mar 2019 13:57:11 -0700 Cc: Jon Callas Content-Transfer-Encoding: quoted-printable Message-Id: <14617627-542E-4672-B83C-1B5E87561B50@icloud.com> References: <871s3475dy.fsf@europa.jade-hamburg.de> To: openpgp@ietf.org X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-20_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1903200151 Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 20:57:28 -0000 As mentioned in my previous note, I feel like I need to comment on the = security rationales, rather than the software engineering rationale. = Here=E2=80=99s what was given before. Andre Heinecke also had very good = comments. > On Mar 18, 2019, at 5:07 AM, Justus Winter = wrote: >=20 > I propose to deprecate compression support in OpenPGP. The reasons > for this are: >=20 > - Compression makes it impossible to reason about the size of a > decrypted message, requiring the use of a streaming interface even > for seemingly small messages, e.g. emails. Experience has shown > that downstream users struggle with the correct use of streaming > interfaces. What experience? References? I have a raised eyebrow on this reason because the vast majority of = every PGP message created in the last 28 years had compression on. I = don=E2=80=99t know of any problems. I don=E2=80=99t know of any = downstream uses struggling with streaming interfaces. Moreover, this is = a criticism of streaming.=20 Moreover, in the common case (an email), there are many plaintext = transformations that go on. For example, there=E2=80=99s = quoted-printable, hexadecimal expansion, base64 encoding, and lots of = other things that go on in the plaintext that make it hard to know the = length of the final plaintext. You=E2=80=99re right that it=E2=80=99s = hard to know the final length of a message, but removing compression = doesn=E2=80=99t solve the problem, nor does it make it appreciatively = better.=20 Are you suggesting that OpenPGP only allow definite lengths? To me, this seems like a non sequitur even if you back it up with = evidence.=20 >=20 > - Compression allows the construction of quines. So what? How is this a problem? Text editors allow the construction of = quines, too.=20 This is an assertion, but it doesn=E2=80=99t say how it=E2=80=99s a = problem, nor does it state how removing compression would remove the = problem.=20 My suggestion =E2=80=94 moving compression to an upper layer =E2=80=94 = also allows quines, since it allows someone to encrypt a bit string = that=E2=80=99s been compressed, and therefore might have a quine in it. >=20 > - Compression interacts badly with encryption, see e.g. CRIME, > BREACH, and hiding of EFAIL-style CFB gadgets [0]. This isn=E2=80=99t strictly correct. There are a number of attacks on interactive encryption protocols that = use differences in different compressed plaintext to learn something = about the internal structure of the plaintext. This is obviously bad. However, *static* encryption, like OpenPGP doesn=E2=80=99t have this = problem. Here=E2=80=99s a challenge I give. Create two plaintexts, P and P=E2=80=99 where P=E2=80=99 =3D = compress(P). Pick any compression function and any plaintext. Now, = encrypt them both, so we have E_1 =3D encrypt(P) and E_2 =3D = encrypt(P=E2=80=99). Show that there is an advantage to an attacker for = recovering P=E2=80=99 from E_2 over recovering P from E_1. I assert that if you can, then your cipher is flawed and you need to = replace it. There is nothing magical about compressed plaintext that = makes it easier to recover. With regards to EFAIL, that is a huge problem that is far more to do = with MIME encoding than anything else. It applies to S/MIME as well as = OpenPGP, and S/MIME typically does CBC mode as opposed to CFB and = typically does not compress. Thus the connection is tenuous, because = EFAIL applies not only to compressed data with CFB mode, but = uncompressed data with CBC. >=20 > - The downstream application is in a better position to decide = whether > and how to compress data that is then encrypted using OpenPGP. I kinda agree with you, in this one. I=E2=80=99d say upstream rather = than downstream because I think that the generator of encrypted objects = is upstream, and the thing that processes the output is downstream. But = I agree with what I think you=E2=80=99re saying. Nonetheless, this is a feature that=E2=80=99s been there since Day One, = and there are many systems that rely on OpenPGP compressing. In that = case, the other application has made a decision and this proposal would = override their decision on the grounds that they should be allowed to = make a decision. This is why while I like deprecating compression, I think we need to = move with care. >=20 > - Compression make the standard more complex, and enlarges the > trusted computing base of implementations. I don=E2=80=99t disagree here, and this is essentially my rationale. = However, to be fair, this is a part of the system that is used on nearly = every encryption and there haven't been many (or any?) problems. = Removing something is also risky and introduces other chances for = errors, too. This is why taking action *now* by just stopping to use compression is a = very good idea. It shows that there won=E2=80=99t be compatibility = issues, and the more that the actual use goes down, the more than an = argument to remove makes sense.=20 The worst thing possible would be that no-compression gets tied into = things like V5 keys (which we need) and AEAD modes (which we also need) = is that it would blunt adoption of the good new technologies by adding = on and tying things together. This is a classic problem that many = systems have, that the goodness is blunted because it drags in something = about which gentlepersons can disagree. Okay, enough soapbox. I think we should start moving away from default compression, starting = now. I think we should move slowly with the standard and collect data = about use, which would support removal in a future update. Jon From nobody Wed Mar 20 17:09:47 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E54D1274D0 for ; Wed, 20 Mar 2019 17:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ruhr-uni-bochum.de 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 knzM8tOIqbUR for ; Wed, 20 Mar 2019 17:09:43 -0700 (PDT) Received: from out3.mail.ruhr-uni-bochum.de (out3.mail.ruhr-uni-bochum.de [134.147.53.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9FD6124B91 for ; Wed, 20 Mar 2019 17:09:42 -0700 (PDT) Received: from mx3.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by out3.mail.ruhr-uni-bochum.de (Postfix mo-ext) with ESMTP id 44PnGW0FYmz8S5v for ; Thu, 21 Mar 2019 01:09:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ruhr-uni-bochum.de; s=mail-2017; t=1553126979; bh=S3YbRH0WvERTxHw0r2MzzXLk8UaAbVgi1+ZexjlhF/U=; h=Subject:To:References:From:Date:In-Reply-To:From; b=qyrrDfE8Z1yj1q3NeCg1+PYFQbzuDFtLGMAwzyMkrBJp8DTdb6yCENRadlB8kmCdc pCLN9JbSCKqmfcV/dnn4VqYC2nZAa8THG18MwIZ9ZkWZzCKsRGVxAwC4g3JLe6B3wO 0nRzdS1mKl2Ka8+mr/KpZxUdQBe42ikM/mgPkpew= Received: from out3.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by mx3.mail.ruhr-uni-bochum.de (Postfix idis) with ESMTP id 44PnGV5sSCz8S5r for ; Thu, 21 Mar 2019 01:09:38 +0100 (CET) X-Envelope-Sender: X-RUB-Notes: Internal origin=134.147.42.227 Received: from mail1.mail.ruhr-uni-bochum.de (mail1.mail.ruhr-uni-bochum.de [134.147.42.227]) by out3.mail.ruhr-uni-bochum.de (Postfix mi-int) with ESMTP id 44PnGV5ggzz8S5X for ; Thu, 21 Mar 2019 01:09:38 +0100 (CET) Received: from [192.168.142.139] (p4FE3F022.dip0.t-ipconnect.de [79.227.240.34]) by mail1.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 44PnGW0qnXzyqL for ; Thu, 21 Mar 2019 01:09:39 +0100 (CET) To: openpgp@ietf.org References: <2301148.obROdnegVN@esus> <871s3475dy.fsf@europa.jade-hamburg.de> <32M8VBNV00C3O.2R23SQ96PJPG3@my.amazin.horse> <2020697.uNjeE9oTgC@esus> From: Marcus Brinkmann Openpgp: preference=signencrypt Message-ID: <2ab499b1-01cb-2738-7ae7-52011747c9ac@ruhr-uni-bochum.de> Date: Thu, 21 Mar 2019 01:09:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <2020697.uNjeE9oTgC@esus> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.4 at mail1.mail.ruhr-uni-bochum.de X-Virus-Status: Clean Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2019 00:09:46 -0000 Hi Andre, isn't gpgtar (which I assume is still used by Kleopatra on Windows to encrypt folders) also "unstandardized" by OpenPGP? For all practical purposes, compressed archive formats are well-established across all platforms, so it's unclear to me what kind of problems you fear. Thanks, Marcus On 3/20/19 2:17 PM, Andre Heinecke wrote: > On Wednesday 20 March 2019 14:14:49 CET Vincent Breitmoser wrote: >> Is your point that you would want to keep compression as a feature in those >> applications, hence removing it from OpenPGP would mean you'd have to keep > it >> around unstandardized / on a different layer? > > Exactly. The User Experience of Kleopatra on Windows is that you right click a > folder and encrypt that folder. You need compression there. > Currently it is standardized. You propose to remove the standard so it will be > unstandartized and no longer interoperable. > > Regards, > Andre > > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > -- Dipl.-Math. Marcus Brinkmann Lehrstuhl fr Netz- und Datensicherheit Ruhr Universitt Bochum Universittsstr. 150, Geb. ID 2/461 D-44780 Bochum Telefon: +49 (0) 234 / 32-25030 http://www.nds.rub.de/chair/people/mbrinkmann From nobody Wed Mar 20 17:30:25 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FAB127917 for ; Wed, 20 Mar 2019 17:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 LcDoT8JFutSw for ; Wed, 20 Mar 2019 17:30:22 -0700 (PDT) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 048F31275F3 for ; Wed, 20 Mar 2019 17:30:22 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id a16so3598869edn.1 for ; Wed, 20 Mar 2019 17:30:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=NOujZlN1+glzdeAwJ3Mw8PuKXiHMiuSdnF63Alg0UAg=; b=Bnzbv/coVmAoY8/MDVWB6okSobdQhHbTRt+FtwyBt1xGt1+x8s8f/aturrm1GxXjjy uCBAqbzz8QMixUxZ/zEEI81bf8cLnWecZ3I9fmTB+0H+7Q84UyxFk4qSlJYg0UW+OOTS cPqTJWlQf8rEzzb8QpsvuTkVDdmRbjrcAgZPmHL9JpX3639Eaii9TrrGdNACaCcJoKQM ZEEghrPnmF5KwgMf2NaKdP+5cYl6JcDiruVeqVdc05JbrcHnN8YB/Kl9V0dKNSkvxZ2p YfY77PFFaeajE4XOJE4vffqU6XpH53iZDUK2JVlXcG2kk/eLRNaeMPZWBqlMkbobo6CH T/QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=NOujZlN1+glzdeAwJ3Mw8PuKXiHMiuSdnF63Alg0UAg=; b=Lxp8t4DgLuxclLZKX7C6iF356CA2f/QqA0WkLeWsYit2f5Qg1oAVOCr4nHFLs/VQFX SyK8yW0QRs8BQxQxCnYtcbH6itNiUwY6/n4qrjzasHNavU8q0JYdXeq2gzjvOqMKOX8A D72gna/rvWMMDCGrZL4WRVs8gdRurWfzqstL+mJHpgqdpY6ZLvPGvIVyPXjJhJFR5nQm SbCyouNYdVSlIzjQuqeXqYRgt/EN680QmiS3fTFhfvaQcQsQ31FagsuBGYx37b3MUfYO uoNHIlvKI+Ut1iSp0x+XBePB7O1W/XsDR6rbeFrFIaoSvE0i1yw3u/ZrEFrLsB1JTHKF FsCA== X-Gm-Message-State: APjAAAXDDqi8XNCwy9cGTy2TvzROv20HTKMJH+eyrVJFyMdcgLJMHiOV Oyrro2ZYGCnpvifqDF1owRm6okCwBuUnp3ZUg+I= X-Google-Smtp-Source: APXvYqwigCRdv9gdHAxjmzDhomHKJ7jcSq9KDvdv8BcMOVuAd3iFjgfkK+o4Lwtl7VgV9yF3SMlVNTkLIyIXdZFLv6U= X-Received: by 2002:a17:906:a841:: with SMTP id dx1mr507869ejb.99.1553128220589; Wed, 20 Mar 2019 17:30:20 -0700 (PDT) MIME-Version: 1.0 References: <871s3475dy.fsf@europa.jade-hamburg.de> <14617627-542E-4672-B83C-1B5E87561B50@icloud.com> In-Reply-To: <14617627-542E-4672-B83C-1B5E87561B50@icloud.com> From: Gregory Maxwell Date: Thu, 21 Mar 2019 00:30:07 +0000 Message-ID: To: Jon Callas Cc: "openpgp@ietf.org OpenPGP" , Jon Callas Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2019 00:30:25 -0000 On Wed, Mar 20, 2019 at 8:57 PM Jon Callas wrote: > There are a number of attacks on interactive encryption protocols that us= e differences in different compressed plaintext to learn something about th= e internal structure of the plaintext. This is obviously bad. > However, *static* encryption, like OpenPGP doesn=E2=80=99t have this prob= lem. > Here=E2=80=99s a challenge I give. > Create two plaintexts, P and P=E2=80=99 where P=E2=80=99 =3D compress(P).= Pick any compression function and any plaintext. Now, encrypt them both, s= o we have E_1 =3D encrypt(P) and E_2 =3D encrypt(P=E2=80=99). Show that the= re is an advantage to an attacker for recovering P=E2=80=99 from E_2 over r= ecovering P from E_1. > I assert that if you can, then your cipher is flawed and you need to repl= ace it. There is nothing magical about compressed plaintext that makes it e= asier to recover. We've been here before: https://mailarchive.ietf.org/arch/msg/openpgp/rG-X9rp2jlbyACoosnbxRXjCeys I buy the combining encryption with compression being useful argument... but at the same time, openpgp compression is increasingly far from the state-of-the-widespread-art (e.g. xz) and there probably isn't much interest in updating it to chase the state of the art compression (and for short human texts, I think recent machine learning progress look like they're resulting in significantly higher amounts of compression, -- just no one has productionized that work yet). From nobody Thu Mar 21 01:35:16 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71CD8130E8B for ; Thu, 21 Mar 2019 01:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org 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 HjOLKd4bEr2Y for ; Thu, 21 Mar 2019 01:35:11 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDFA8130DE7 for ; Thu, 21 Mar 2019 01:35:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=NzGRWiKVGn78mZGAhugYNGthXVAiAAEecAAmZvc/En4=; b=Y3rutclbkp/PXvkZP9cPbw7DDv 1rNkjjekhce5t5YYXrctmn+zQKiwPjNFAXQQyHOMoLOLgXNiWtXzYE1UhUyKEwQPIxSRAR6Az3oAA klPrhYcZQQnaFIi3i5FnDFF0eKWX4djUenQ7nAFLPdNTrw89Pesoop7Gmxk68hdmYd1I=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1h6tAM-0005px-Cu for ; Thu, 21 Mar 2019 09:35:10 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1h6t8E-0006ea-So; Thu, 21 Mar 2019 09:32:58 +0100 From: Werner Koch To: Bart Butler Cc: Andre Heinecke , Bart Butler , "openpgp\@ietf.org" , Justus Winter References: <871s3475dy.fsf@europa.jade-hamburg.de> <2181951.mQFCbn3PMz@esus> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: Bart Butler , Andre Heinecke , Bart Butler , "openpgp\@ietf.org" , Justus Winter Date: Thu, 21 Mar 2019 09:32:52 +0100 In-Reply-To: (Bart Butler's message of "Wed, 20 Mar 2019 18:47:27 +0000") Message-ID: <87lg181vbf.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=Phreaking_STEP_First_responder_chameleon_man_Interstate_JSOFC3IP=Att"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2019 08:35:14 -0000 --=Phreaking_STEP_First_responder_chameleon_man_Interstate_JSOFC3IP=Att Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 20 Mar 2019 18:47, bartbutler=3D40protonmail.com@dmarc.ietf.org said: > One thing we could add to the compression section would be a SHOULD > for ZLIB as opposed to the legacy ZIP and bzip2, which is slow and I was about to write the same. Salam-Shalom, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=Phreaking_STEP_First_responder_chameleon_man_Interstate_JSOFC3IP=Att Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCXJNMNQAKCRD/gK6dHew1 jVI6AQDE7y4OGDuERyM7OWUIjD95ION1BO4clhEt/tty6TvuDQEAlh40gkaxKkIG bmYcBX4XnehILjdU4zuKM8VOCiisTQI= =n6U3 -----END PGP SIGNATURE----- --=Phreaking_STEP_First_responder_chameleon_man_Interstate_JSOFC3IP=Att-- From nobody Thu Mar 21 15:37:54 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E25C129A87 for ; Thu, 21 Mar 2019 15:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com 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 6kYT2-tmlWNj for ; Thu, 21 Mar 2019 15:37:51 -0700 (PDT) Received: from mr85p00im-hyfv06021301.me.com (mr85p00im-hyfv06021301.me.com [17.58.23.188]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D87301279A5 for ; Thu, 21 Mar 2019 15:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1553207869; bh=9jjeJzRv4OtyzqHKJ7+KpFN8P5g5XO4Rnc+sozOFIjo=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=tMwmvC5seKJhsM8CKFO8kxzbj7/I/ZKA6nefwElQ03BoyHGbSXeZBbkNb0BbG/04B CuhXH0ZWFTccfTyILkvJj6qn5WFGU83EMPH+k3Dh/kLrnnYK6ntwCYgFNHC6i3rFA4 RlDz6xLcXN9XtSSlLa3E4u0edV5fMtxt1q89uLGsBrdY3qRtTwJqcA38CKYmjm1DPe tGfv8MqFHeZNDRmO2VjmeLBI1AJVa6rbBOv18hCunwpRU/1qItRVEq5OOPhcv8Kqmj CVoVGqUs8FSjpUOg3fFj/3qMXMec4AUOe69rdOyle1luNt8kJqFW63CG1cTtQW3zLG 5c2XwVh7tM+Zw== Received: from [192.168.7.69] (thing1.merrymeet.com [173.164.244.99]) by mr85p00im-hyfv06021301.me.com (Postfix) with ESMTPSA id 9EB0F40119; Thu, 21 Mar 2019 22:37:49 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Jon Callas In-Reply-To: Date: Thu, 21 Mar 2019 15:37:46 -0700 Cc: Jon Callas , "openpgp@ietf.org OpenPGP" Content-Transfer-Encoding: quoted-printable Message-Id: <3E3D5147-2360-4F78-9AA6-02603AB1C095@icloud.com> References: <871s3475dy.fsf@europa.jade-hamburg.de> <14617627-542E-4672-B83C-1B5E87561B50@icloud.com> To: Gregory Maxwell X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-21_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1903210157 Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2019 22:37:53 -0000 > On Mar 20, 2019, at 5:30 PM, Gregory Maxwell = wrote: >=20 >=20 > = https://mailarchive.ietf.org/arch/msg/openpgp/rG-X9rp2jlbyACoosnbxRXjCeys >=20 > I buy the combining encryption with compression being useful > argument... but at the same time, openpgp compression is increasingly > far from the state-of-the-widespread-art (e.g. xz) and there probably > isn't much interest in updating it to chase the state of the art > compression (and for short human texts, I think recent machine > learning progress look like they're resulting in significantly higher > amounts of compression, -- just no one has productionized that work > yet). I almost brought up that case, as I find it interesting and compelling, = but it=E2=80=99s not the case we=E2=80=99re dealing with here, and I = thought it would be some combination of trollish and a straw man, so I = didn=E2=80=99t. This is a case where there=E2=80=99s an issue. For those wanting a = TL;DR, someone created a text ballot that got encrypted with OpenPGP and = sent in an email. Because the encrypted ballot a single question and = compressed to a different size, so you could tell who someone voted for = by the size of the ballot (all other things being equal). [1] This is a problem that=E2=80=99s worth looking at. (Also, I feel like I = am a broken record here.) There is an existing workaround for this = issue, and that=E2=80=99s to put a no-compression preference on the key = people encrypt to.=20 I believe this is yet another reason why the implementations might want = to move towards compression off by default.=20 That wasn=E2=80=99t what was said at the time =E2=80=94 at the time, the = debate was that because of this problem, compression should be banned in = the standard, which is not only more problematic (as we=E2=80=99re = seeing now, there are a lot of people who depend on it), and the slower = way to handle things.=20 I am quite sure you=E2=80=99re frustrated, and I am too. I agree that we = ought to phase out compression, and there are a number of reasons for = it. This is one of those reasons. I=E2=80=99m sure that I frustrate you, = too, because I consider that case to be a minor reason. We are, however, = on the same side on outcomes. Let=E2=80=99s concentrate on the outcome = we agree with. Jon [1] Getting rid of encryption does not completely solve the ballot = problem; you still need to design the ballot properly. Here=E2=80=99s = the counter example: Consider a ballot where someone writes in either = =E2=80=9CAlice=E2=80=9D or =E2=80=9CBob.=E2=80=9D This ballot leaks the = choice because Alice=E2=80=99s votes are two bytes longer in length. A = ballot that ships =E2=80=9C[ ] Alice [ ] Bob=E2=80=9D and asks to put an = X between the appropriate brackets is much better ballot construction. = It=E2=80=99s still possible to get that one wrong, too, either by = accident or on purpose.= From nobody Fri Mar 22 02:20:16 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E0E130EC9 for ; Fri, 22 Mar 2019 02:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org 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 ljrKtm2jhoYc for ; Fri, 22 Mar 2019 02:20:11 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5747E130EC2 for ; Fri, 22 Mar 2019 02:20:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=RcKGptHFDRRGh9GbSZRsYfZJFIfiZJhzEWRk50p3QIY=; b=LtAtlx4WxYBNtvFyxJNRCemhVo PaoVpYNf+T8SiPc0n+3HiqCxFL0XQKtSkQDnS80f6cff7BcN6/GvhGA1UIdJfvuBJDCunoUi/FWVp +ZmFkZwUvC7wjbnNNXvCa7imn40Ulw/kw2yf383715j2rnLCUrcGGAPNRcyHyihCAfCI=; Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1h7GLR-0006lZ-Hl for ; Fri, 22 Mar 2019 10:20:09 +0100 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1h7GKR-0004u3-T2; Fri, 22 Mar 2019 10:19:07 +0100 From: Werner Koch To: Bart Butler Cc: Andre Heinecke , Bart Butler , "openpgp\@ietf.org" , Justus Winter References: <871s3475dy.fsf@europa.jade-hamburg.de> <2181951.mQFCbn3PMz@esus> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: Bart Butler , Andre Heinecke , Bart Butler , "openpgp\@ietf.org" , Justus Winter Date: Fri, 22 Mar 2019 10:19:07 +0100 In-Reply-To: (Bart Butler's message of "Wed, 20 Mar 2019 18:47:27 +0000") Message-ID: <87va0bxo50.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=Communications_infrastructure_bce_DRA_Extreme_weather_Emergency=mana"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2019 09:20:15 -0000 --=Communications_infrastructure_bce_DRA_Extreme_weather_Emergency=mana Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 20 Mar 2019 18:47, bartbutler=3D40protonmail.com@dmarc.ietf.org said: > One thing we could add to the compression section would be a SHOULD > for ZLIB as opposed to the legacy ZIP and bzip2, which is slow and > doesn't have much of a reason to exist in my opinion. There's no real So what about this minor change: @@ -3322,8 +3321,9 @@ ## Compression Algorithms 100--110 Private/Experimental algorithm =20 Implementations MUST implement uncompressed data. Implementations =2DSHOULD implement ZIP. Implementations MAY implement any other =2Dalgorithm. +SHOULD implement ZLIB. For interoperability reasons implementations +SHOULD be able to decompress using ZIP. Implementations MAY implement +any other algorithm. =20 ## Hash Algorithms Salam-Shalom, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=Communications_infrastructure_bce_DRA_Extreme_weather_Emergency=mana Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCXJSoiwAKCRD/gK6dHew1 jS7SAP9KFmOakgAkTXisoCdfqKhz9eaWsG0isYpC99nUtc+uOwEAzU1i9fKUj2pk LBZ4mQA/c/zqhusLXEwtXJMOpGCIHAY= =JkvF -----END PGP SIGNATURE----- --=Communications_infrastructure_bce_DRA_Extreme_weather_Emergency=mana-- From nobody Fri Mar 22 03:33:03 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6CF7130DE7 for ; Fri, 22 Mar 2019 03:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ribose.com 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 k5LPnyXAuogZ for ; Fri, 22 Mar 2019 03:33:00 -0700 (PDT) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-eopbgr1300040.outbound.protection.outlook.com [40.107.130.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD72D1200D7 for ; Fri, 22 Mar 2019 03:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ribose.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+h2Qidx8QmjsQhhi2gggiyPgqpJLoSs+z/gkS6uczLs=; b=iDwHq1vtEgai5OJU1DYLxPWQtN05htuAXJ+1GdaTHL8MQ9v7sQ2wIIh/cnfIwe62is2E22gGte1KlGF5SUXYU2q/9O+h29nHihzraNbBEtpwMjJbm8yl81ca+DjMRRT9prwsoEfV81mUD4jECGk13UHRsj6qj/LF5WeHTmy9Xuo= Received: from HK0PR01MB2770.apcprd01.prod.exchangelabs.com (20.177.167.212) by HK0PR01MB1956.apcprd01.prod.exchangelabs.com (52.133.211.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.16; Fri, 22 Mar 2019 10:32:55 +0000 Received: from HK0PR01MB2770.apcprd01.prod.exchangelabs.com ([fe80::6028:8749:e156:58f7]) by HK0PR01MB2770.apcprd01.prod.exchangelabs.com ([fe80::6028:8749:e156:58f7%4]) with mapi id 15.20.1730.013; Fri, 22 Mar 2019 10:32:55 +0000 From: Ronald Tse To: "openpgp@ietf.org" , Werner Koch Thread-Topic: [openpgp] Deprecating compression support Thread-Index: AQHU3YM2J+61qWeIREOBXd4QSRtXvqYUnncAgABBPYCAAoZGRYAAFDYA Date: Fri, 22 Mar 2019 10:32:55 +0000 Message-ID: <309FAB65-B738-4D92-983D-717887622B86@ribose.com> References: <871s3475dy.fsf@europa.jade-hamburg.de> <2181951.mQFCbn3PMz@esus> <87va0bxo50.fsf@wheatstone.g10code.de> In-Reply-To: <87va0bxo50.fsf@wheatstone.g10code.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tse@ribose.com; x-originating-ip: [112.120.148.19] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e6b5da28-1bce-4fa8-3571-08d6aeb1bebe x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(5600127)(711020)(4605104)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(2017052603328)(7153060)(7193020); SRVR:HK0PR01MB1956; x-ms-traffictypediagnostic: HK0PR01MB1956: x-microsoft-antispam-prvs: x-forefront-prvs: 09840A4839 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(366004)(39830400003)(376002)(136003)(189003)(199004)(7736002)(236005)(11346002)(486006)(81156014)(6246003)(229853002)(186003)(2501003)(2616005)(966005)(68736007)(81166006)(82746002)(5660300002)(97736004)(476003)(8676002)(102836004)(256004)(26005)(54896002)(6306002)(76176011)(6506007)(53546011)(6512007)(53936002)(99286004)(86362001)(6486002)(71200400001)(8936002)(106356001)(83716004)(66066001)(25786009)(6436002)(71190400001)(36756003)(2906002)(105586002)(93886005)(14454004)(3846002)(6116002)(508600001)(316002)(33656002)(110136005)(446003); DIR:OUT; SFP:1101; SCL:1; SRVR:HK0PR01MB1956; H:HK0PR01MB2770.apcprd01.prod.exchangelabs.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:3; A:1; received-spf: None (protection.outlook.com: ribose.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: DB1vZR4okeehlYfkwB+IQbISZV+lul22kvPr3fJHlWZOvcWIYofDxklBLVCTfKmcF808LuxW0adzoWDWWQeXBqcBx40q3qVltWw3YlThfew5wb7mywvADJbyGLefZi+kJA6DEww5F1Y1N8cL3Mrw9BTWoiW+bvNs7phJRvS7zrS1XqQFuBAgIH/1AsdIRTKDwlKSkFlkpzn3Ye46ag8KF80UefZzEGEEkuGufOGoTyySsLskxsmvGWPXliazPE/2/earb5Ljwpi6sfN9rQYAVXQUpNaDcPEZsoUMEkW5ziqCAtdQFzQVg4zBdIaNFQcgFjhv/2wWnnOUQat4pWXDuAI945rAFOQlnVbQxTFbmvhUxXJGsgss0kofPyHXfiGqgFCRFJpX4JCrxZGs+28dmOyx9aetRbmgijgwg8PGWXA= Content-Type: multipart/alternative; boundary="_000_309FAB65B7384D92983D717887622B86ribosecom_" MIME-Version: 1.0 X-OriginatorOrg: ribose.com X-MS-Exchange-CrossTenant-Network-Message-Id: e6b5da28-1bce-4fa8-3571-08d6aeb1bebe X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2019 10:32:55.0693 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d98a04ff-ef98-489b-b33c-13c23a2e091a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK0PR01MB1956 Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2019 10:33:03 -0000 --_000_309FAB65B7384D92983D717887622B86ribosecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agree. Thanks Werner! _____________________________________ Ronald Tse Ribose Inc. On Mar 22, 2019, at 5:19 PM, Werner Koch = > wrote: On Wed, 20 Mar 2019 18:47, bartbutler=3D40protonmail.com@dmarc.ietf.org said: One thing we could add to the compression section would be a SHOULD for ZLIB as opposed to the legacy ZIP and bzip2, which is slow and doesn't have much of a reason to exist in my opinion. There's no real So what about this minor change: @@ -3322,8 +3321,9 @@ ## Compression Algorithms 100--110 Private/Experimental algorithm Implementations MUST implement uncompressed data. Implementations -SHOULD implement ZIP. Implementations MAY implement any other -algorithm. +SHOULD implement ZLIB. For interoperability reasons implementations +SHOULD be able to decompress using ZIP. Implementations MAY implement +any other algorithm. ## Hash Algorithms Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. _______________________________________________ openpgp mailing list openpgp@ietf.org https://www.ietf.org/mailman/listinfo/openpgp --_000_309FAB65B7384D92983D717887622B86ribosecom_ Content-Type: text/html; charset="us-ascii" Content-ID: <754C315193EF2E4D8EEB0334A14F522E@apcprd01.prod.exchangelabs.com> Content-Transfer-Encoding: quoted-printable Agree. Thanks Werner!

_____________________________________

Ronald Tse
Ribose Inc.

On Mar 22, 2019, at 5:19 PM, Werner Koch <wk@gnupg.org> wrote:

On Wed, 20 Mar 2019 18:47, bartbutler=3D40protonmail.com@dmarc.ietf.org
said:

One thing we could add to the compress= ion section would be a SHOULD
for ZLIB as opposed to the legacy ZIP and bzip2, which is slow and
doesn't have much of a reason to exist in my opinion. There's no real

So what about this minor change:

@@ -3322,8 +3321,9 @@ ## Compression Algorithms
 100--110  Private/Experimental algorithm

Implementations MUST implement uncompressed data.  Implementations
-SHOULD implement ZIP.  Implementations MAY implement any other
-algorithm.
+SHOULD implement ZLIB.  For interoperability reasons implementati= ons
+SHOULD be able to decompress using ZIP.  Implementations MAY impl= ement
+any other algorithm.

## Hash Algorithms



Salam-Shalom,

  Werner

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
_______________________________________________
openpgp mailing list
openpgp@ietf.org
https://www.ietf.org/mailman/listinfo/openpgp

--_000_309FAB65B7384D92983D717887622B86ribosecom_-- From nobody Fri Mar 22 07:18:21 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF5B130ED7 for ; Fri, 22 Mar 2019 07:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com 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 mEi6CZWCqFq4 for ; Fri, 22 Mar 2019 07:18:18 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C753F130EC2 for ; Fri, 22 Mar 2019 07:18:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 48849E2042; Fri, 22 Mar 2019 10:18:15 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 06806-03; Fri, 22 Mar 2019 10:18:10 -0400 (EDT) Received: from securerf.ihtfp.org (99-46-190-172.lightspeed.tukrga.sbcglobal.net [99.46.190.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id BE347E2040; Fri, 22 Mar 2019 10:18:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1553264289; bh=3mKS5s1RiaUlT/f46EdBz8pQOvIRL1AW9nJp7cVSrlI=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=H6uRXAGAycU50eg/pN6ogyJicp3qdji3jUg5FoBtXjtGaRPfYgEllbDerwkU/7F9e 00Uk9FpthIB1TxkVj40g2Cudy8e6dCUYoE7vEeHAvz7jiupMP+jGxAM7gAdSbJxLgE F91FpANWbNILDJUdWQcro2JvdCGwkwRivlL3iep0= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id x2MEI0bD018566; Fri, 22 Mar 2019 10:18:00 -0400 From: Derek Atkins To: Bart Butler Cc: Andre Heinecke , Bart Butler , "openpgp\@ietf.org" , Justus Winter References: <871s3475dy.fsf@europa.jade-hamburg.de> <2181951.mQFCbn3PMz@esus> <87va0bxo50.fsf@wheatstone.g10code.de> Date: Fri, 22 Mar 2019 10:17:58 -0400 In-Reply-To: <87va0bxo50.fsf@wheatstone.g10code.de> (Werner Koch's message of "Fri, 22 Mar 2019 10:19:07 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2019 14:18:20 -0000 +1 from me! Thanks, Werner. -derek Werner Koch writes: > So what about this minor change: > > @@ -3322,8 +3321,9 @@ ## Compression Algorithms > 100--110 Private/Experimental algorithm > > Implementations MUST implement uncompressed data. Implementations > -SHOULD implement ZIP. Implementations MAY implement any other > -algorithm. > +SHOULD implement ZLIB. For interoperability reasons implementations > +SHOULD be able to decompress using ZIP. Implementations MAY implement > +any other algorithm. > > ## Hash Algorithms > > > > Salam-Shalom, > > Werner -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Mar 22 09:58:42 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B087C1312C7 for ; Fri, 22 Mar 2019 09:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com 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 0ANljRG55yef for ; Fri, 22 Mar 2019 09:58:36 -0700 (PDT) Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32312131297 for ; Fri, 22 Mar 2019 09:58:36 -0700 (PDT) Date: Fri, 22 Mar 2019 16:58:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1553273913; bh=AcCUeXW3zB1upNMs1D8qdDXtgU0J0zaVWDjYXEOvlVI=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=ANZmAVZR5ZQLFWnj8mmwaHTzsLC32HkC8Ei1vs5iTGEQ/LObQkSSF0u84iQ9q/zM0 OcUhhjbzpYcvLill/hZY9BMTZIYMJksCKhC5v1irdgc1PdqSMJrxfrJGjFzmuy14sE eFNI5+s9wRVBhNuRvWS63XeVc+1TwVLmCAUoKvOA= To: Derek Atkins From: Bart Butler Cc: Andre Heinecke , "openpgp\\@ietf.org" , Justus Winter Reply-To: Bart Butler Message-ID: In-Reply-To: References: <871s3475dy.fsf@europa.jade-hamburg.de> <2181951.mQFCbn3PMz@esus> <87va0bxo50.fsf@wheatstone.g10code.de> Feedback-ID: XShtE-_o2KLy9dSshc6ANALRnvTQ9U24aqXW2ympbGschdpHbU6GYCTUCtfmGhY9HmOyP1Uweyandwh1AVDFrQ==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="---------------------66bb294df9105692f0d8a90dcde56d7b"; charset=UTF-8 Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2019 16:58:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------66bb294df9105692f0d8a90dcde56d7b Content-Type: multipart/mixed;boundary=---------------------4c0e1429801214233c17c6f1769e57be -----------------------4c0e1429801214233c17c6f1769e57be Content-Transfer-Encoding: quoted-printable Content-Type: text/plain;charset=utf-8 +1 from me too, thanks! =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original M= essage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Friday, March 22, 2019 7:17 AM, Derek Atkins wrote: > +1 from me! > Thanks, Werner. > = > -derek > = > Werner Koch wk@gnupg.org writes: > = > > So what about this minor change: > > @@ -3322,8 +3321,9 @@ ## Compression Algorithms > > 100--110 Private/Experimental algorithm > > Implementations MUST implement uncompressed data. Implementations > > -SHOULD implement ZIP. Implementations MAY implement any other > > -algorithm. > > +SHOULD implement ZLIB. For interoperability reasons implementations > > +SHOULD be able to decompress using ZIP. Implementations MAY implement > > +any other algorithm. > > = > > Hash Algorithms > > = > > ---------------- > > = > > Salam-Shalom, > > Werner > = > -- > = > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > -----------------------4c0e1429801214233c17c6f1769e57be-- -----------------------66bb294df9105692f0d8a90dcde56d7b Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail Comment: https://protonmail.com wl4EARYKAAYFAlyVFCsACgkQmQVEZe8zHkSlpgD9HXFUauJTX0SLaxyNQLnj hefO45nAWaRyzUSRgS1kOZYA/i3YM9MVyGl/GRVGcrb247XAmmR89OhEn652 lbaj7DIK =2Xxh -----END PGP SIGNATURE----- -----------------------66bb294df9105692f0d8a90dcde56d7b-- From nobody Fri Mar 22 15:01:15 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D7E130F2B for ; Fri, 22 Mar 2019 15:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com 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 qTqYbTjxzM-6 for ; Fri, 22 Mar 2019 15:01:11 -0700 (PDT) Received: from mr85p00im-hyfv06011301.me.com (mr85p00im-hyfv06011301.me.com [17.58.23.184]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AF57124BA8 for ; Fri, 22 Mar 2019 15:01:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1553292070; bh=Wev0todErPoGHcLiZiyayb5w8KWWy7jbXhgDN1Yk7g0=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=H0nfmdTBcc4i4711IxyuCz5RFl2ccEhmpf44CPVuFlHwDfwaZ/kpuQgaSZJNBJrxr LeJsyvHW0N0OiAnix20Y/+5OTFE8pvF0g7/6bO3E+AjG13hrjgmZtt2OcJN/m2ZVZA gIw/Gn2hmK50qo5yTQkvBaDZ9cOCw660aCbQ5UmMILuf7Nfjw9+qSBA2Q84VXTXbVK SpaRP41OmUOgoAenriorDXOBK8vptgZzFHBeo73NaW0QUEqPbLEp5qA8zxyeTfySO3 ICoo3xQSIQcciDLFnAe3dvcG65iJKqSHf9YBvlDVMLvKOmev96/K89Hpu5WGl6Jg9K PpiAYWLougUMQ== Received: from [10.125.12.156] (67-207-120-150.static.wiline.com [67.207.120.150]) by mr85p00im-hyfv06011301.me.com (Postfix) with ESMTPSA id 5932F5801EF; Fri, 22 Mar 2019 22:01:10 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Jon Callas In-Reply-To: <87va0bxo50.fsf@wheatstone.g10code.de> Date: Fri, 22 Mar 2019 15:01:09 -0700 Cc: "openpgp@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: <871s3475dy.fsf@europa.jade-hamburg.de> <2181951.mQFCbn3PMz@esus> <87va0bxo50.fsf@wheatstone.g10code.de> To: Werner Koch X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-22_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1903220156 Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2019 22:01:13 -0000 > On Mar 22, 2019, at 2:19 AM, Werner Koch wrote: > > On Wed, 20 Mar 2019 18:47, bartbutler=40protonmail.com@dmarc.ietf.org > said: > >> One thing we could add to the compression section would be a SHOULD >> for ZLIB as opposed to the legacy ZIP and bzip2, which is slow and >> doesn't have much of a reason to exist in my opinion. There's no real > > So what about this minor change: > > @@ -3322,8 +3321,9 @@ ## Compression Algorithms > 100--110 Private/Experimental algorithm > > Implementations MUST implement uncompressed data. Implementations > -SHOULD implement ZIP. Implementations MAY implement any other > -algorithm. > +SHOULD implement ZLIB. For interoperability reasons implementations > +SHOULD be able to decompress using ZIP. Implementations MAY implement > +any other algorithm. +1. Thanks, Werner. Jon From nobody Fri Mar 22 15:03:55 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43053131589 for ; Fri, 22 Mar 2019 15:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com 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 XCiFzxdmleJV for ; Fri, 22 Mar 2019 15:03:52 -0700 (PDT) Received: from mr85p00im-ztdg06021801.me.com (mr85p00im-ztdg06021801.me.com [17.58.23.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0AA113138A for ; Fri, 22 Mar 2019 15:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1553292231; bh=MzynhhhPYSqyZ8t1TAwShdlKYlQXWz36GS0BDe1ccu8=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=Ny57puXx2aUiPxnCcIICTtpKoprfzTj67W7Rb/ZJaQeXaCGZTfeHJIrq10IAJE30S +K2OQvC6dQP6c6JyFJL+Lmwp4+gbCXrhNzcyyDP4LgsRuc7z8XQ2wXlkbQMUHDiVpv fQ/Qf7NX3iscblLr18c4W8NTvM6Oj1hqNbsKy4VIg9vZyR226hOtwZi0gnUh2+J2RY VI6ZHvaClAPu+uFIhUSlSKPRSFq6EfKg9sbxM8yj//a9AnGmifNJnyiSPXO9PksEb+ socmiZJ8vzPW3e0vVoCwesJweQdNcIz9zovjvXd1qbD1AMw6jAkZRaDANqk6TYzJHh egz9a5d9e29kQ== Received: from [10.125.12.156] (67-207-120-150.static.wiline.com [67.207.120.150]) by mr85p00im-ztdg06021801.me.com (Postfix) with ESMTPSA id 7359B180073; Fri, 22 Mar 2019 22:03:51 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Jon Callas In-Reply-To: <96055353-B0EB-4E25-95CC-B25D9C5A0BA8@icloud.com> Date: Fri, 22 Mar 2019 15:03:50 -0700 Cc: Jon Callas , openpgp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8634EB15-05A3-4FCB-A349-134B8A2CC025@icloud.com> References: <871s3475dy.fsf@europa.jade-hamburg.de> <96055353-B0EB-4E25-95CC-B25D9C5A0BA8@icloud.com> To: Jon Callas X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-22_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=733 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1903220156 Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2019 22:03:53 -0000 > On Mar 18, 2019, at 1:45 PM, Jon Callas = wrote: >=20 [=E2=80=A6] > =E2=80=A6 banning encryption in 4880-bis, as well.=20 Obviously, I meant compression, not encryption. Oops. Thanks to the = friend who pointed this out. Jon From nobody Sat Mar 23 10:07:36 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18BC61277DE for ; Sat, 23 Mar 2019 10:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 O3O3PosF5K2g for ; Sat, 23 Mar 2019 10:07:32 -0700 (PDT) Received: from smtpin.nadir.org (smtpin.nadir.org [217.114.68.218]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3F231277CE for ; Sat, 23 Mar 2019 10:07:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtpin.nadir.org (Postfix) with ESMTP id 695897C9444 for ; Sat, 23 Mar 2019 18:07:27 +0100 (CET) Received: from smtpin.nadir.org ([127.0.0.1]) by localhost (fry.nadir.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qT2txBvcOIMm for ; Sat, 23 Mar 2019 18:07:27 +0100 (CET) Received: from snail.zeromail.org (mail.zeromail.org [217.114.68.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpin.nadir.org (Postfix) with ESMTPS id 301777C913C for ; Sat, 23 Mar 2019 18:07:27 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1])ng TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by snail.zeromail.org (Postfix) with ESMTPSA id 4B3D0BFABE for ; Sat, 23 Mar 2019 18:07:26 +0100 (CET) Date: Sat, 23 Mar 2019 18:07:23 +0100 From: ilf To: openpgp@ietf.org Message-ID: <20190323170723.GC1497@zeromail.org> Mail-Followup-To: openpgp@ietf.org References: <871s3475dy.fsf@europa.jade-hamburg.de> <96055353-B0EB-4E25-95CC-B25D9C5A0BA8@icloud.com> <2RAT852LYMAQD.3U70IQJPU0VPO@my.amazin.horse> <0092256D-94EB-4FE5-9560-FEB0B8E3769E@icloud.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="H8ygTp4AXg6deix2" Content-Disposition: inline In-Reply-To: <0092256D-94EB-4FE5-9560-FEB0B8E3769E@icloud.com> Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2019 17:07:34 -0000 --H8ygTp4AXg6deix2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable So can we change GnuPG to default-preference Uncompressed? Jon Callas: > To address your point, as I said in my long missive, you can do this=20 > today. No changes are needed to the protocol. All you have to do is=20 > put a compression preference on your key that says no compression, and=20 > then you won=E2=80=99t get compression. (Well, to be completely correct, = if=20 > someone compresses then they=E2=80=99re non-compliant to the standard.)= =20 > Repeating myself, I support and encourage implementations to do that=20 > by default. --=20 ilf If you upload your address book to "the cloud", I don't want to be in it. --H8ygTp4AXg6deix2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEy7FaaO86yASHXVxOFT/jmIIcg5QFAlyWZ8sACgkQFT/jmIIc g5RZtQ/6AseInRwdsxROcVkt43q40MriTDPfkfQUE8dss7AXTMf/dp+aV/V6c0GG ziMWW1FIBm0yGbo9HBj/btuG9Av0WxJiQ4gbhVM7TPbwQTkjV3b1WPjM6cVU5roL k7Gg1AWj5EZB+hLQJ31Kttv+xMiKg0qyeabWbMqBglH+p8MaanFdFCNBuGAm2Cqe BoDEpqpiGpnzd8XzNKoHIOFrqp4JSn2c8R844cGYd6hHtaSkCCtFlZSsI/JtZIsT 61lhgMV/zIKqhvibos6OFowgPNKef/fTgjHhhYeCkoWiV/5uqASxLS7ppm1/SVEy VGPob6p9RdmrEswPD2EggAlFFId5Sf4cR4X4014bVtHMHIx5a4Dmv4K3LBuFzlgD tnWwJZkKY0ZojBQBxec4m7LuJFzFR/04LVNSVC/wgYTi59zjViaaoG4fBlF1fQOv OkaXUuJhhcpnuF5Bw0WayWEgVxJVmtnwbXraIaEp4oKxeXdSQC+Zv60GNMKRQARW 7hzPJgCWLkVp14W9HdG070Y1SNJj0EtPtvnmrzEPdRm+2elBU+AapXNZbgLBuL0P f6yz9JSvFu76Bg6mWyOTtVWDkNss8kkrMM4fk1oqNKg6wcWOZHwT1UwEHtf9Gr3A C1GF9/ybGDZdlbYgterA/CaYNdx5UQM9uWyCZjoDCszgJV3X1Tg= =Z6xo -----END PGP SIGNATURE----- --H8ygTp4AXg6deix2-- From nobody Sat Mar 23 15:25:21 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B80191228B7 for ; Sat, 23 Mar 2019 15:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=2XuqJu/c; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=FKPYxzuc 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 mSoLc1UYDSZ7 for ; Sat, 23 Mar 2019 15:25:18 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4F631200B3 for ; Sat, 23 Mar 2019 15:25:17 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1553379916; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=D49e0tw99uEIcRwga4hcThDGQ0iEvpeP3gk7Sa/LPck=; b=2XuqJu/c0HN2JONJ3sGAUTe3XxueLDl1NDjdcPRfL1QUG+qXYp1m47vX Bd89YOzrB2dMxam6/3S5jlzTo0GuBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1553379916; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=D49e0tw99uEIcRwga4hcThDGQ0iEvpeP3gk7Sa/LPck=; b=FKPYxzucXbkHvP/Qh/lIe84HVBXelQ1xqiMWdij316qcnMYn8LnIsPav ze67EhSqVYNsBGWnu139L9Kur9Bl6zLTXGr7BmiZRDUF5wLMgAQDyctgAu eTWw1T7b8pbIvoCGScWKcNEzIi43MNH/7lDSzKbD6iJHjnTeiAsCx8E6c4 VHBf5ifHGI4ums/Gm9CCouYcdlE6y7hIUGwdPCurbDDGKj8Ks5PYQvEiSd oa6oziWe+lzI1obM5mXM8VmX2D33a8fLCSOvy0uVU0LqEShwEiD0kp6hDk S2cbYVZLWGAGM8iCIbN0MKOxGRUbXnRAuyzujwAWYBgk08L6ONf5CQ== Received: from fifthhorseman.net (ip-78-45-46-183.net.upcbroadband.cz [78.45.46.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 94934F99D; Sat, 23 Mar 2019 18:25:15 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 9A3FC206B9; Sat, 23 Mar 2019 18:13:30 -0400 (EDT) From: Daniel Kahn Gillmor To: ilf , openpgp@ietf.org, gnupg-devel@gnupg.org In-Reply-To: <20190323170723.GC1497@zeromail.org> References: <871s3475dy.fsf@europa.jade-hamburg.de> <96055353-B0EB-4E25-95CC-B25D9C5A0BA8@icloud.com> <2RAT852LYMAQD.3U70IQJPU0VPO@my.amazin.horse> <0092256D-94EB-4FE5-9560-FEB0B8E3769E@icloud.com> <20190323170723.GC1497@zeromail.org> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Mail-Followup-To: gnupg-devel@gnupg.org Date: Sat, 23 Mar 2019 23:13:30 +0100 Message-ID: <87imw9jl2t.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2019 22:25:20 -0000 --=-=-= Content-Type: text/plain On Sat 2019-03-23 18:07:23 +0100, ilf wrote: > So can we change GnuPG to default-preference Uncompressed? [ switching this implementation-specific message to gnupg-devel@gnupg.org, please respect Mail-Followup-To: ] The current implementation of GnuPG creates OpenPGP certificates with this preference listing: Compression: ZLIB, BZIP2, ZIP, Uncompressed Are you suggesting that we change it to: Compression: Uncompressed, ZLIB, BZIP2, ZIP or to: Compression: Uncompressed ? Setting aside the question of defaults, for your own OpenPGP certificate right now you can do this with any modern version of GnuPG, if you're willing to poke at the command line with some arcana: For the less severe change: gpg --edit-key $FINGERPRINT showpref 'setpref S9 S8 S7 S2 H10 H9 H8 H11 H2 Z0 Z2 Z3 Z1' save For the more severe change: gpg --edit-key $FINGERPRINT showpref 'setpref S9 S8 S7 S2 H10 H9 H8 H11 H2 Z0' save then of course you'll need to re-publish the cert via whatever your standard publication mechanism is (keyservers, WKD, keybase, etc). --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXJavigAKCRB2GBllKa5f +NoxAQDBPSK+C5+x6afn4lNDP7dQ9OXlR0pgCPSrszsX79TbBgEA1paEOKyLSo9l n8/aJzUC/e7fN1ZGCpYPCOeRc/TcSgo= =pRLf -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 25 02:20:53 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C5312037F for ; Mon, 25 Mar 2019 02:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 VPuY_ef8hCdJ for ; Mon, 25 Mar 2019 02:20:49 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 A39AC12037B for ; Mon, 25 Mar 2019 02:20:49 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id z24so4874425wmi.5 for ; Mon, 25 Mar 2019 02:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=N4REFOrfi0Dsk+oilFRfrO6PCK21rZrMiWyrvrrng2c=; b=gLI5fNHnuTjzEubWORgVkMvuYWuJu7x3iJONInTeRTnuGRJSegiIMi7IvQCjzqdl69 WwsfPj96V4mCxU6kTYakiySbzCejE4SiCymZItKSuucVxPm/MKJAhmOfWB4fe2GWc3Vb ACvEn6InATFUhcguQg6irvflQupBfboOUbi5YTVcxjbfGBLq/vY9RQfWAOU9QUB7ktAO 2nY2HAZObqccWk6JmbDYouDzvT2ETEU2AdHSCMnJ1D41u6zhatCr8iY0u1hfa2qVKcyN CBmhj5dcQqL38MHmnKqMv6Svhxa6Yd87iD3pdQ7K2jKykXvmzGOv3PmoaDrj0DQbmhXD 20Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=N4REFOrfi0Dsk+oilFRfrO6PCK21rZrMiWyrvrrng2c=; b=blVM4F5T6UEgoB7HGRE/nh3w49ZoF4RMXTsjedGGQuB0Anm/XNZgrcVWgojhiwGXaL ReKUjTsw6KRk21qGvdRXQiyIhYOJZgvGNCJQPFq4szQzQQUsbfqM+18NG5UhXedcI5V7 PKnJ7yCbrlkMLMGQsFRCvaXLE8Po6fm2fCXNHeJQNcj9k6iEemk0SsCsgdLkdp8TTCYu Nf8Il4X/5D6O7HIYqKHZ1VFHFB4/w0N738uPAUhiWYTZZcWU3Goaz3QpS9AE5EISDnBG QDrcef3ps+oybN4hqarWEE0KiSOwwRX67/oZTNQtWxp5KIAmLQ41Qkmn5b2HFsvYOLHO 8Kiw== X-Gm-Message-State: APjAAAWZp1ovs4gXLBKHeK35ESMR6JRXWi/3JOsW+tfLZgwhFEfVXeM9 b5/rM7vh9JDgQBlErV6Xi4Ag0LTb X-Google-Smtp-Source: APXvYqzBWITlHxZzWky9HK/N+9dcb4yD0vX9FZsUroJbwaX3JC8AxKoR3Uud23nRv7KUYecZzAzEcA== X-Received: by 2002:a1c:c6ce:: with SMTP id w197mr11137245wmf.95.1553505648129; Mon, 25 Mar 2019 02:20:48 -0700 (PDT) Received: from localhost (port-92-193-51-13.dynamic.qsc.de. [92.193.51.13]) by smtp.gmail.com with ESMTPSA id w9sm15535445wmi.0.2019.03.25.02.20.47 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 25 Mar 2019 02:20:47 -0700 (PDT) From: Justus Winter To: openpgp@ietf.org Date: Mon, 25 Mar 2019 10:20:45 +0100 Message-ID: <87ef6v71jm.fsf@europa.jade-hamburg.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: [openpgp] Embedded TPK subpacket X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 09:20:51 -0000 --=-=-= Content-Type: text/plain Hello, I'd like to propose a new signature subpacket that contains a TPK, let's call it the Embedded TPK subpacket. I see two immediate use cases: - If a designated revoker creates a revocation signature, she can embed her TPK in the signature, so that it is easy to verify the revocation without having to hunt for her TPK. - Some MUAs attach TPKs to emails, pEp does so too, and Autocrypt includes TPKs in mail headers. Instead of doing that, one could then transmit ones TPK (and those of others in the conversation) in-band. This has the advantage of requiring no cooperation of the MUAs, and the PGP implementations can gather the TPKs when parsing the signatures. Thanks, Justus --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEJWpOVeSnLZetJGjniNx+MzhfeR0FAlyYnW4ACgkQiNx+Mzhf eR1VTwgAlvrHKAd/s/gWemxnnp8CiJYfs67lFZbeLuljZbKqAAx617kzWfmsvvi2 KhOLH06COKAfLJ9bdtqogrlSrpOlv7O+F6xcTTYddH8GXLCUvEFFZwOjgAK3feiB HIJBUiYUrgeDDFGKd1durXJExNq9lNwBIIsH6bx+K9PU3kZxBVrHW5L4q4h8g4zV uGV2/BZdWASCQvwv6QrjyXA1q5CVHFMjmlgxck7dUCv1B8wIeHOkjkuaoUod7/7T 7l9zEYbU9Os10WQMFYnw6J6kEzWgCOHbfVN000d56saVDXCx0uXKMFlTzrkxCDbb PxtsUzExxGQ/6Eo+FrzL17iaXV34Lw== =7iuQ -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 25 02:46:21 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3B5120381 for ; Mon, 25 Mar 2019 02:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ruhr-uni-bochum.de 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 6a42Olj0GMZ0 for ; Mon, 25 Mar 2019 02:46:17 -0700 (PDT) Received: from out1.mail.ruhr-uni-bochum.de (out1.mail.ruhr-uni-bochum.de [134.147.53.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC8E612014F for ; Mon, 25 Mar 2019 02:46:16 -0700 (PDT) Received: from mx1.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by out1.mail.ruhr-uni-bochum.de (Postfix mo-ext) with ESMTP id 44STtH0C3lz4wBm for ; Mon, 25 Mar 2019 10:46:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ruhr-uni-bochum.de; s=mail-2017; t=1553507191; bh=+Q0VsafAVOHav9AVzZCzr/WTzTEAoRbdOy6Ln/G0WGk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=vrL8YG7YEx3GzjJ2gRVKJ2i+C6c8w7Bso/UP6LhnL6vDQif/iocgXti0rHFkspNk2 zZ77d0c783ku6WlLnNq0qrfSHVJhSwkMh8wfr6zqwwrLJLmFcw3pj33f6IZM5w7/Tq St43n4YrFzSogI62GRpgvPw3iyFIZyI0KdBO29qA= Received: from out1.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by mx1.mail.ruhr-uni-bochum.de (Postfix idis) with ESMTP id 44STtG6Fqqz4vyd for ; Mon, 25 Mar 2019 10:46:30 +0100 (CET) X-Envelope-Sender: X-RUB-Notes: Internal origin=134.147.42.227 Received: from mail1.mail.ruhr-uni-bochum.de (mail1.mail.ruhr-uni-bochum.de [134.147.42.227]) by out1.mail.ruhr-uni-bochum.de (Postfix mi-int) with ESMTP id 44STtG5q6Pz4wBm for ; Mon, 25 Mar 2019 10:46:30 +0100 (CET) Received: from [192.168.142.139] (p4FE3F5A1.dip0.t-ipconnect.de [79.227.245.161]) by mail1.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 44STsw61cXzyqp for ; Mon, 25 Mar 2019 10:46:12 +0100 (CET) To: openpgp@ietf.org References: <87ef6v71jm.fsf@europa.jade-hamburg.de> From: Marcus Brinkmann Openpgp: preference=signencrypt Message-ID: <1e6052ec-36ba-d14d-5028-b4aac973a494@ruhr-uni-bochum.de> Date: Mon, 25 Mar 2019 10:46:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <87ef6v71jm.fsf@europa.jade-hamburg.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.4 at mail1.mail.ruhr-uni-bochum.de X-Virus-Status: Clean Archived-At: Subject: Re: [openpgp] Embedded TPK subpacket X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 09:46:20 -0000 Note: I am assuming TPK means transferable public key. Some issues that spring to mind and that you may want to consider in your proposal: This is a bit awkward if you only want to do encryption (there is no subpacket then). Some think one should always encrypt and sign, but the issue at least needs to be raised and considered. Can you clarify what keys are allowed as embedded TPKs? Just the signing key for that signature, or arbitrary keys? If the latter (for example to allow more use cases such as key rollover), then the new subpacket would be the first subpacket not to have any relationship to the signature it is contained in, which would be awkward. It would also potentially allow interesting attack vectors (injecting arbitrary keyring data). If only some keys are allowed, it needs to be specified which and how they are verified. Also, as you said, there are already some ways to transfer public keys in email as attachment or header. Some email readers already look in these places and have a GUI to import these keys. You say your proposal requires no cooperation by the MUAs, but this seems to rely on very narrow trust models not requiring any user interaction. Maybe you can expand on that topic a bit? Are the existing mechanisms obsoleted by it, or is it an alternative? If the latter, can your proposal be extended to cover existing use cases? The embedded key can contain signatures, and these signatures can again have embedded keys. This would allow for arbitrary recursion, which from experience makes for interesting bugs. Maybe you can add some considerations for that to your proposal? Thanks, Marcus On 3/25/19 10:20 AM, Justus Winter wrote: > Hello, > > I'd like to propose a new signature subpacket that contains a TPK, > let's call it the Embedded TPK subpacket. > > I see two immediate use cases: > > - If a designated revoker creates a revocation signature, she can > embed her TPK in the signature, so that it is easy to verify the > revocation without having to hunt for her TPK. > > - Some MUAs attach TPKs to emails, pEp does so too, and Autocrypt > includes TPKs in mail headers. Instead of doing that, one could > then transmit ones TPK (and those of others in the conversation) > in-band. This has the advantage of requiring no cooperation of > the MUAs, and the PGP implementations can gather the TPKs when > parsing the signatures. > > > Thanks, > Justus > > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > -- Dipl.-Math. Marcus Brinkmann Lehrstuhl für Netz- und Datensicherheit Ruhr Universität Bochum Universitätsstr. 150, Geb. ID 2/461 D-44780 Bochum Telefon: +49 (0) 234 / 32-25030 http://www.nds.rub.de/chair/people/mbrinkmann From nobody Mon Mar 25 03:48:21 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E467120421 for ; Mon, 25 Mar 2019 03:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 w-rA5x-UlRYA for ; Mon, 25 Mar 2019 03:48:13 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 D43AE12039B for ; Mon, 25 Mar 2019 03:48:12 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id v14so8497288wmf.2 for ; Mon, 25 Mar 2019 03:48:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:in-reply-to:references:date:message-id:mime-version; bh=AcEV3DWzWIf6sz5ZMdaIwKZDMLRBWVkYwvTcKstbBAc=; b=JVUbToZISwoPoeaPXC4xLqJMb1LqzNfIT1soUSrjtTYjbkaALMUqhjA20LMRfnzzlF cvNVtL7NLDzTFvPduuGpqOrVzzZE1TID/VGCc4a78GRuiURJd9q/3xoaGUpYO0/FMkrC dKizXeP/a0+ONbgpV+zgCUML/OzXZsNn2mfyg4yegTqxGDWkqJ30XXn3B7p+xITWBJBv oAmoAcxBrZ5n4xlsxYgUwDemhcrKivZlvf/KW+rnG1UKJDgk5A7d9aocJ/AuL6cTI/fF Z08JDNZF53pwFPOz1kx+sDnAk0hpKRXHbSLft6doKluxN/mabz4/wWTE6mpFsQ932l7W gffg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version; bh=AcEV3DWzWIf6sz5ZMdaIwKZDMLRBWVkYwvTcKstbBAc=; b=po3utrEQJiytBVFM2wEo5fUEnQ7hWpyPvOTnwh8G26Qd8D1AGSoT3FeeYFighxoJ1a lZRgGoo4z5agBVopnnI2b8vS2XXBJzAiaYWlUVpSGMlhsEaQBsBMTiH9a1W3ms62fJHi Mwoo57relNEU1/cCzBseAmaqqDoEI9hEr1iewM1iDlF6c8UimjjonHyNz3mx4rIWbmhe Dikls6sZl85d62lgoJOS6jebAlP6AjawRtcXUJGhKNwVHyKDiS2UHwgaDmvztrwW4fgN XD66hG+1wWTzhbSB9nIXEYnHLs3cPrnAyKrrvlVQGonGF+TkTlINeFI5XDgdH0cdHTh9 tmwQ== X-Gm-Message-State: APjAAAVqL9X+LrLBSlwFPqHD8sIqAcxRydxy7uVmdEy9r9r5Y9hZcPjN qevziRjzd8WyR15HAeZGgDw= X-Google-Smtp-Source: APXvYqwGvtXAvcPe+PU02vwlJqA+2p0/FfdUI1tydoiMUxggdZiDNi2WbKcy3/XS++HkDs6tSJh5tg== X-Received: by 2002:a1c:ca06:: with SMTP id a6mr9514081wmg.14.1553510891393; Mon, 25 Mar 2019 03:48:11 -0700 (PDT) Received: from localhost (port-92-193-51-13.dynamic.qsc.de. [92.193.51.13]) by smtp.gmail.com with ESMTPSA id a6sm3499wrp.49.2019.03.25.03.48.10 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 25 Mar 2019 03:48:10 -0700 (PDT) From: Justus Winter To: Marcus Brinkmann , openpgp@ietf.org In-Reply-To: <1e6052ec-36ba-d14d-5028-b4aac973a494@ruhr-uni-bochum.de> References: <87ef6v71jm.fsf@europa.jade-hamburg.de> <1e6052ec-36ba-d14d-5028-b4aac973a494@ruhr-uni-bochum.de> Date: Mon, 25 Mar 2019 11:48:09 +0100 Message-ID: <87bm1z6xhy.fsf@europa.jade-hamburg.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Embedded TPK subpacket X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 10:48:19 -0000 --=-=-= Content-Type: text/plain Hi Marcus :) thanks for the prompt answer! Marcus Brinkmann writes: > This is a bit awkward if you only want to do encryption (there is no > subpacket then). Some think one should always encrypt and sign, but the > issue at least needs to be raised and considered. That is true. For me, not-sign-then-encrypt is not such a prominent use case. Note that this only concerns the key-gossiping use case. Distributing the revoker's TPK with revocations is always possible. > Can you clarify what keys are allowed as embedded TPKs? Just the > signing key for that signature, or arbitrary keys? Arbitrary keys. > If the latter (for example to allow more use cases such as key > rollover), then the new subpacket would be the first subpacket not to > have any relationship to the signature it is contained in, which would > be awkward. Really? Plenty of signature subpackets deal with keys, user preferences, or can simply contain arbitrary data (notations). > It would also potentially allow interesting attack vectors (injecting > arbitrary keyring data). GnuPG's keyring is uncurated, and it uses trust models to compute the validity of userid,key-bindings. Similar, Sequoia's keystore can contain keys that have no bindings. > Also, as you said, there are already some ways to transfer public keys > in email as attachment or header. Some email readers already look in > these places and have a GUI to import these keys. You say your proposal > requires no cooperation by the MUAs, but this seems to rely on very > narrow trust models not requiring any user interaction. Maybe you can > expand on that topic a bit? Are the existing mechanisms obsoleted by > it, or is it an alternative? If the latter, can your proposal be > extended to cover existing use cases? My proposal is ment to obsolete the existing mechanisms. The fact that we now have multiple incompatible mechanisms is a bit sad, and I'm trying to extend OpenPGP so that we can have interoperable implementations again. By requiring no MUA cooperation I ment to say "no MUA modifications other than the usual PGP integration". For example, if you look at Autocrypt, implementing it means that the MUA needs to do a lot of low-level key manipulations. As I see it, this is much more work than what is already done for many MUAs. My proposal aims at bringing the key gossiping to MUAs without requiring further modifications. > The embedded key can contain signatures, and these signatures can again > have embedded keys. This would allow for arbitrary recursion, which > from experience makes for interesting bugs. Maybe you can add some > considerations for that to your proposal? I don't see that as too problematic. We already have embedded signatures, which can contain embedded signatures, and it doesn't seem to be a problem there. Cheers, Justus --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEJWpOVeSnLZetJGjniNx+MzhfeR0FAlyYsekACgkQiNx+Mzhf eR3jqAgAiSMw75l5XMC9XbNDJZo3pUycwIf09QCw6mJ3Q8wLCzWH70s1wqawSB/p OkhoOTbN2pJeg797sbJ3JwSUPSBkUUa3nrEMEsnHrEmIV9caQf5WNhrGNTUookoI oLVKgU31D1Za92pkyw4obdLPeEMzkMNxRlFRSMgi/Q8BBjzaV3t/76Xq5IZUKnUO 3oGpfEb6n+crop4/o1frRsc/+K3IfsCH2ILQFUtDAW5vRrWmB9dQLcAnA+NJTige DFFDeqF5PvqheTxxQuggD4BhMi5n7NTVOEwXaITeqUJw+k1cMFyuo4hpqh+5D7S9 Ia/QYPuszp96vhVwA1RQWRn2H6AIZA== =r755 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 25 05:25:58 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2131203E3 for ; Mon, 25 Mar 2019 05:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=my.amazin.horse 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 8xdq24vDZVMX for ; Mon, 25 Mar 2019 05:25:55 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DB77120390 for ; Mon, 25 Mar 2019 05:25:55 -0700 (PDT) Received: from localhost (dhcp253-101.wlan.rz.tu-bs.de [134.169.253.101]) by mail.mugenguild.com (Postfix) with ESMTPSA id 0D6215FACC; Mon, 25 Mar 2019 13:25:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=my.amazin.horse; s=mail; t=1553516753; bh=vR3+thURNk1bRQr4R+7kvkveZL42xRSeetW+bkcJkgQ=; h=Date:From:To:Subject:Autocrypt:From; b=P2CZRuZl62EGmXrvuvmSoCYTx943RZ3/CGpn2TfwRY/Ith5HYrmHrthOPgZ+RdHJL 6W+imGL7LVM0kdXOAlhABCjpoxhILHKyuxKq05hZVLbKdPYiDgk9L7qb+ZHzUbrm0B iJoZv9gzQyVk5AkuomnJ3exZBmSq+96Qm9q6J8sU= Message-Id: <29A44KDN1HQXS.2GVZ2DXB0KXAS@my.amazin.horse> In-Reply-To: <87bm1z6xhy.fsf@europa.jade-hamburg.de> References: <87bm1z6xhy.fsf@europa.jade-hamburg.de> <87ef6v71jm.fsf@europa.jade-hamburg.de> <1e6052ec-36ba-d14d-5028-b4aac973a494@ruhr-uni-bochum.de> Date: Mon, 25 Mar 2019 13:25:52 +0100 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Vincent Breitmoser To: Justus Winter Cc: Marcus Brinkmann , openpgp@ietf.org Autocrypt: addr=look@my.amazin.horse; keydata=mQINBFAB3UABEADCyB/vbIBA3m1Bwc yjTieEMLySwYgt54EQ2hglOocdtIhqC+b05t6sLSkwx2ukxrU2cegnCBkdyF/FZ/+Et638CUEBbf 4bjplwpt2IPLazQgjkwjMuhz0OcYDpMhwimTvh3mIl+0wzpOts6mEmMw0QZdl3RXvIW+NSynOn7q mz/fAv4Htt6lv2Ka0s6R2voyi+5U7CcIqizPad5qZVn2uxmovcFreTzFt6nk37ZbbTfvA3e5F0bR RQeH3viT5XxpJF4Y76v/Ua+5N3Kd18K0sX85rD1G7cmxR2CZ5gW1X24sDqdYZdDbf10N39UIwjJH PTeuVMQqry792Ap0Etyj135YFCE0loDnZYKvy2Y1i0RuEdTUIonIHrLhe2J0bXQGbQImHIyMgB9/ lva8D+yvy2gyf2vjRhmJEEco7w9FdzP7p3PhKrUiTjRsjHw8iV8LOCFx9njZOq9mism9ZZ16tZpx 9mXOf11HcH1RtVuyyQRS/4ytQPzwshXdSDDW6Btkmo9AbZQKC54/hSyzpp3Br2T2xDH7ecnonDB/ jv8rWuKXSTbX3xWAIrNBNDcTYaNe4jkms4HF7jJE19eRlqsXMMx6Fxvrh4TtKICwJYJ3AUmXrK3X Ti/mjqYfJ1fpBn54rWs8nhSR1fuZPD+aMlcP8BDUPlNKPKtj0DGSh3/VlnnwARAQABtClWaW5jZW 50IEJyZWl0bW9zZXIgPGxvb2tAbXkuYW1hemluLmhvcnNlPokCOAQTAQIAIgUCVTNZmgIbAwYLCQ gHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQe9GDIN6t+hHcVg//aeiijNqsQ3pjbFQn3VvND7hNfJ vrVcLZ+U4kOzXPF818aVdOnDyNXyE17vBDDcvaZ730sCsZIRZJ3KhUJ+nPvdttKjUIGLARmx+pA3 Jl3IIv2uLtOb3I0TMuyfIGJVGF+q10/CeDMKVjKlmyOVrR0opkel+KEoN7VLq3Hf3zPKENO1HBgp LHeP31tlb9cgs+u4o2wLrVe9myHbuFBW7EjWbSvdz2zliwbsFeFVLMNcWrKAU0GkkiH69SgnwmXU RkhGma4L27GLtkHHufsxfbcPqPtmtCttsGZU4EmrghGUqVyDOxnn8ZqybzLrRfpin+OCIX+aHJz5 r2L8qtrP0LorNMX3Gopd26vfhNvq/wq8xk++bW1R5FmkaUhx9h+DhO2ybcg7p/E8JHc8zrWv+bb3 0o9lkrOaU8GxXrgtb1cjtbb+MxFvjm0Elw7MSZDG7sF/APFU6cwuIA9Nai/OGAUCSt/W2ecS8Zox cWWbGSEiDvjtEctkpmHjfVuGoL34966Olm41VdH+NjgoSYUJKx4Mty8DRcZxdyoXll84LvDkEEYK ZqOIACsJf8CDFvUkmhXc+moCj15Yxtj3/RslRVEiOUyrpDwB72zWcZG8YnzoyGxhcRIc/gFejO/y SI8bzCpYngeuTb5NjFG+ChGiInHbQcFeHBlaHtKi2o/B5axIO5Ag0EVDvOgQEQALJby/ztliToGE u1lslvWQUQ6teKZVUQ7hy9bM4N83G0AGLatUBHtY6PkJBe4XkIw3sK7LoFCV2W4GSt4zWp9l+kG3 /J8Ow7EFjN0F7DrCg0M0lMg9dQz9jYSoBR8skaH3BRzCq9AKIVKV94poL/G65289L7zKDHoZnnyF qbBtedYZir0SZx+kiouZ1qnmxRPaYmH2fkuiuvYEAyzLDLYM8F5gQhdZM4YVtuvSICYPet0z4CDi JX/vZmDi3AzzoEVaKeAM/0H9f9Ni547J2+8dZSllgTrA+fq0aMJVScAObIxTAQtEq0DoNBzPpVrm W10b4bmgePrAvNkifqSr5StymSBgwvoeW6GrJiyN4XhoLOadZzwgjqioR1nXw5tXtrr5sYdkZ06b 1WWHkxtu1hFTdLC7RYNxY07ytLNM+C2lplCwCwlWB7RwI9BL1Dhre4kv8uaaX2Gksaq9mDf9MSDW qQ0TJ/RAiwMGmFrzBEYI1J2Oyeshi/dqW4/OiZAukOIlxOnt6u8zU2KL6Qjxqqna0oTbS4Zv3fRd YkuUCL6CDEJdkuRAiW+Gw+lKcMjXqApEqixhaDkoB/kwtu+2gIFTzAxMfwFN1YtNc0kJZWnFkGIW MrrwTcOwAFzlFz7wn/EyMFtg+ERcqMX0+olXDwM8MODI2+BzulPuEDEteCw09hABEBAAGJAh8EGA ECAAkFAlQ7zoECGwwACgkQe9GDIN6t+hFjuQ//UQyg49f8TytUYQaBb8R0UfI+KhQFs1Nsz2z8a3 0CD1MeiHHYWdAcomVvTkg4g5LbnYHVDrj/XagY3FN/AIE97usFbsTG+rsWAOLi7N2dN2ehWZ634k MvrgyC9uTiOdkw31+B8K5MpyySgD8e6SAzRfiu06/bcQOUyJifw8Hudpj9by4uyGhSH+kHu4afrp OduUighbsGFtcuRwwQ/w/oSk68XvPUgiOQWMZh/pVoXdFyFvrt/hgArCi8dfy5UPK58nl7jPnu/I uQXrJ50nNAFIIxPVeo2/B83KAnEZPU+qWZsdba0V+FIIQQVizLtQFMuJJk4/UTAOfJ2tBpQ9PADX 6/scqDE7unXNWdxcHTjK7KmWjXC8CyhGOx8V/rb7Ial4mZo4cTED6SNlO7dV1XYwnSctL2HCYNM3 RUe4eJ7JWuu7/Nbf6yip2eq7BQKZ9hAH/se/OSZNYsEkZ4pxUc8W5U3uAZImUwC6L74SM0jBZIuD mQhOYX6sZZ6urIn/MYlj4/hqSBFS4vTK7nXRLmtr7+5T5U5srVseUiYc+l9pu9/XD8zGIu+M2xEd 41NwP44GDQTQm0bFljRv5fSblwmi56YHPFQUIh2RZNX3kOJgeyQ3enw5uY+7ocKRVP38hpnffliL lJcO6TtHWnElS3pACbTQM0RHJox3zqU3q6K3c= Archived-At: Subject: Re: [openpgp] Embedded TPK subpacket X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 12:25:57 -0000 > My proposal is ment to obsolete the existing mechanisms. The fact that > we now have multiple incompatible mechanisms is a bit sad, and I'm > trying to extend OpenPGP so that we can have interoperable > implementations again. So what your proposal brings to the table is in-band key distribution without MUA involvement, but hinges on the use of signed-only mails. Given the rather terrible state of signed-only messages, which is likely what caused both Autocrypt and PEP to omit support for them, I'm sceptical of this approach's potential to do much for the unification of key distribution mechanisms. Some more context: I chose to actively discourage signed-only mails in K-9 Mail, due to 1) the friction they cause with recipients ("your mail contained a weird attachment, is this a virus?"), and 2) limited usefulness in practice due to brittle reliability and non-existent network effect. That said, I can definitely see how self-contained signatures could be useful to have for this and other purposes! > For example, if you look at Autocrypt, implementing it means that the MUA > needs to do a lot of low-level key manipulations. Can you elaborate on this? We designed Autocrypt to be as agnostic of OpenPGP implementation details as possible, especially for public key management it can get away with treating keys as opaque bytes blobs. IINM the required API from an OpenPGP implementation should be complete with just "get minimal own public key", "check TPK integrity", and "encrypt to keys (given as blobs)". In practice OpenPGP support in MUAs tends to be more involved than that, but I don't think there is an actual "need" for that. - V From nobody Mon Mar 25 05:27:08 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F52120396 for ; Mon, 25 Mar 2019 05:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ruhr-uni-bochum.de 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 YqVc29rGtktS for ; Mon, 25 Mar 2019 05:27:03 -0700 (PDT) Received: from out2.mail.ruhr-uni-bochum.de (out2.mail.ruhr-uni-bochum.de [IPv6:2a05:3e00:c:1001::8693:2ae5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCFD9120390 for ; Mon, 25 Mar 2019 05:27:02 -0700 (PDT) Received: from mx2.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by out2.mail.ruhr-uni-bochum.de (Postfix mo-ext) with ESMTP id 44SYRS0rMTz4x0X for ; Mon, 25 Mar 2019 13:27:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ruhr-uni-bochum.de; s=mail-2017; t=1553516820; bh=rdz4g4+SWywoYNbGB/tx11exeL6TUYEZMTfSd5JrOEI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=jeeQu2AZm6OpPQyasycf/oXyhDaJpmD26HCJMcYFsEe6h3XlKbr8Tnm/V3xdPW0tB HnOX5Q8oMvfCySRUmlBBQogNuDiET/MzcZsLrGuPZfj58EPk0ZVoqRd29mTfbl3EhM AFXapofs9xp4fw54yyEwia7KjvdxfVr3vD3snFxQ= Received: from out2.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by mx2.mail.ruhr-uni-bochum.de (Postfix idis) with ESMTP id 44SYRR6kfDz4wyC for ; Mon, 25 Mar 2019 13:26:59 +0100 (CET) X-Envelope-Sender: X-RUB-Notes: Internal origin=134.147.42.227 Received: from mail1.mail.ruhr-uni-bochum.de (mail.ruhr-uni-bochum.de [134.147.42.227]) by out2.mail.ruhr-uni-bochum.de (Postfix mi-int) with ESMTP id 44SYRR6Bt6z4wnr for ; Mon, 25 Mar 2019 13:26:59 +0100 (CET) Received: from [192.168.1.102] (phoneyspot-457.nds.ruhr-uni-bochum.de [134.147.159.61]) by mail1.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 44SYRR5HL8zyt6 for ; Mon, 25 Mar 2019 13:26:59 +0100 (CET) To: openpgp@ietf.org References: <87ef6v71jm.fsf@europa.jade-hamburg.de> <1e6052ec-36ba-d14d-5028-b4aac973a494@ruhr-uni-bochum.de> <87bm1z6xhy.fsf@europa.jade-hamburg.de> From: Marcus Brinkmann Openpgp: preference=signencrypt Autocrypt: addr=marcus.brinkmann@ruhr-uni-bochum.de; keydata= mQINBFZU6WABEADoVonKbB/tV0v25cm39DaSZyN7it70RhTZHLESbpDiHCwiAMi74MK/HB/q VR9LZDkTDF1x5xUnxxMHa2rpxO329dlk5dQFq1iELxIC/yBCEh5HMLT5MkWqwb8UkINYpaFU csQdPvdC2RzZ4Wt5/xX/6mvSnA4g7hSmUKwIiDX6489Fj5jHK3i0UQFnzKty3O7mqSbedTHs ym2q6fPcIlEOvU6unzxJRK4bgfW2NBM6aMqgLeQkKYIkd1Q/OXEWCXC4hQJepak+n34ChIrV RRHIBJ0GHRkEgHQgQUqPLS0fJlMYCaSZFmOAaqmigxVn1ErG3jTnFQPbPkfE5SCssFP2grNV N1ikJzOEpBLYA/4pOaJzSnZ0xx9aKPdUsyBksKmCsLQNiRt4ZTNFpJ2DJ8NbXYAFkrcu15og lrB//CVQj3CfkzUbpyfcwJHAho1K6XaPybI14znuorTJF3ml0qDd3XDkcmnF58s4hfvGHQtz +CEW+85gUF+T9jKLpwNGcNdBhbvdE6d3cSbR7dXeZsxiA4AmqqEhH6SnVmkSqmhX4+k6RksE MrHJnzefTyA4kXIR2QvD60nZXqta35VhhCzIcpkUpxcwABBR7C8nCxiGV7wNmGECgHv+Zl/O hQhWF1Ld1G93xCg7D+Nz0RerRdwtBOUatmCp+2HRTcRXNOW8jQARAQABtDZNYXJjdXMgQnJp bmttYW5uIDxtYXJjdXMuYnJpbmttYW5uQHJ1aHItdW5pLWJvY2h1bS5kZT6JAjgEEwECACIF AlZU6WACGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEIiwjVpXtiFAHDUP/0PuDwhn Cyn7b2S7Lrn0BBmi3LOS4ioalCZkV6BenkXydeGwJ9CVVix9WEbiLzCz/DHfvz97l/T9lxcM bACc1tX5a+qvqydzKd2eXFnVdH1JaihqdhG7sWYi22H1uWSyWbHd3rBZaDAts5Qialdg+WC0 kHh9pkmmlUE3BIkTaIOA9k4J93hz4QDOEO7xjB9XMOIRuasZ0lOOPraezS/pKLaQHlzPJZfo QEGL3ndn8U1FXZgR2DWhGtbClEvLaNXJ7RYhIlCeEwCwsTuGg48iDYC0+phvj/nwhZV60+Eb lR4Kux4DjY65s4Rp4kIzh51PRE+bLHtULPx1x9X1x5ZekYQdgwf6doBIIauARZFaxI6dt3i+ HSMjpga3k2Xn5iCaf6NeG1J2bh9sEAH7nntibOOp4sT8YR2SiQ5ab8PnDkydwbghUZcJ39a/ CZnN3f1RFeRX6d3zbfULPsf7o0LM/IvNKFvBoVzVb3AVYdhe5FNOE0DfhOe8lpE88ofu+es6 ECGumfR8UEcQc/O4dSyprngxZjjEdgdo5KqUkCEeGM8lVp+EFcmtLME3uqFhsUihk3YfF9Ni vZ0/0ZcLsmMp3zCZ9wS6HWr2UTkYrgc7Nr3YBClDs9W/jurcSPMmpwwhq2ycWaMMMPqULS4c U2vhGKh6JDPqfIfXFQIfhiVwCMx1uQINBFZU6WABEAC3meKoeQn4r37Z1WCvl/lRVgwYLIEw GX94WCZODxPPEy2zTWStj45yv1ZrSI0HyAqssZzXPelOFJzlM8M+iccxIMRgjnnGJJR0YqYU draf1Z2YQk/x2WjYNUg0blChdyeqwBhLAQKtnPOKkTPZBBGzPjsS+JeB8yN5r4vouFGMG+Cm YFUy4oCmcmuUrdLm9NlzM5ituyTJsPG9CDO834e4qlZsNW/yEzyPsYDW0PxJxgEe/WjLsDJ0 aiwaDhBpR8/i2FfEUTGXl+6wvdXR9lhddBoiUCVlNRu9jiKVxv2JVJepcZa9B/atJwcsDAkZ JgnjP0qRybixx/wo14KromgWVBGwpZ89sFEgZF6HcxPMKuWtieIORzs9kb0jpMFi1hW9xi60 UBHikrpDG9MnwA35d1lg/9kUlrF1nqTnyoz43UxntlgQejl6JcBR2Poaaib3ZtCR34yxslFz 4znXBermA2eEvusEmjYJlxPWozW18grbSYUr1tCmjvKZAIMrspVx37+WSm/4fy8Mq9iqhkIw eFQM10GL+fRQOGJTpSY/KiGxmkaTPtj9iaovJOcGAjUzzreGhi4toIrWWULPNKS6vuV4VgMB F4XxIcVqC9I43yzJ6/cYciwL9bxoWQ4EpHuIG3sewvOWbceeDO9j9DRSd9E6GX67NzrruDPX Ooge2QARAQABiQIfBBgBAgAJBQJWVOlgAhsMAAoJEIiwjVpXtiFAHBwP/3x5953X/1jR2Aeg R6oHSF0HAD8kMnKLP5cwLqrOzUpCwqzFGBCbYdvxrWG106jyvcZdUvtBSGd8n1FuE2WrpQrK gNjdRG65cN2kduk/w66Oq57EqSuO/r6OnadG9hgVZ1YP/QUsL6n4oF7coD0CJiH98UyLw1yP 3Em1ONX8ditvMVHNudVC1VoEN1BFjIX9VWqWoU843vPct9wKi6jLYHHAX3UpnEJtfqLHCj55 4s+0yhMhoaAIfNQZWU9iKzldM6Y0j8DJ/YBSThhw9S/TX7mClhXArJ/iPJSr6FPhlQMMcZRQ aSiQu1gDL76I5G03SkBWCnXbSpeNtTeMiSpsA58c8rpr2T4giCiV29FPgEj4We2/jBrBcwWA /XjSLE2RNOnF2G65dVxHAlaCc84lC2+bh9kVU+Tb+9YDWfHyNO+pNk/Lpaef2Kg6ScKmte6+ wVkWQZFTU8mgkHZqFvQk29RnV02phRTM0ryvWWldNgf3vzztS3iyD3GrJCPcxjm24cAflp+7 JfQ4qV/ec598k++HI4r3SfmSFKFcsxh+073p+oVjs5kIHxM0SExdjKewLOE3BKQYjn1r17xW XogKlIGbTEluQ4Odyh4n88/iA8ZLNPKjvjno7UuwBsZyJxdaTOXlQYt+ZRZNfIBSWqv0U9fY tp9qPuy4vCfkycCucIgO Message-ID: Date: Mon, 25 Mar 2019 13:26:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <87bm1z6xhy.fsf@europa.jade-hamburg.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.4 at mail1.mail.ruhr-uni-bochum.de X-Virus-Status: Clean Archived-At: Subject: Re: [openpgp] Embedded TPK subpacket X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 12:27:06 -0000 On 3/25/19 11:48 AM, Justus Winter wrote: >> Can you clarify what keys are allowed as embedded TPKs? Just the >> signing key for that signature, or arbitrary keys? > > Arbitrary keys. > >> If the latter (for example to allow more use cases such as key >> rollover), then the new subpacket would be the first subpacket not to >> have any relationship to the signature it is contained in, which would >> be awkward. > > Really? Plenty of signature subpackets deal with keys, user > preferences, or can simply contain arbitrary data (notations). I haven't done an exhaustive analysis, but on a first glance those seem to be related to the signature. For example, user preferences are part of binding signatures. >> It would also potentially allow interesting attack vectors (injecting >> arbitrary keyring data). > > GnuPG's keyring is uncurated, and it uses trust models to compute the > validity of userid,key-bindings. Similar, Sequoia's keystore can > contain keys that have no bindings. GnuPG's keyring was very helpful in my enigmail signature spoofing attack [1]. Just saying :) [1] https://neopg.io/blog/enigmail-signature-spoof Thanks, Marcus -- Dipl.-Math. Marcus Brinkmann Lehrstuhl für Netz- und Datensicherheit Ruhr Universität Bochum Universitätsstr. 150, Geb. ID 2/461 D-44780 Bochum Telefon: +49 (0) 234 / 32-25030 http://www.nds.rub.de/chair/people/mbrinkmann From nobody Mon Mar 25 05:38:53 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3136120390 for ; Mon, 25 Mar 2019 05:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=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 zJwplwBj5eM7 for ; Mon, 25 Mar 2019 05:38:49 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 92C811203C3 for ; Mon, 25 Mar 2019 05:38:49 -0700 (PDT) Received: from p57b22663.dip0.t-ipconnect.de ([87.178.38.99] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1h8OsI-0004TT-1A; Mon, 25 Mar 2019 12:38:46 +0000 Date: Mon, 25 Mar 2019 13:38:45 +0100 Message-ID: <87va07gmcq.wl-neal@walfield.org> From: "Neal H. Walfield" To: Vincent Breitmoser Cc: Justus Winter , Marcus Brinkmann , openpgp@ietf.org In-Reply-To: <29A44KDN1HQXS.2GVZ2DXB0KXAS@my.amazin.horse> References: <87bm1z6xhy.fsf@europa.jade-hamburg.de> <87ef6v71jm.fsf@europa.jade-hamburg.de> <1e6052ec-36ba-d14d-5028-b4aac973a494@ruhr-uni-bochum.de> <29A44KDN1HQXS.2GVZ2DXB0KXAS@my.amazin.horse> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] Embedded TPK subpacket X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 12:38:52 -0000 Hi Vincent, On Mon, 25 Mar 2019 13:25:52 +0100, Vincent Breitmoser wrote: > > My proposal is ment to obsolete the existing mechanisms. The fact that > > we now have multiple incompatible mechanisms is a bit sad, and I'm > > trying to extend OpenPGP so that we can have interoperable > > implementations again. > > So what your proposal brings to the table is in-band key distribution without > MUA involvement, but hinges on the use of signed-only mails. Given the rather > terrible state of signed-only messages, which is likely what caused both > Autocrypt and PEP to omit support for them, I'm sceptical of this approach's > potential to do much for the unification of key distribution > mechanisms. This is *one* of the things that this proposal can help with. Note: in the context of Autocrypt, this could help with "autocrypt gossip"; I don't foresee it replacing autocrypt headers. > 2) limited usefulness in practice due to > brittle reliability and non-existent network effect. I agree that they *currently* have limited usefulness. But, if companies started to actually sign their outgoing mail, this could help combat phishing. I think we should consider both the future's potential and today's limitations, and not be driven be either exclusively. From nobody Mon Mar 25 05:51:43 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9A51203E3 for ; Mon, 25 Mar 2019 05:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 qlX3DOJL6_Im for ; Mon, 25 Mar 2019 05:51:39 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 CBD41120403 for ; Mon, 25 Mar 2019 05:51:38 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id y7so5879362wrn.11 for ; Mon, 25 Mar 2019 05:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=zuivPlRcbMxAnL0cq+37zQ0jABAu4l/wEyNB1TRE/fs=; b=m6cNHXlvn7hF6rlNumDm5KiCqHB0iUjBpSvGugbwWcwmzBgyTUou90bFVJoh/9z+yx vXBC2ClWCiAl7sh/qw5Z3+/5FzT4GvsTAqqfibFWflqbElr/AmaDkSfIJ7lQA/CsXPjv QbvvAuuHfWVLjmygxsyLofiNuSDKxjpN/yxTHUjmc6yaJWxpGwApe78b5McPF1tKw2to Qzv/j/54Ud87ZGG0BQD5AZmd9b43IQicy0uyNyfackmKXWCLBVTNnyKVD9USlB/CThc1 pGDcgHsatCZcUaWrKVjF9ITFyWNFMSpR4iDolyhvgxmdS84+KRqbhYklNOGb/lZ8bvKo aQ/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=zuivPlRcbMxAnL0cq+37zQ0jABAu4l/wEyNB1TRE/fs=; b=qZhg0mc7cfY4xz6VOK0y63Wj9N60TDtD1akCGCiABNMgaSzi/RdmzEZKavQkNbT5DK yDkfjZjxj2GCl9mBY5BM9TB1jVZy3FxdJNcMvDpMogbRUxUbgrxEE/OO5wX4URp7uptX rDRQ9Ir7mBMpIORtJTOYeOlIrHE2zUnpXMgv+WUjUAUsmMLv+Tw/575GyztfSOa0KYLu XEWO/GLS2yNlNroPPryPhkbx44oxKn0nAs+rCkP8/tNxB09lJ9iZDROUkvuo+cONQHtG yJdcjjHjmdVAXKdLYRnXoWPO6gImuzq9FfW1YESiZlhdf4WyvwKI+rOBXXpiQshSyhJ8 HCfA== X-Gm-Message-State: APjAAAWvQ7s0ZBPvau+Z75021RCBeTKPuNm0L/GdMOyl40HcohAGVj5F UiUJNah4f4m27SZF8mTClRtIqvua X-Google-Smtp-Source: APXvYqz8pxSpKqJ5q5SUFzN40hE5UJJq3jLJBBVjNmMUMof2iFH8MtMnh3LFV2k0bYrJISCcJA2/dA== X-Received: by 2002:adf:f1c6:: with SMTP id z6mr15111866wro.232.1553518297367; Mon, 25 Mar 2019 05:51:37 -0700 (PDT) Received: from localhost (port-92-193-51-13.dynamic.qsc.de. [92.193.51.13]) by smtp.gmail.com with ESMTPSA id z11sm5680446wmf.12.2019.03.25.05.51.36 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 25 Mar 2019 05:51:36 -0700 (PDT) From: Justus Winter To: Vincent Breitmoser Cc: Marcus Brinkmann , openpgp@ietf.org In-Reply-To: <29A44KDN1HQXS.2GVZ2DXB0KXAS@my.amazin.horse> References: <87bm1z6xhy.fsf@europa.jade-hamburg.de> <87ef6v71jm.fsf@europa.jade-hamburg.de> <1e6052ec-36ba-d14d-5028-b4aac973a494@ruhr-uni-bochum.de> <29A44KDN1HQXS.2GVZ2DXB0KXAS@my.amazin.horse> Date: Mon, 25 Mar 2019 13:51:35 +0100 Message-ID: <878sx36rs8.fsf@europa.jade-hamburg.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Embedded TPK subpacket X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 12:51:41 -0000 --=-=-= Content-Type: text/plain Vincent Breitmoser writes: >> My proposal is ment to obsolete the existing mechanisms. The fact that >> we now have multiple incompatible mechanisms is a bit sad, and I'm >> trying to extend OpenPGP so that we can have interoperable >> implementations again. > > So what your proposal brings to the table is in-band key distribution without > MUA involvement, but hinges on the use of signed-only mails. Why would it be restricted to sign-only messages? My proposal also works with OpenPGP's usual sign-then-encrypt messages. Marcus'es point was about it not working with encrypt-only messages. >> For example, if you look at Autocrypt, implementing it means that the MUA >> needs to do a lot of low-level key manipulations. > > Can you elaborate on this? We designed Autocrypt to be as agnostic of OpenPGP > implementation details as possible, especially for public key management it can > get away with treating keys as opaque bytes blobs. IINM the required API from an > OpenPGP implementation should be complete with just "get minimal own public > key", "check TPK integrity", and "encrypt to keys (given as blobs)". In practice > OpenPGP support in MUAs tends to be more involved than that, but I don't think > there is an actual "need" for that. "get minimal own public key" according to https://autocrypt.org/level1.html#openpgp-based-key-data seems pretty involved to me. I'd be surprised if one can even implement that using the various OpenPGP implementations out there. Same for the filtering of keys to be gossiped. (I just noticed that I cannot do Autocrypt with my key because my primary key is not signing-capable...) Justus --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEJWpOVeSnLZetJGjniNx+MzhfeR0FAlyYztcACgkQiNx+Mzhf eR1/ngf/QoDTOkBxIwzfIqUoSGXywtJ6pMwJvmWGEDv9vrTMa8EgBzviYl28uv/r vcWFzt+dhj8qyujEE7b2FU4bjkRYSmullGGCIVaiomqQoHfl3dMnz2rgNbcAmpX0 3UIv8CZr0Ii4IG0Y+JPxhLexYgsRe6CJeHMbryA9vA0vhZocE/MxPZAL6cJa0qKf IiU4jya6LRDwpzFcr34ecSZ5Jeprbh8vtNKzDgGJ2bYVG2GAh1ICD2/sApQps17v +SQ2o7wY36gFukzhJ0I4Ex0vRWF0TTj+duoXBskZlmVg87EVmZ7p+g7cCuEhl+MS vGMIuJ9uyacMuRtcKNqqqLpWv3P9bQ== =GXJ3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 25 07:32:07 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB35A120407 for ; Mon, 25 Mar 2019 07:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=my.amazin.horse 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 veU5R29SnrG4 for ; Mon, 25 Mar 2019 07:32:02 -0700 (PDT) Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3E1F1203BB for ; Mon, 25 Mar 2019 07:32:02 -0700 (PDT) Received: from localhost (dhcp253-101.wlan.rz.tu-bs.de [134.169.253.101]) by mail.mugenguild.com (Postfix) with ESMTPSA id AE2305FACC; Mon, 25 Mar 2019 15:32:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=my.amazin.horse; s=mail; t=1553524320; bh=1P2yXB5SNd3Ow5DlMGicrQlZ/aVYfOOFzAzROjWesig=; h=Date:From:To:Subject:Autocrypt:From; b=gnryrtOCulhWOTTR24G+yFRn+rF/tJnyDpAJs7J3aPmFJZP2ch0HXHT/4NjWsN8Rh k4Ixuh5awycY7OrfYZmo1RINDCObw0wlTEcRWvfuyYkueliUbHvR+rD1/IZhwiffiT smY6aINTX1fKC/qbza6RSc9704ZbUh0P91JN3It0= Message-Id: <2WXMWITJ03MHX.20OZYVK4V626V@my.amazin.horse> In-Reply-To: <878sx36rs8.fsf@europa.jade-hamburg.de> References: <878sx36rs8.fsf@europa.jade-hamburg.de> <87bm1z6xhy.fsf@europa.jade-hamburg.de> <87ef6v71jm.fsf@europa.jade-hamburg.de> <1e6052ec-36ba-d14d-5028-b4aac973a494@ruhr-uni-bochum.de> <29A44KDN1HQXS.2GVZ2DXB0KXAS@my.amazin.horse> Date: Mon, 25 Mar 2019 15:31:58 +0100 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Vincent Breitmoser To: Justus Winter Cc: Marcus Brinkmann , openpgp@ietf.org Autocrypt: addr=look@my.amazin.horse; keydata=mQINBFAB3UABEADCyB/vbIBA3m1Bwc yjTieEMLySwYgt54EQ2hglOocdtIhqC+b05t6sLSkwx2ukxrU2cegnCBkdyF/FZ/+Et638CUEBbf 4bjplwpt2IPLazQgjkwjMuhz0OcYDpMhwimTvh3mIl+0wzpOts6mEmMw0QZdl3RXvIW+NSynOn7q mz/fAv4Htt6lv2Ka0s6R2voyi+5U7CcIqizPad5qZVn2uxmovcFreTzFt6nk37ZbbTfvA3e5F0bR RQeH3viT5XxpJF4Y76v/Ua+5N3Kd18K0sX85rD1G7cmxR2CZ5gW1X24sDqdYZdDbf10N39UIwjJH PTeuVMQqry792Ap0Etyj135YFCE0loDnZYKvy2Y1i0RuEdTUIonIHrLhe2J0bXQGbQImHIyMgB9/ lva8D+yvy2gyf2vjRhmJEEco7w9FdzP7p3PhKrUiTjRsjHw8iV8LOCFx9njZOq9mism9ZZ16tZpx 9mXOf11HcH1RtVuyyQRS/4ytQPzwshXdSDDW6Btkmo9AbZQKC54/hSyzpp3Br2T2xDH7ecnonDB/ jv8rWuKXSTbX3xWAIrNBNDcTYaNe4jkms4HF7jJE19eRlqsXMMx6Fxvrh4TtKICwJYJ3AUmXrK3X Ti/mjqYfJ1fpBn54rWs8nhSR1fuZPD+aMlcP8BDUPlNKPKtj0DGSh3/VlnnwARAQABtClWaW5jZW 50IEJyZWl0bW9zZXIgPGxvb2tAbXkuYW1hemluLmhvcnNlPokCOAQTAQIAIgUCVTNZmgIbAwYLCQ gHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQe9GDIN6t+hHcVg//aeiijNqsQ3pjbFQn3VvND7hNfJ vrVcLZ+U4kOzXPF818aVdOnDyNXyE17vBDDcvaZ730sCsZIRZJ3KhUJ+nPvdttKjUIGLARmx+pA3 Jl3IIv2uLtOb3I0TMuyfIGJVGF+q10/CeDMKVjKlmyOVrR0opkel+KEoN7VLq3Hf3zPKENO1HBgp LHeP31tlb9cgs+u4o2wLrVe9myHbuFBW7EjWbSvdz2zliwbsFeFVLMNcWrKAU0GkkiH69SgnwmXU RkhGma4L27GLtkHHufsxfbcPqPtmtCttsGZU4EmrghGUqVyDOxnn8ZqybzLrRfpin+OCIX+aHJz5 r2L8qtrP0LorNMX3Gopd26vfhNvq/wq8xk++bW1R5FmkaUhx9h+DhO2ybcg7p/E8JHc8zrWv+bb3 0o9lkrOaU8GxXrgtb1cjtbb+MxFvjm0Elw7MSZDG7sF/APFU6cwuIA9Nai/OGAUCSt/W2ecS8Zox cWWbGSEiDvjtEctkpmHjfVuGoL34966Olm41VdH+NjgoSYUJKx4Mty8DRcZxdyoXll84LvDkEEYK ZqOIACsJf8CDFvUkmhXc+moCj15Yxtj3/RslRVEiOUyrpDwB72zWcZG8YnzoyGxhcRIc/gFejO/y SI8bzCpYngeuTb5NjFG+ChGiInHbQcFeHBlaHtKi2o/B5axIO5Ag0EVDvOgQEQALJby/ztliToGE u1lslvWQUQ6teKZVUQ7hy9bM4N83G0AGLatUBHtY6PkJBe4XkIw3sK7LoFCV2W4GSt4zWp9l+kG3 /J8Ow7EFjN0F7DrCg0M0lMg9dQz9jYSoBR8skaH3BRzCq9AKIVKV94poL/G65289L7zKDHoZnnyF qbBtedYZir0SZx+kiouZ1qnmxRPaYmH2fkuiuvYEAyzLDLYM8F5gQhdZM4YVtuvSICYPet0z4CDi JX/vZmDi3AzzoEVaKeAM/0H9f9Ni547J2+8dZSllgTrA+fq0aMJVScAObIxTAQtEq0DoNBzPpVrm W10b4bmgePrAvNkifqSr5StymSBgwvoeW6GrJiyN4XhoLOadZzwgjqioR1nXw5tXtrr5sYdkZ06b 1WWHkxtu1hFTdLC7RYNxY07ytLNM+C2lplCwCwlWB7RwI9BL1Dhre4kv8uaaX2Gksaq9mDf9MSDW qQ0TJ/RAiwMGmFrzBEYI1J2Oyeshi/dqW4/OiZAukOIlxOnt6u8zU2KL6Qjxqqna0oTbS4Zv3fRd YkuUCL6CDEJdkuRAiW+Gw+lKcMjXqApEqixhaDkoB/kwtu+2gIFTzAxMfwFN1YtNc0kJZWnFkGIW MrrwTcOwAFzlFz7wn/EyMFtg+ERcqMX0+olXDwM8MODI2+BzulPuEDEteCw09hABEBAAGJAh8EGA ECAAkFAlQ7zoECGwwACgkQe9GDIN6t+hFjuQ//UQyg49f8TytUYQaBb8R0UfI+KhQFs1Nsz2z8a3 0CD1MeiHHYWdAcomVvTkg4g5LbnYHVDrj/XagY3FN/AIE97usFbsTG+rsWAOLi7N2dN2ehWZ634k MvrgyC9uTiOdkw31+B8K5MpyySgD8e6SAzRfiu06/bcQOUyJifw8Hudpj9by4uyGhSH+kHu4afrp OduUighbsGFtcuRwwQ/w/oSk68XvPUgiOQWMZh/pVoXdFyFvrt/hgArCi8dfy5UPK58nl7jPnu/I uQXrJ50nNAFIIxPVeo2/B83KAnEZPU+qWZsdba0V+FIIQQVizLtQFMuJJk4/UTAOfJ2tBpQ9PADX 6/scqDE7unXNWdxcHTjK7KmWjXC8CyhGOx8V/rb7Ial4mZo4cTED6SNlO7dV1XYwnSctL2HCYNM3 RUe4eJ7JWuu7/Nbf6yip2eq7BQKZ9hAH/se/OSZNYsEkZ4pxUc8W5U3uAZImUwC6L74SM0jBZIuD mQhOYX6sZZ6urIn/MYlj4/hqSBFS4vTK7nXRLmtr7+5T5U5srVseUiYc+l9pu9/XD8zGIu+M2xEd 41NwP44GDQTQm0bFljRv5fSblwmi56YHPFQUIh2RZNX3kOJgeyQ3enw5uY+7ocKRVP38hpnffliL lJcO6TtHWnElS3pACbTQM0RHJox3zqU3q6K3c= Archived-At: Subject: Re: [openpgp] Embedded TPK subpacket X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 14:32:05 -0000 > Why would it be restricted to sign-only messages? My proposal also > works with OpenPGP's usual sign-then-encrypt messages. Marcus'es point > was about it not working with encrypt-only messages. I didn't think it would be restricted to that, but I assumed this would be a common purpose for the mechanism given you were talking about obsoleting key management/discovery schemes. > "get minimal own public key" according to > https://autocrypt.org/level1.html#openpgp-based-key-data seems pretty > involved to me. I'd be surprised if one can even implement that using > the various OpenPGP implementations out there. Same for the filtering > of keys to be gossiped. Well, "export minimal public key" functionality should probably be part of a general purpose OpenPGP implementation. You're right that it might be tricky to get this particular flavor right, but it's not super important to have the exact structure in practice (however, see below). > (I just noticed that I cannot do Autocrypt with my key because my > primary key is not signing-capable...) Indeed, we should change that to a SHOULD. Looking at it now I'm surprised we're so strict there, it's good to have a proper recommendation but any minimal key format should be at least acceptable there. Thanks for the hint, I'll make a PR :) - V (I'll drop this line of questioning here since it's not really on topic) From nobody Mon Mar 25 14:09:13 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04CE1120824 for ; Mon, 25 Mar 2019 14:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=metacode.biz 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 4-Js3sYyQHSI for ; Mon, 25 Mar 2019 14:08:59 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 5ECB812082F for ; Mon, 25 Mar 2019 14:08:59 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id p14so8208515ljg.5 for ; Mon, 25 Mar 2019 14:08:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metacode.biz; s=2017; h=from:openpgp:autocrypt:organization:to:cc:subject:message-id:date :mime-version; bh=X1aKZwBu10v5IIHSEWezPiPHgPTHQ5cqxy8DkbTFumo=; b=xAVhiFtFFgJmOloQ73oCPj4wqr6M4QnobayP8hd3URXwsg8zEqo4FRMxzfPTkzEzAS 7vuwCXYAgvsJw2ACA7fBiX8GLwoYuKu3YEb4lPm8cOKqmi9S2YxzmZAEuQOBBH7oDlNH KI89U0QrRiGbjqAK8dCllBS44OINwkZ3vYmp6p7qpVUOxfnA26LEAh0JLF3/C1gEqkmR k+i6S3D/X7jW660eVZmBZsbaaKTRjWmm2CMq28tmLY/PU8igQMYTa+R21faumyuYHK/7 ipws2lUF4QZSatT+5PeL8ejEoTyeo36z7Ckv54J3mC/EMZiKfLYK3i2YQ654h/xGVN9F KKeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:openpgp:autocrypt:organization:to:cc :subject:message-id:date:mime-version; bh=X1aKZwBu10v5IIHSEWezPiPHgPTHQ5cqxy8DkbTFumo=; b=cd/GzmgQ+Cw2iWHAlMiQGj6iJe84dIpi7epIIM1ZrDbfncKYUFOFl3tA7wmEdEU6SQ mRTmSCELgWJEEiSM8s62SMbACLz5brAWzQRSz1fYsG+esujFTtipM8SQcRakCC7XX0VR IwMJvSHmM8/nC4JIRLi/xfONdapmKD6X2CJysfoIIktnQG80fG1u7hCIIPSZQRBEKI1R WUymJvU+BZ2Ap84v/IWifQJRDLqy/mqkWV36FgtrbXYBgMLxR+pDcklepXSDumTHZLGr Y4O8voOIpduijdCDrMtcMYcVg276MdVq+Vd4hkrclkAwchqdOeF8chXnbeuL8VUTWcGj lF4Q== X-Gm-Message-State: APjAAAX65VCwxbm5rg4wj+jTYbQdiQ9euY5ksI5EkuM6JKhtF1JnVyfM 885wags1HKvz2iPg8XPacPPWwfnjWK00Zg== X-Google-Smtp-Source: APXvYqwwPMHWIemvutzqTkMNvte2kduPtfNuwWXmRiWaA5dh2xI7Bt/rTGg7k69OLe6L3HLQZxnpCw== X-Received: by 2002:a2e:8582:: with SMTP id b2mr154514lji.24.1553548137196; Mon, 25 Mar 2019 14:08:57 -0700 (PDT) Received: from ?IPv6:2a02:a317:4e3d:46f0:8257:3c28:8576:2eba? ([2a02:a317:4e3d:46f0:8257:3c28:8576:2eba]) by smtp.googlemail.com with ESMTPSA id p22sm3541114lfh.93.2019.03.25.14.08.55 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 25 Mar 2019 14:08:55 -0700 (PDT) From: Wiktor Kwapisiewicz Openpgp: preference=signencrypt Autocrypt: addr=wiktor@metacode.biz; keydata= mQINBFhoYHoBEADzmg9UuwDrtvyejU01gDY1J1iJiCi4XGJ4lCfYeLC2jSagIxU/5Lu0lRft 0Loi2tsjpo0c8docP7HFxafEEvnnt/iabd6I536llMuw0uno4PgnD3ljcCMZLT+vn+amIDta lzVoMnSqzoNUotMNMtjIFuAaQ/wr4/Mp9CIgJdviGUc3PscqUiiUVVtk6uF0x657NULZgSIT /Mrqlr2i4RuyPwXe2Qt0uEA3KWWjF0l2NpAMVrqz+nHsLoNOaAsfdx94bzKQrrSeSQqEO2f+ /eO/hbUAFAmEhrotmUO8wJNygo8TgkdlzFI+UE4p8/KW0aCgGGgR8YkCvHq2OQhAAYFNJoNz Hqw0FGxdsY8qWFkYpoSB8zKspNy8KliofCamMYXoPF7eVIxIiKvxrAykGP4jNnzSoV0cn+bY fXnox1IhnqbnoJIT7kTmXv4JmWoYm8ThHqpEgcQOUUQzSRXb9OiNwiXT71ijeO1qswMRpsgk 6AGKSZGWxa3c4ive/p8z1Ax27BFZSh2FceIcMCcGLrDjnQYgeFsAJ1jSxZQXkGuJFHfb4nff Big7aq/vyKrQFQXG0NQQL7rZAdk/s665vifos0yPmRDu7yDT1ggdyBp4Pa4re+ZJcNRNzNHo zU9al+CoImCQjnTtKMXmOe/BzGrpHI4QR3NNzVa423WCIWkHfwARAQABtClXaWt0b3IgS3dh cGlzaWV3aWN6IDx3aWt0b3JAbWV0YWNvZGUuYml6PokCxQQTAQoArwIbAQgLCQgHDQwLCgUV CgkICwIeAQIXgHMUgAAAAAAqAEB0aW1lc3RhbXArYml0Y29pbi10cmFuc2FjdGlvbkBtZXRh Y29kZS5iaXphZmNiMDkyYzVjYTY0MDk1MjZkMThhZTljZjIyZDNiNTVkMzdlNzIzZWIxYjc0 ZTNmODRmN2U2YjA1MmExNjJhFiEEZTkJovDjfBBvX69UbIhX4Njo8HQFAlu193MFCQWi18oA CgkQbIhX4Njo8HSAThAAqaqrTGO7eM+ljzGCtJm5rucXZ47bdwq9n4Yh/KKZd6DxM1IBUpyi nBdUVSJv3ffQ8JSFbGGfg5zR2v/3LLrVvpQMH4pj1OxS81dRVSfJ29wJPJmMW/d7v8sCSFu4 obAEVyw/y0o0W5HFr2i/v/i0/USI2uFjngZ2nq3E4+4JnBheMadX+M52CiMKRyaSxVam81Jv B/pd77sB8dmjYojZ59RqqIYh1VRc09LrNGucX2u2moZmiI+W9xV+9NTTAfKkUDAFQ9tr0blq +320VwEMCYDFJFzDqOLF119lRTaiKVwNpfCcrP3dTPToOorGLFbFrK9Ozp3I/NZT5Hrw+5yQ ZW+OXOAj2ToZ2piFBbCVUNNF2rvwt++VyHHyOmF1PnD1F496P7Pz3PUQlmpnilGD/2z1Tenm OabzFNGZVL+Tp0wpJc0aiAGS0j1GPWQONEuW1V+MrLciG9To91ROIH0TdrYS5u/lNIn3Uurs Iqn0astxXgYYIJ1zdG7oxFVbtegK3HvJQade2U/w77aWvT2NknNzRBg1BR0srJ5QaaP1idsT aGUO+hZhvpNZ9CIgBNd8CF3SLWOzwMOoxp5UbQWlA2UyR0b0QoiU96oMLz8k06BIGIeS4A/H u7xzYXdkZnau4gNDL6z8MgIUcqdL81xCOr3wQTuK83Dj0Sr6dac01fy5Ag0EWedg9QEQAMtP WapVDrMX6MPhP2O6ekoPG+C+sw9B/PejBeO6A19Z4KS7j8oCNEDG2Il+KEK/1KHWhyuTdjDE ZKeJg80N2Xa9FpFSth5b1XGXwJqO55a4r4vNKA+gr95k4gCbdsPqVIdQ2XMZTRT/xUuWlv5V x29Ek5oO9c7mrUzQLY0zeq2TFFWnq9YeAjrBq3zB7niCgcd1heWBddJZaToBvBu7yOcakmos YfMPnv0iHYrUVjfM3/D0KBE/IXud/MRNJW+503BA3nD6VqS8ge3C/TDADCiJ7LADFPi/+HJ1 diLJBHzVgLpOhCSJGkFIlry2TqtjAiAKZ0PlccIU51N9Mn0BykiK3Zcd3BTayVoLk6YbnchN NlbuPbD/PoRmbyxw3EIWlajgNAwNDqEebMw3MP7tMNZk6hs/vk7uJWIjTUv6qgj77NLawoDg qs4mnwxSTT1hL4LXAQ5vHc6Ap7fcPyF+oaU8iyN25WQcg9dK0PjbvT02MbooYK1eWDKpahe6 v8DdvU/p8P2g7w8DUCBfWdj36OtDgYltVKDAajiveDQDelwntjbtLr6SaxbdhO8Ni2NUnRMW 5/3b+ngbIwqHEaMDeijllt27cPQ1MDMEiU4Add3/8+5Cypl3vkw1en5OSxztp/jSsvsmbIu3 guYfcul7Vd3g5PlwcAZ8BkyrYpjTkpL1ABEBAAGJBFsEGAEKACYCGwIWIQRlOQmi8ON8EG9f r1RsiFfg2OjwdAUCW7X3zwUJBCPXTQIpwV0gBBkBCgAGBQJZ52D1AAoJELl6HuCdtBfs0+4P /R5gKp160iDCdLDTVQbzxlfEufC2rYlj0LyyBZWMdE8Hx7t7nDgM7jFa6Hte2lm3s9viIaOV W7J6jnDMDbsFirHOdI9Yx5gCdVWVj32+lnyTAU6sik+Az7vfm5/f5n9yKdr7w1X91TzaAdpF ZJs/HAyaK2l6A+VY45FHOBOUE2QkE7F1IITXUis2r7wuMRHoznfy2393ioHsOTiMD+Yi9ZMm w/oDuvPgUb33SgM6RHeCev7h49WowjE3VEpwcCegNVhseSD1XLMVu5nu0tHniJUvOGcfpCqc 4EkU9cmss9s63ET2O+PLbYN4HpDnzt1Nfid4fdvqWle7+mT0c/5gWpjUfhjZm6CteFlrYdlI FPJuej5fBqBhH/wGJ5eAptyRlCFDytR6WI7CR6Hv/sfVc9QT3GGFh2gQ7j2E3cRZi8VkyycC sp8ioPyK2eXnnqbzmbNDlXaHY5cZjCXyBmURqHoHmwpkI83FqWXL4c2GI7rGekl2VK/yZVlB XCLzuuWqworAUwEJH02USiRaz2OBJBzJKMn/SyCcNEXffsIbUFQSSdBSZtUX0w0gpILUxG6l y4SATpPWXUJ24VFx2W8AdyavMYl9RIDosqmfdP5w5C7rZdRxKJAF7bZSgrcNAeSkFikn4UQE iOpAbDiZOLyMtmPbs03S103QApTls+e8bmUJCRBsiFfg2OjwdLfXD/4iceGw3oN8d2A3JsAp nkWTcmrt7pPW/dr/BD0owAjlJjwismpgt/0k0eTwccR4ab2N5uVdh1jiuOBol4B6L1jJebHR Zlt7QvXRVl5hynNW8lDAsq4uWOFg/n6TDLslt83qIPYc/o1Fks5tf5HX0FcEQx77o5GFD45q 3z9ubG9qST2Lavv9hAxON3vTbMHz0o/pqU7bWw59lqtiEqm3nQgRwEc6cOgHISD3IYkwTnV8 VjLDb4VLQXlXp8hdwAGIXmD5WyJGYhbmk5YfGafzZQR0Rku/JOgzqntwI0RVKgHRWXGsxq/r IPJH5o2QjnplTMVTT50zp/ieOpNHTUX27q9bH/ivozh3zAejlgS0HNXexebwxuQct6XXcfoa zshOXsVrrqmBw4r1uO2p1HCbY0mlwNek28IQ3j481uUWT94bkfDnp1SeY4CDl7nRxApXdhEl NWAER7mVnER76YGu7NL0zV9/Sa8+V5a3vpn1WEZL6muHZ32K45pfuoj/zLpkTmnn1X8So8Qv 95Z+gJP4iz1HUEW9qqFZvsEeTS6hRoHE/1SZG6keVsPkRtdVlgwA3YJOmaN03ZtQz0Eqo9Fd hxkgfM3h8swZkxfzpsjgDs6e/1yizHNyGnQSAojxdvtVdHhO7smUt5RYCjTmWgkCh2SXVBXh vlYAytc4Xwluk16oe7kBDQRbP5UtAQgAuaF9695bhe3MzBfFBcSc+eV7rzUbOLRI6B86nKqH uPkScnzQ7bKYHr2CKtVkysPx92WLHdsGaZDNyPgSZ/Xnh2SrO+6l0GRjeTwQeua2aC4zMfqh 2usB+JSGDGFu3gfRxzLE/+RNyCwUkc2SMCYpnf0HSDCkqyeZjzJAHfvfsaG+cyhzuS+aW0LS UhktJte/4QNJAkyyPPOYS7U9ybCPylsLgGA608LGss4f4RvzYHQNyPMZa0AiwtBBSaMR5Dfb Qsl3ij5ayD2MjAdYx06NYjVdAkBqZPs3+gwP8khnycXd9JLCWfMuasQ+N80tGH32DAtNQnrq j6BmdhcvVcYTgwARAQABiQI8BBgBCgAmAhsMFiEEZTkJovDjfBBvX69UbIhX4Njo8HQFAlu1 988FCQLLoxUACgkQbIhX4Njo8HQpcRAAvsOQsP0C2CsBSvBNRRg1As3u+WMyTmBM419K1R1W yQZCPqEiaQ65TBnDIXSCsm1w25gMFBjgvOt9evEHowJMsX9Y0kSgXCMeM6AHaSnktpnxTiAR bSVvv0c5CMGIuLBR+I6ySF9YYzP86y9dTydemkZYQJkQJlfO8bOt2TdeUSp8vsGoAdSuCmqz aBAuGwlkXs7M7VCptStbjFqgX5wwX6AjIL0K7toNIMGZXuZBFFFQhjFmie+r8es7Bqvuzd7b pdynHtlDDoogfqvUHLuRuRpBZNkN70dtycBF2lgQZYyrqDjSUJQhWdAUKAYFdjn3wcrAfTd/ GyygsUBtDpKZpaDZgdYoPuRt/NeHEr6G71SDCQBEWWm6MzE290K82UAUy9VnuyuQ0y+Q50nS UP9mkvXPtGTY1CmHZi5r7skRYkd16yCEbkJIcjpmbaIvWSvqRTnGqLrkgnBfC0M3bVC40G5m 3P6WOq8I6dPLk7IGMr3muo9/RAXjDwzpmPhfVabz/23k+xKKTC3aTlMvBcet5xPtfMB6aDQl OPyWOA+eTe/EAfpu/M0n4sTmBFDUfUUNnlYFsKvPsRZ7Rzeib0auZ/r0gKCBrB9abncemayR F9yJmkBISgT8SrZ4ukmBsgCugTEk4KmI35f5FPgqxIAhqkFB74/autmGQnF0P6IMzAO5AQ0E Wz+VagEIALfzaIAu2prgEE+mmLpd5Z2o+w5ombyxvfUAaEzUWkIyaWyndzL7tKX2ofhp0EIn MTjtxjrj1VnnE1TCwSgxV/C/Flk6tjRYcKGVeeTAXFYFbDu2vUh1i1MM67Hyh4fRvu+1DasV JXZCk0SI7NBkgor6VVydttheJ2D9FJWLFEHDaPWEuZvL18MGxsoD0c6Vq+XOQYev/VZgh91m eTtegUajYnrTgW6lSiK43cObi/UmRS2FuDpLCzl+9D7zM5/XNAViFFUgMDCWBsJZDfsRYkSm ZH4dfmi3OAphGRrLbfaaKhwmQFFFZ4U4I84Xl7MGIFKR2Mbav13l9hOb5CyviQ0AEQEAAYkD cgQYAQoAJgIbAhYhBGU5CaLw43wQb1+vVGyIV+DY6PB0BQJbtffQBQkCy6LYAUDAdCAEGQEK AB0WIQTvHuD6lCD4BP3vwCaX/e802rj4KwUCWz+VagAKCRCX/e802rj4K7naCACEcQYkm2Xq LuNpI9XCzadE28KPT9BnEJtzo6zLejYcJEpjmbWM55+vkyaMR1anxrBcDl4H7SStucysLFKR le6eBncK2EZ/qxxSpK7Idlyo4lVrVVA+Ug/3BgYDOnTIIakK2sy25gfAFas3pmsmF/bvcOTT MTFXuGbs3tdnToAH9ML/kT11ccZ9JlWJcTlo4qHelS594NuGk7/mzeoZnLIxiUZUKQQNA1bE qfcGMZTAnbWk4cwnzkk6EDl5mDCZl5nd3kqACTUEZUgEZaz+crIjG4EtPBLpGy/4b7Opmsny gNtkTua4wkKhszeAVKksOETMUEEDs/wTv7CmO0XSAkbWCRBsiFfg2OjwdOW1D/sGdJczydRD diLy09AcJThxcen/YrkAEpsfoWTeBhYBFJByAanuhMx4DWjyS5+AYmsXFKF9A4xiaVgvr9z8 NVIxISv/xLPApyNrfJ/0F8CnYiWtn+7cy4Va00gaahGbOjfn/G9vbE/6dDtvm6fAMbXhwZxa Q4emZOa4vAxE+2yuMWHVEOUIcB6/JhC+SoCbHXM9+jDFdVJYLHCeiIPEz4BUNFMOdVtY4pYp ah58ZPEy/jjILPdxmH0t6KhGSRwzL9/f7WFWzXuO2xi7dALD8r8NSaQKnAxC8cItk/r3RkIx B3G9PhBmfDN0iaBZKrErk3ItpHoizSW7n84kzXODEShvT20Emh5CJ8tRrIHRgRv61hGBtK3y sSUqllw/O8Q2X952bk+7Yxr79z9fbepEmf9GvRwIWc/37pT//b74UvJW/qxhPSQij/Ira97P jLEJpB03qdT1z7/wy76EI/botldwu5gO8MAaOUEVa4OUGHunOJdnVB8QHiD/7WcIyV9OMnXQ mMlzFwNCAdbogaGQhAyRkSyZr2hR71jhSik7859Y29/DdLKQxwdi1zXUS3nTb+/ClxGKD8D4 5joqgukB5JIDmpwewZLHm44tBxcJzQHcJaIxyBLkRgit7Ralb2mKm6SP4nyqs2+5LhzxUEDJ XRujRx/4fbU1SFqd+BeXB+jRlw== Organization: Metacode To: Werner Koch Cc: openpgp@ietf.org Message-ID: <02531d3b-c743-6c34-f93b-0bd7a087aa5c@metacode.biz> Date: Mon, 25 Mar 2019 22:08:30 +0100 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Buh4bKdUcHWAgScD9GRuepUFFRuWBjO2z" Archived-At: Subject: [openpgp] Web Key Directory and CORS X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 21:09:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Buh4bKdUcHWAgScD9GRuepUFFRuWBjO2z Content-Type: multipart/mixed; boundary="m0HQPDy9UdC5ko0rbJvliEqjyzgoP9uKD"; protected-headers="v1" From: Wiktor Kwapisiewicz To: Werner Koch Cc: openpgp@ietf.org Message-ID: <02531d3b-c743-6c34-f93b-0bd7a087aa5c@metacode.biz> Subject: Web Key Directory and CORS --m0HQPDy9UdC5ko0rbJvliEqjyzgoP9uKD Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hello, I would like to ask if it would be possible to add a mention of CORS=20 header [0] in 3.1. Key discovery [1] in OpenPGP Web Key Directory documen= t. I think it could be added somewhere below: > The server SHOULD use "application/octet-stream" as the Content-Type= > for the data but clients SHOULD also accept any other Content-Type. > The server MUST NOT return an ASCII armored version of the key. And the wording may be something like: "It is RECOMMENDED that the key=20 is returned with 'Access-Control-Allow-Origin' HTTP header set to value=20 '*'". The context of this change is the following: without appropriate CORS=20 header JavaScript code running on one domain cannot access resources=20 hosted on different domains. There are web applications that would like=20 to fetch the key and encrypt data purely in the browser and send only=20 encrypted blobs to the backend thus minimizing attack surface somehow. [2= ] OpenPGP.js today can do WKD lookups, but without CORS header set it=20 cannot fetch keys from any domain [3] thus making WKD not usable in the=20 browser [4]. One similar paragraph, recommending CORS header for=20 "/.well-known/host-meta" can be found in XMPP [5]. Thank you for your time! Kind regards, Wiktor [0]: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS [1]:=20 https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-07#section-= 3.1 [2]: One such site is https://pipefile.com [3]: This was pointed out by Sanjana Rajan: https://github.com/openpgpjs/openpgpjs/pull/714#issuecomment-392609354 [4]: Thomas Obernd=C3=B6rfer mentions that "For regular web pages, CORS=20 header would be beneficial": https://github.com/mailvelope/mailvelope/issues/580#issuecomment-39469005= 1 [5]: https://xmpp.org/extensions/xep-0156.html#impl --=20 https://metacode.biz/@wiktor --m0HQPDy9UdC5ko0rbJvliEqjyzgoP9uKD-- --Buh4bKdUcHWAgScD9GRuepUFFRuWBjO2z Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEWaKd6o03OIxlaGPfuXoe4J20F+wFAlyZQ1QACgkQuXoe4J20 F+xd0xAAu5g6hJTzsUyT7LWvqRWvTJKUL2CgdFtG6549/EFvHIngkQnS5tDs+UvQ 5ztoPLaP8ldt9abxFx4jgrCJLFj5Y7N2P/iU7z6nEzOPE209XMwzpOpcyfH86QVR keHXLD1rXu4zZluU5knFjK//+EAhzDiQjvRArYwJgiRRGRrz2A35Y/4Ms1E7n4aR fwzuzPHdfGU9GiQ4QtDLx7HfG9Kr4AREasu5CszOKichpzxXDFEZhLNheQalRnBd peAdHuiGTk9HeqsHAZeIK4E8pTQPTL20xL5fDuhmMDZweW8F7nZobJlZdx/Ea6uo 0DfO1vZ3NjRe/oWKuiX7iJ+RGJbbfy1Tr7OUHsNET1iSQU87FyaTxXuhU202uBtQ rL0J8opPqgbfIIJBMEGAAAwHnF4smREC1tZ54Ordx70SgsVCseCYWdbL6Z06zRvq 5W6UZlj86fYGYANKBe8RxMrUf7x3I1Bdt693MqTfAoMKhZWm3t2+DemjHbctQWoX P/Hy9sMPk0kLGLWGcW8dAT3vXT6n+QI6ZuBdE/ivpgJGK5GFAKhx3sxW1dTWUsrW 580Ee399cMy7SFE5IVsy3ty2N+/W9JE35uEhkJOq+djx+jVVQm8ypXS1Uej0hF5R yE9ab0S2JZLK9RTiYu/KiRBLmN7HnQuXXfa5nQks1QBbCUDmYGI= =SaHD -----END PGP SIGNATURE----- --Buh4bKdUcHWAgScD9GRuepUFFRuWBjO2z-- From nobody Tue Mar 26 10:40:46 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5880B120419 for ; Tue, 26 Mar 2019 10:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 lB7nTSijMyfP for ; Tue, 26 Mar 2019 10:40:41 -0700 (PDT) Received: from bitbox.cryptobit.ch (cryptobit.ch [188.40.138.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 120681206D2 for ; Tue, 26 Mar 2019 10:40:40 -0700 (PDT) Received: from unibox (p5B0DD103.dip0.t-ipconnect.de [91.13.209.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.cryptobit.ch (Postfix) with ESMTPSA id 44TJLs2PyGz13LHy; Tue, 26 Mar 2019 18:40:37 +0100 (CET) Message-ID: From: Tobias Mueller To: "Neal H. Walfield" Cc: openpgp@ietf.org Date: Tue, 26 Mar 2019 18:40:35 +0100 In-Reply-To: <87a7hri39u.wl-neal@walfield.org> References: <87r2b348z5.fsf@wheatstone.g10code.de> <87ftrji7sr.wl-neal@walfield.org> <87k1gv41zj.fsf@wheatstone.g10code.de> <87a7hri39u.wl-neal@walfield.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 17:40:45 -0000 Hi Neal, On Tue, 2019-03-19 at 11:09 +0100, Neal H. Walfield wrote: > Can you please explain > how the MDC helps protect against ciphertext modification in the > streaming case, as that it still not clear to me. RFC 4880 currently states in § 5.13: Any failure of the MDC indicates that the message has been modified and MUST be treated as a security problem. Further down in the security section (§ 14): An implementation MUST treat an MDC failure as a security problem, not merely a data problem [...] Consequently, it is important that: 1. Implementers treat MDC errors and decompression failures as security problems. There the MDC, if the spec is followed, indicates a security problem. I guess that conversely, applications using OpenPGP thus ought to exercise care when using that data which was flagged as having a security problem. So that's how the MDC protects against modification of the ciphertext. Is that clear to you now? Obviously, that didn't prevent consumers from ignoring that reported security problem. But the spec cautions the use of the unauthenticated data. That's arguably too weak and it should probably say to not use unauthenticated data at all. And implementations probably shouldn't have released plaintext early. Or, if the application really needs to access early plaintext, because, say, it's running out of buffering capacity, then it needs to be able to deal with the fact that the data may turn out to be bad. AFAIU, the MDC itself is not the most elegant or efficient construction, but works just about well enough to detect modified ciphertext. As an aside which you all of you are probably aware of: The other, bigger, problem with SEIP packets is that they it can be downgraded [1] which then, AFAIU, served as a another motivation to move to AEAD [2]. While "authenticated prefixes" (if used correctly) would render certain ciphertext modifications powerless, they still leave an application susceptible to attacks if it is not prepared to defend against them. Spontaneous examples that I can come up with are the script in the backup that does "cp /foo /bar" where the attacker manages to cut off the "bar" and causes havoc or a PDF with multiple xref tables where the attacker manages the remove the last one. I'm sure there are more and better examples. I appreciate that the bar is higher for an attacker to mount this attack if you can only cut off at the end rather than modify anything at free will. At the end of the day, though, the application layer has to be able to defend against such an attack. Now the question becomes whether applications using OpenPGP are in such a position. Assuming that most of them are would make things easy, but may be a bit far fetched. Yet, forcing streaming onto every user and encouraging the release of plaintext while the whole message has not yet been authenticated seems to make that assumption. I thus dislike the proposed removal of the option of not dividing a message into separately authenticated pieces. I appreciate that the authenticated prefixes reduce the attack surface of Efail style attacks when you really can't hold all of the message. But they don't prevent the root cause of those attacks. Not using unauthenticated plaintext (or parts thereof) would. To that end, I like Vincent's idea of moving the discussion towards fixing a chunk size for chunked mode but leaving support for a non- chunked mode. Cheers, Tobi 1: https://mailarchive.ietf.org/arch/msg/openpgp/JLn7sL6TqikUf-cD34lN7kof7_A 2: https://mailarchive.ietf.org/arch/msg/openpgp/9uJYltQjfOaTKlnarJoDYnLXNzc From nobody Tue Mar 26 10:45:18 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDD6120760 for ; Tue, 26 Mar 2019 10:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 MkWukHagdAbC for ; Tue, 26 Mar 2019 10:45:13 -0700 (PDT) Received: from bitbox.cryptobit.ch (cryptobit.ch [188.40.138.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 328CC12075B for ; Tue, 26 Mar 2019 10:45:13 -0700 (PDT) Received: from unibox.fritz.box (p5B0DD103.dip0.t-ipconnect.de [91.13.209.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.cryptobit.ch (Postfix) with ESMTPSA id 44TJS718Byz13LJ2; Tue, 26 Mar 2019 18:45:11 +0100 (CET) Message-ID: <65e588255c689d329546c3908dac112896d029ca.camel@cryptobitch.de> From: Tobias Mueller To: "Neal H. Walfield" Cc: Derek Atkins , Werner Koch , openpgp@ietf.org, Vincent Breitmoser Date: Tue, 26 Mar 2019 18:45:09 +0100 In-Reply-To: <87imwfj3oq.wl-neal@walfield.org> References: <87d0n174w6.fsf@wheatstone.g10code.de> <87mumh33nc.wl-neal@walfield.org> <3GFS71V7BTJNZ.29C5TO8OY0O44@my.amazin.horse> <87r2bax5u2.wl-neal@walfield.org> <87pnqtwot9.wl-neal@walfield.org> <0f7f492bf18145f96e70886ba19ba290.squirrel@mail2.ihtfp.org> <87lg1gwelf.wl-neal@walfield.org> <61e3fb9d194d0b47f21be8e176daa0b9b6c5d0a5.camel@cryptobitch.de> <87sgvkihd1.wl-neal@walfield.org> <241225ce914a1843b48dab304c760151fe05b764.camel@cryptobitch.de> <87imwfj3oq.wl-neal@walfield.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 17:45:17 -0000 Hi Neal, On Mon, 2019-03-18 at 22:03 +0100, Neal H. Walfield wrote: > On Mon, 18 Mar 2019 20:51:32 +0100, > Tobias Mueller wrote: > > On Mon, 2019-03-18 at 11:53 +0100, Neal H. Walfield wrote: > > > > For me, a plaintext is authenticated if the whole ciphertext > > > > could > > > > > > be > > > > successfully authenticated. Which seems to be very well in line > > > > with > > > > > > the > > > > definition you've linked to. > > > > > > 4880bis defines a chunking mechanism based on AEAD: the message is > > > split into multiple chunks. In 4880bis, AEAD operates on a per- > > > chunk > > > basis. The chunking algorithm provides mechanisms for ensuring > > > chunks > > > can't be reordered, detecting the end of the message, etc. Using > > > AEAD > > > to decrypt a chunk authenticates that chunk's ciphertext; for a > > > given > > > chunk, the decryption operation will either return the correct > > > plaintext, or it will return an error. This is exactly what RFC > > > 5116 > > > requires. > > > > I beg to differ. Because, as you mention: > > > > > RFC 5116 doesn't discuss chunking; chunking is not AEAD. > > > > > > > Chunking is not AEAD. It's a protocol on top of AEAD messages that > > you > > have to come up with. And then you have to implement it correctly. > > The > > security guarantees that AEAD gives you, do not automatically apply > > to > > your chunking scheme. > > As you've said: Chunking is not AEAD. Hence, it cannot automatically > > be > > in line with what RFC5116 demands. > > The chunks use AEAD. So 5116 applies to the chunks. That means, for > a given chunk, either authenticated plaintext is returned or failure. > I don't see a contradiction. Let's carefully revisit the RFC5116. It starts with: There is a single output: A ciphertext C, which is at least as long as the plaintext, or an indication that the requested encryption operation could not be performed. Note that there is *a single output* rather than multiple and that it doesn't allow for releasing partial plaintexts or authenticated prefixes. Do you see that any chunking protocol on top of that which is allowed for releasing plaintext early is not immediately covered by this definition? Let the RFC be crystal clear: In particular, partially encrypted or partially decrypted data MUST NOT be returned. This contradicts with handing out decrypted chunks, partial plaintexts, authenticated prefixes, or whatever name you might want to give them, as those are partial decryptions of the original message that was protected in full with an AEAD scheme. If I meant to encode several individual messages which have a right to be decrypted on their own, I might as well have produced several individual messages. > > > > You seem to think that AEAD's guarantees must apply to the whole > > > message. I disagree. > > > > I'm glad you're saying this. > > And yes, I think that proper AE means that the full message enjoys > > the > > security guarantees of AE. Also because I am not aware of > > definitions > > covering partially authenticated plaintext. > > TLS is used by a few billion people. Let's just do what they do... > I don't fully understand how you're making the leap here from definitions of AE to a transport layer protocol. But that's a very interesting point. First of all, be aware that TLS records use a variable size. That's much unlike what you're proposing. Additionally, TLS is a transport layer protocol rather than a syntax which people will use to archive their emails and backups, which OpenPGP is to some. Finally, TLS requires the application to be safe from truncation. From the source you've referenced yourself < https://crypto.stanford.edu/~dabo/cryptobook/BonehShoup_0_4.pdf> on the "Cookie Cutter" attack in § 9.8: "TLS assumes that the application layer will defend against this attack". I think you can make that assumption for applications using OpenPGP, but if you do then stating that in the spec would be more honest about the security OpenPGP will provide rather than silently taking the one-chunk option away without warning the applications which intend to use the protocol. The TLS record protocol needed to be changed a few times to respond to newly discovered threats. I am too humble to assume that the design of the OpenPGP chunking protocol has been gotten right on the first attempt. By removing the option to not use the chunking protocol, you prevent a safe usage of the protocol in the future. Do you still think we should blindly "just do what they do"? What would that even mean? > The whole thread, starting here, > https://mailarchive.ietf.org/arch/msg/cfrg/-lj3IEm9agpfgUOb2yX9JNrtrm8 > is an interesting read. And, I think it generally supports my > position. I thought your position was that chunking a message and applying AE to those automatically preserves the security properties which we have proofs for. The position in the thread, as far as I can see, is, that a custom chunking protocol has unknown security properties. I'm glad that this was a misunderstanding. > > > > I further think getting as close to > > proper AE as possible is a goal worth pursuing. > > I think that if we accept your position, OpenPGP will have less > practical security. AFAICS, there is no need to accept anything here. Right now, with 4880bis, it is possible to create a message with exactly one chunk. You are proposing to remove that option. Did you rather mean to say that "if we keep providing the option of using proper AE for the messages then we will have less practical security"? And I would even agree to some extent. But I'm not yet convinced that fully trusting the OpenPGP chunking mechanism leads to a safer future than allowing clients to not rely on the correct definition and implementation of that mechanism. > > > > If you absolutely must stream, then there is no way that you can > > buffer > > the whole message, otherwise you wouldn't stream. I claim, however, > > that in the vast majority of use-cases you don't have the > > requirement of > > having to stream. As in, purely from a functional perspective, not > > from > > an implementation perspective. Hence, imposing the concept of > > streaming > > onto everybody somehow does not feel right. > > Let's consider email, which is a common use case for OpenPGP. I like > that K-9 just downloads the first few kilobytes of each message. I > want K-9 to be able to continue to do that even when everyone is > encrypting their email. For that, I need an authenticated prefix. > Just a quick reminder that nobody is about to take that option away. The proposal at hand is to remove the option of not having to produce several chunks. Reg. Email, let me cite the Efail paper: We think it is safe to turn off streaming in the email context because the size of email ciphertexts is limited and can be handled by modern computers. > Likewise, with a dropbox-like application, I'd like to be able to > preview the content. Again, I need an authenticated prefix. > I don't object. The application could, probably based on the file type, determine reasonably safe boundaries and encrypt those. Assuming that the safe boundary for all files is the same seems dangerous. > I want to be able to stream archives and backups. I'm not so sure here. A nc -l -p 1234 | unsafe_decrypt | tar -f- can have severe consequences if partial plaintexts are involved. I can understand that some users are enjoying the guarantees of AE, that is, either to decrypt the whole message or nothing. With your proposal, the user is at risk of either the chunking algorithm not being sound, the algorithm not being implemented correctly, or the application (tar, in this case) not being safe against recovering from a truncated message. And the truncation is the best case, that is, we assume that the implementation did everything right. We haven't yet considered a minor flaw in the implementation that would allow, say, re-using nonces, re- ordering of chunks, or changing the size of the chunks. With your proposal, how would such a user construct an OpenPGP message that is less risky? > > Pretty much the only case that I can think of that chunking is not > useful is for verifying software updates. I agree that chunking is useful more often than it's necessary. > > > I'd like to note, though, that it is possible to not reveal the > > plaintext no matter how large the message is, though. You can mask > > the > > output you release, e.g. XOR it or apply CTR mode, and provide the > > key > > to remove the mask only when the ciphertext has checked out > > correctly. > > I don't see how that helps with streaming. Basically any further > processing needs to wait until the whole message has been decrypted a > second time... Of course. Implementations are free to provide a different API. I merely presented an example of how one could expose the functionality of the spec. Anyway, if you desire a property P and that property depends on all the bits of the ciphertext, you need to wait until you have gotten around to process all those bits. One could argue that this has been the semantic ever since the MDC has been introduced. Now with AEAD we get a formal description of that semantic. And it helps an OpenPGP library to support streaming, because it can safely release that memory to the caller or update the message in-place. > > > From the proposal you made it seem you think we should not even try > > to > > provide a format for a non-streaming message. Would you describe > > that > > as correct? > > We should provide exactly one variant. Additional variants must > justify their existence, and I don't see the huge value add for > "proper AEAD". In fact, it seems dangerous as I think it will > encourage decryption misuse. Fair enough. The value add is that we have proofs for the security properties of AEAD encrypted messages. AFAICS, we don't have those for the custom chunking protocol. I'll be happy to be told otherwise. Note that proven schemes exist which have "intermediate tags", such as POET or COLM. Alas, none of them is defined as an option for OpenPGP (yet?). Another benefit is being able to not use the chunking once it turns out that it's not good enough anymore. So we know that using AE has security benefits, that libraries can implement that safely, and that most use cases do not require messages to be actually streamed or that they're better off defining partial plaintexts for themselves. Given that applications can produce multiple message if they desire, the one-chunk option is strictly better than the multiple-chunk option. Removing the option of using one chunk and *forcing* every consumer to use streaming seems mis-guided. > > > > I think that even if we add a bit that says: "don't stream", > > > implementations will ignore it. > > > > Hm. I'd classify this as a wilful violation of the spec rather than > > an > > accident while implementing it. > > Once you assume that implementations are doing things wilfully > > wrongly, > > it gets messy. > > I mean... where do we stop making compromises in the security of the > > spec because we believe someone will wilfully ignore the spec? We > > rely > > on the client not actively misinterpreting the spec. Like.. not > > making > > secret key material available. > > It's a simple question of: "can I use the software to get my work > done"? If the security is in the way, then the security will be > disabled. "Proper AEAD" will be in the way often enough that it will > get disabled, and decrease the security of the whole system. I get your point. You don't want the security properties of AE. That's fair. And you assume that implementations will actively misinterpret the spec. While this is a bit pessimistic it may indeed reflect real-life. Do you think that defining a non-streaming mode and a streaming mode would work? Then clients wouldn't need to feel bad about releasing plaintext early, but can use the streaming mode instead. Cheers, Tobi From nobody Wed Mar 27 02:50:29 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B089D12028F for ; Wed, 27 Mar 2019 02:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 TGHVwVL2PWIk for ; Wed, 27 Mar 2019 02:50:26 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 7DFED1202AE for ; Wed, 27 Mar 2019 02:50:26 -0700 (PDT) Received: from p57b22663.dip0.t-ipconnect.de ([87.178.38.99] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1h95CS-0001sX-4h; Wed, 27 Mar 2019 09:50:24 +0000 Date: Wed, 27 Mar 2019 10:50:23 +0100 Message-ID: <87pnqchcio.wl-neal@walfield.org> From: "Neal H. Walfield" To: Daniel Kahn Gillmor , openpgp@ietf.org In-Reply-To: <87d0mdtj10.fsf@wheatstone.g10code.de> References: <871s3475dy.fsf@europa.jade-hamburg.de> <96055353-B0EB-4E25-95CC-B25D9C5A0BA8@icloud.com> <2RAT852LYMAQD.3U70IQJPU0VPO@my.amazin.horse> <0092256D-94EB-4FE5-9560-FEB0B8E3769E@icloud.com> <20190323170723.GC1497@zeromail.org> <87imw9jl2t.fsf@fifthhorseman.net> <20190324162058.GA1238@zeromail.org> <87o95yujj0.fsf@wheatstone.g10code.de> <87imw5haya.fsf@fifthhorseman.net> <87d0mdtj10.fsf@wheatstone.g10code.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [openpgp] 4880bis status X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 09:50:29 -0000 Hi, Werner wrote on gnupg-devel@gnupg.org that he views 4880bis as done, and the recent proposals as "severe last minute changes". Is there general consensus that 4880bis is done? Is further discussion of the changes to 4880bis no longer desired? Are new proposals no longer desired? Thanks! Neal On Tue, 26 Mar 2019 22:36:43 +0100, Werner Koch wrote: > Those folks who are trying to get severe > last minute changes into a revision of a standard may be better off to > start their protocol from scratch. From nobody Wed Mar 27 03:46:16 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620AC120476 for ; Wed, 27 Mar 2019 03:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 ZwajPrr567Vh for ; Wed, 27 Mar 2019 03:46:05 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 B3F9A1202BF for ; Wed, 27 Mar 2019 03:46:04 -0700 (PDT) Received: from p57b22663.dip0.t-ipconnect.de ([87.178.38.99] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1h964I-0002Tm-5Z; Wed, 27 Mar 2019 10:46:02 +0000 Date: Wed, 27 Mar 2019 11:46:01 +0100 Message-ID: <87o95wh9xy.wl-neal@walfield.org> From: "Neal H. Walfield" To: Andre Heinecke Cc: openpgp@ietf.org, Justus Winter , Vincent Breitmoser In-Reply-To: <2020697.uNjeE9oTgC@esus> References: <2301148.obROdnegVN@esus> <871s3475dy.fsf@europa.jade-hamburg.de> <32M8VBNV00C3O.2R23SQ96PJPG3@my.amazin.horse> <2020697.uNjeE9oTgC@esus> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 10:46:16 -0000 Hi Andre, On Wed, 20 Mar 2019 14:17:53 +0100, Andre Heinecke wrote: > On Wednesday 20 March 2019 14:14:49 CET Vincent Breitmoser wrote: > > Is your point that you would want to keep compression as a feature in those > > applications, hence removing it from OpenPGP would mean you'd have to keep > it > > around unstandardized / on a different layer? > > Exactly. The User Experience of Kleopatra on Windows is that you right click a > folder and encrypt that folder. You need compression there. > Currently it is standardized. You propose to remove the standard so it will be > unstandartized and no longer interoperable. You talk about encrypting a folder. So I assume you mean multiple files. As far as I know, 4880 doesn't support this out of the box. For instance, an OpenPGP message can only have one literal data packet: https://tools.ietf.org/html/rfc4880#section-11.3 Are you using some container format? PGP/Mime with multiple attachments? Something else? Thanks, Neal From nobody Wed Mar 27 03:57:46 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 628E91202A1 for ; Wed, 27 Mar 2019 03:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 MBBdmh3Ma1Lf for ; Wed, 27 Mar 2019 03:57:43 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 8FBA1120291 for ; Wed, 27 Mar 2019 03:57:43 -0700 (PDT) Received: from p57b22663.dip0.t-ipconnect.de ([87.178.38.99] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1h96FY-0002bb-V9; Wed, 27 Mar 2019 10:57:41 +0000 Date: Wed, 27 Mar 2019 11:57:40 +0100 Message-ID: <87mulgh9ej.wl-neal@walfield.org> From: "Neal H. Walfield" To: Andre Heinecke Cc: openpgp@ietf.org, Justus Winter In-Reply-To: <2181951.mQFCbn3PMz@esus> References: <871s3475dy.fsf@europa.jade-hamburg.de> <2181951.mQFCbn3PMz@esus> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 10:57:45 -0000 Hi Andre, On Wed, 20 Mar 2019 15:53:58 +0100, Andre Heinecke wrote: > * I don't want to use unstandardized compression only because you do not want > to implement compression in sequoia. For the record, Sequoia implements all three compression algorithms that 4880 specifies. Also, I don't think Justus suggested that we remove compression from 4880bis, because we don't want to implement it in Sequoia, but due to a number of security-centric reasons. I welcome constructive criticisms. > Here is where annoyed rambling about unproductive suggestions starts: Calling Justus's suggestion "unproductive" is an insult. If it is so obviously wrong, then it should be easy to provide a short, convincing response that ends the discussion. Unless you think that Justus is a troll. In that case, please don't feed the trolls. I've tried to act in good faith, and appeal solely to technical arguments. I hope that we can all work towards this, at least on this list. Thanks, Neal From nobody Wed Mar 27 03:59:52 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C53120450 for ; Wed, 27 Mar 2019 03:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 8_Kf8zQrdytN for ; Wed, 27 Mar 2019 03:59:36 -0700 (PDT) Received: from mail.heinecke.or.at (mail.heinecke.or.at [159.69.149.236]) by ietfa.amsl.com (Postfix) with ESMTP id AF6F01202A9 for ; Wed, 27 Mar 2019 03:59:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.heinecke.or.at (Postfix) with ESMTP id 1D9983E8AE; Wed, 27 Mar 2019 11:59:35 +0100 (CET) Received: from mail.heinecke.or.at ([127.0.0.1]) by localhost (mail.heinecke.or.at [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwhCb2jw2gft; Wed, 27 Mar 2019 11:59:33 +0100 (CET) Received: from esus.localnet (193-80-87-252.hdsl.highway.telekom.at [193.80.87.252]) (Authenticated sender: andre@heinecke.or.at) by mail.heinecke.or.at (Postfix) with ESMTPSA id 1094A3E811; Wed, 27 Mar 2019 11:59:33 +0100 (CET) From: Andre Heinecke To: openpgp@ietf.org Cc: "Neal H. Walfield" Date: Wed, 27 Mar 2019 11:59:32 +0100 Message-ID: <1825148.YadyztgY27@esus> In-Reply-To: <87o95wh9xy.wl-neal@walfield.org> References: <2301148.obROdnegVN@esus> <2020697.uNjeE9oTgC@esus> <87o95wh9xy.wl-neal@walfield.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5182660.fWC2pMMWap"; micalg="pgp-sha256"; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 10:59:51 -0000 --nextPart5182660.fWC2pMMWap Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hi, On Wednesday 27 March 2019 11:46:01 CET Neal H. Walfield wrote: > Are you using some container format? PGP/Mime with multiple > attachments? Something else? As you know we are using tar archives. We take pains that our tar=20 implementation is compatible with the tar format used by PGP. Marcus already made that point. "Why are you not using tar.gz.gpg" if you u= se=20 something out of the standard anyway? Here I said that this will move something that was standartized (the=20 compression) out of the standard and leave it to the application.=20 But if you dislike my example with a folder, which I chose to underline tha= t=20 compression is needed. Please ignore it and respond to the other points mad= e=20 in this thread like compression for mails or just replace "folder" in my=20 example with "file" and there you go. I find this kind of discussion about my example unhelpful and distracting o= n=20 this list. If you want to further discuss this please do it off list. Regards, Andre =2D-=20 GnuPG.com - a brand of g10 Code, the GnuPG experts. g10 Code GmbH, Erkrath/Germany, AG Wuppertal HRB14459 GF Werner Koch, USt-Id DE215605608, www.g10code.com. GnuPG e.V., Rochusstr. 44, D-40479 D=FCsseldorf. VR 11482 D=FCsseldorf Vorstand: W.Koch, M.Gollowitzer, A.Heinecke. Mail: board@gnupg.org =46inanzamt D-Altstadt, St-Nr: 103/5923/1779. Tel: +49-2104-4938799 --nextPart5182660.fWC2pMMWap Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRwkxlKrbuKLRTTyRcpeOnUDLq6XAUCXJtXlAAKCRApeOnUDLq6 XISPAP9taplE33+nehkmUQl2mYsqyJSyPl3jw1mzRHfU8jVKZQEAwY3yShpJsIIk D3nLQMXk79jQglv9+VjynJ4gs/YrmQY= =ha7E -----END PGP SIGNATURE----- --nextPart5182660.fWC2pMMWap-- From nobody Wed Mar 27 04:24:52 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 219DD1205FF for ; Wed, 27 Mar 2019 04:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 a7FnNNM9hvmZ for ; Wed, 27 Mar 2019 04:24:44 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 4AFB2120485 for ; Wed, 27 Mar 2019 04:24:44 -0700 (PDT) Received: from p57b22663.dip0.t-ipconnect.de ([87.178.38.99] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1h96fi-0002x5-AK; Wed, 27 Mar 2019 11:24:42 +0000 Date: Wed, 27 Mar 2019 12:24:41 +0100 Message-ID: <87lg10h85i.wl-neal@walfield.org> From: "Neal H. Walfield" To: Andre Heinecke Cc: openpgp@ietf.org In-Reply-To: <1825148.YadyztgY27@esus> References: <2301148.obROdnegVN@esus> <2020697.uNjeE9oTgC@esus> <87o95wh9xy.wl-neal@walfield.org> <1825148.YadyztgY27@esus> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 11:24:51 -0000 Hi Andre, On Wed, 27 Mar 2019 11:59:32 +0100, Andre Heinecke wrote: > On Wednesday 27 March 2019 11:46:01 CET Neal H. Walfield wrote: > > Are you using some container format? PGP/Mime with multiple > > attachments? Something else? > > As you know we are using tar archives. Actually, I didn't know, which is why I asked. I've used Kleopatra once or twice to see how it worked, and I've never used KMail or GpgOl. > But if you dislike my example with a folder, which I chose to underline that > compression is needed. I'm sorry that I gave you the impression that I disliked your example. > Please ignore it and respond to the other points made > in this thread like compression for mails or just replace "folder" in my > example with "file" and there you go. > > I find this kind of discussion about my example unhelpful and distracting on > this list. If you want to further discuss this please do it off list. Your tone makes it sounds like I've personally attacked you. I'm not sure where I did that. If so, I apologize and I will try and keep at least my side of the discussion more focused on the technical discussion. Thanks, Neal From nobody Wed Mar 27 08:50:52 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37641202F4 for ; Wed, 27 Mar 2019 08:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_CSS=0.1, URIBL_CSS_A=0.1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com 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 kELoz_M7v2x3 for ; Wed, 27 Mar 2019 08:50:47 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A01A1202EF for ; Wed, 27 Mar 2019 08:50:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id D10D4E2045; Wed, 27 Mar 2019 11:50:45 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 22243-09; Wed, 27 Mar 2019 11:50:39 -0400 (EDT) Received: from securerf.ihtfp.org (99-46-190-172.lightspeed.tukrga.sbcglobal.net [99.46.190.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 61E29E2044; Wed, 27 Mar 2019 11:50:39 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1553701839; bh=300oHuK2POq99Y8jZoEkr/+gkupzekQq9K8j3sIF5II=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=qCC2I85k4MH2EgejpXik/L4W+9BaBcxtCPYUoAC6Ia+zu8L5T4bhYULnjPuJyiXtl ITCY3CIjKJ1szIQ13OwTFV3alvNY1zb3DR4Q2Xr9ALSo+9UmnNwyG39r+6coeWi9UK WwV3LqKnfPFIs5OjWCTEftx3h8wGD+SjLnT6TTT4= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id x2RFoWOw020640; Wed, 27 Mar 2019 11:50:32 -0400 From: Derek Atkins To: Tobias Mueller Cc: "Neal H. Walfield" , Werner Koch , openpgp@ietf.org, Vincent Breitmoser References: <87d0n174w6.fsf@wheatstone.g10code.de> <87mumh33nc.wl-neal@walfield.org> <3GFS71V7BTJNZ.29C5TO8OY0O44@my.amazin.horse> <87r2bax5u2.wl-neal@walfield.org> <87pnqtwot9.wl-neal@walfield.org> <0f7f492bf18145f96e70886ba19ba290.squirrel@mail2.ihtfp.org> <87lg1gwelf.wl-neal@walfield.org> <61e3fb9d194d0b47f21be8e176daa0b9b6c5d0a5.camel@cryptobitch.de> <87sgvkihd1.wl-neal@walfield.org> <241225ce914a1843b48dab304c760151fe05b764.camel@cryptobitch.de> <87imwfj3oq.wl-neal@walfield.org> <65e588255c689d329546c3908dac112896d029ca.camel@cryptobitch.de> Date: Wed, 27 Mar 2019 11:50:32 -0400 In-Reply-To: <65e588255c689d329546c3908dac112896d029ca.camel@cryptobitch.de> (Tobias Mueller's message of "Tue, 26 Mar 2019 18:45:09 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 15:50:49 -0000 Tobias Mueller writes: [snip] > Note that there is *a single output* rather than multiple and that it > doesn't allow for releasing partial plaintexts or authenticated > prefixes. > Do you see that any chunking protocol on top of that which is allowed > for releasing plaintext early is not immediately covered by this > definition? In my mind, each chunk is its own AEAD ciphertext. So the chunking is happening *during* AEAD encryption, and not after encryption. I.e., the chunking and AEAD encryption should be tied together such that the chunk header is part of the AEAD protection and the chunk data is the AEAD encrypted data. This approach does, IMHO, map directly into the RFC definition. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Mar 27 13:11:19 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7B7120307 for ; Wed, 27 Mar 2019 13:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 ifxvOjCIBauQ for ; Wed, 27 Mar 2019 13:11:15 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 30BA21202C1 for ; Wed, 27 Mar 2019 13:11:15 -0700 (PDT) Received: from p57b22663.dip0.t-ipconnect.de ([87.178.38.99] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1h9EtE-0008ME-Rt; Wed, 27 Mar 2019 20:11:12 +0000 Date: Wed, 27 Mar 2019 21:11:12 +0100 Message-ID: <87imw4gjrz.wl-neal@walfield.org> From: "Neal H. Walfield" To: Derek Atkins Cc: openpgp@ietf.org, Vincent Breitmoser In-Reply-To: References: <87d0n174w6.fsf@wheatstone.g10code.de> <87mumh33nc.wl-neal@walfield.org> <3GFS71V7BTJNZ.29C5TO8OY0O44@my.amazin.horse> <87r2bax5u2.wl-neal@walfield.org> <87pnqtwot9.wl-neal@walfield.org> <87y35hy2i0.fsf@wheatstone.g10code.de> <87k1h0we7w.wl-neal@walfield.org> <87va0g65ht.fsf@wheatstone.g10code.de> <87va0gioae.wl-neal@walfield.org> <431ea8fdaca6b3d20e19cfe2a14f6c96.squirrel@mail2.ihtfp.org> <87mulsi7ms.wl-neal@walfield.org> <87lg1a3fcl.wl-neal@walfield.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 20:11:18 -0000 Hi Derek, On Wed, 20 Mar 2019 14:24:22 +0100, Derek Atkins wrote: > I still don't think we need a fixed chunk size. Different use cases may > dictate different ideas. It's a tradeoff, of course. The hope would be > the receiver can signal to the sender what it should do. I've spent some time thinking about use cases for different chunk sizes, and I can't come up with any modulo some, IMHO, insignificant performance tweaks. Can you please give some examples of use cases that would profit from different chunk sizes? > I DO believe that recommended chunk sizes should be smaller than, say > 4TB (let alone exabytes). I am happy to have the range be anywhere from > 1KB to 128MB (give or take), but I still don't think we should outright > prohibit smaller or larger. Considering the chunk size should be part > of the protected data, I don't see how an attacker could modify it, only > a sender that doesn't pay attention. If I understand you correctly, you would support a SHOULD restriction on the the range, but not a MUST restriction. What should / would you recommend an implementation do if it encounters a chunk that it can't buffer? I see two choices: report an error, or release unauthenticated plaintext. Please don't misunderstand my questions: I sincerely am interested in your answers to these questions. Thanks! :) Neal From nobody Thu Mar 28 05:30:25 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8181A1202CF for ; Thu, 28 Mar 2019 05:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6atYIequZWtw for ; Thu, 28 Mar 2019 05:30:20 -0700 (PDT) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 0E567120296 for ; Thu, 28 Mar 2019 05:30:20 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id h18so3813469wml.1 for ; Thu, 28 Mar 2019 05:30:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:in-reply-to:references:date:message-id:mime-version; bh=wzrs/ehZD/tYEXXL5kD2J53tgqUk9IuVpzTJulMRnKY=; b=e9LgP3vNp3QDKvefpodCxPpVPxxjTg/USk2z8yxqjxoDnWqMLiQ5g0vHHmYqC+sJK2 YPdbmTvCa/nxMbqdR28gSzBEK1gy7lZMxJ2M1xGB31js4RRi9ibQ/bBRTQxeIbWLbE9C pDICbu3wYGf17xRbka5YUy1afkA8kYXV68B6QtrDy6GyTIZgjyiROPJumny9owH8ukTt R703OXVqCbOazBDazM6wTq3W/OP4gvQ+fU7klKg2fbYa4w8Wsox7JxoWCAzeOFOMHWYX 0S196wJSwT1HlzeksNHWn0KAsCND93H3dztyzcHoCH4yuwc/iw/6oYo/J7+X/54UH3KY 6lNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version; bh=wzrs/ehZD/tYEXXL5kD2J53tgqUk9IuVpzTJulMRnKY=; b=UZacmdA9y6VuWyTxvuONJqTjEx1qznzBA9jQpDbwF9b7054PMwhPad/1apRNh7X4PX LHnr8zXNSlQMIAw/9CxcRTuDt8rxFcsDQ8BRFa6OKyBpvLvvmWzl/fLSyE4kYv0oiWRk sVZvD377IJTEkMXjjLwnCEGefW65X6DZC+2uEhDG+eDn2phZWzmRShimc9vZF5QV1WTw l6k1RQn4AecoKpcHCFC3BOll1DrzOfgJkxamctkvIYVaJa3Ji5CFgA7tyCi4H4C78eTK lKoMAuzRuFEIkmox85mlanysZWpH4pn+rBMgfS1jGx+Xgf+k3mMG690E/Wid4GY2QrBP toAw== X-Gm-Message-State: APjAAAXl2crHTazcsvYeHP71m7gk281bTLL2Aqq1nmnRbTspx0owYxqG Amj3AudbOEjsahbvvxQKpiunUH+9 X-Google-Smtp-Source: APXvYqxLCL+CaI+1tylFaBQ6pS+CXnT+CqlRGHhNJFq74qRxUjFbMuYiPZfapaLy9qNZD5MLq2DwnA== X-Received: by 2002:a1c:f00a:: with SMTP id a10mr23451719wmb.100.1553776218392; Thu, 28 Mar 2019 05:30:18 -0700 (PDT) Received: from localhost (port-92-193-8-174.dynamic.qsc.de. [92.193.8.174]) by smtp.gmail.com with ESMTPSA id c10sm32681140wrt.65.2019.03.28.05.30.17 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 28 Mar 2019 05:30:17 -0700 (PDT) From: Justus Winter To: openpgp@ietf.org In-Reply-To: <87mumh33nc.wl-neal@walfield.org> References: <87mumh33nc.wl-neal@walfield.org> Date: Thu, 28 Mar 2019 13:30:16 +0100 Message-ID: <878swzp4fb.fsf@europa.jade-hamburg.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 12:30:23 -0000 --=-=-= Content-Type: text/plain Hello, I'm interested in building robust systems. To do that, I need to consider memory consumption of both my code, and the code that I'm using, say in libraries. I consider that important in general, but even more so if the application in question is handling sensitive data, and transporting it over untrusted networks, therefore it is necessarily exposed to potentially malicious data. In the context of processing OpenPGP data, currently there is no relation between the size of the encrypted message and the size of the decrypted message. This is due to compression. Recently, we discussed compression on this list, and it does not look like we will be phasing it out anytime soon. https://mailarchive.ietf.org/arch/browse/openpgp/?index=dFS9kySMJCcOlR9Svys9QwP7I7Y&gbt=1 For me, using an unbounded amount of memory is not an option for a component processing OpenPGP data if we want to build robust systems on top. Therefore, we need to process OpenPGP data in bounded space. Since there can be no relation between encrypted and decrypted message size due to compression, the only option I see is to provide a streaming API, which let's us process data in constant space. [Now, when I say constant space, implementations could still decide to use, say, 30 megabytes of buffer space. Then, most emails will fit into this buffer, and we can detect truncated messages before we hand out one byte to the downstream application. This is what we do in Sequoia. Note, however, that the consumer decides how much data to buffer before releasing the first data, and not the producer. If we decide to even allow 128 megabyte chunks, than the producer can *force* the consumer to allocate 128 megabytes, or either not process the message or do it unsafely.] Now, as efail demonstrated, we need to protect against ciphertext modifications, and we need to do it in a way that does not bring back the problems with requiring unbounded space that we're trying to address with streaming in the first place. Therefore, we need to use chunking and authenticate message prefixes. We need to use chunks that are reasonably small, and this size should preferably not be configurable. We should consider performance constraints and pick one suitable size. Configurable chunk sizes bring complexity and increase the attack surface, as was pointed out in this thread. The only argument for a configurable chunk size that came out of this thread is to be able to fit the entire message into one chunk. I appreciate the desire to protect against truncation. But, truncation is pretty common when we transmit data, so I'd argue that application developers are more likely to expect and gracefully deal with truncated data than with ciphertext being manipulated or the PGP implementation consuming unbounded amounts of memory. Now, you may say that even if the PGP implementation doesn't buffer the plaintext, the downstream consumer must buffer it in order to detect truncation. But that is not always true. As pointed out in this thread, you can use some kind of transaction scheme to only commit data once it has been confirmed to be not truncated. I have implemented AEAD in Sequoia, and I have evaluated the implementations in GnuPG and RNP. Every implementation is either unsafe, not robust, or does not implement the proposal. What is proposed in RFC4880-bis06 can not be implemented safely. If the working group produces a standard that cannot be implemented safely, I consider that a grave failure of the standardization effort. Thanks, Justus --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEJWpOVeSnLZetJGjniNx+MzhfeR0FAlycvlgACgkQiNx+Mzhf eR0K5AgAs+qyRhWlKfynCdqCIy3xunDMq3yyk6UQMCveYSz8B6vVsZOo+yvGptsg pHTzp/qr5k/YIwmAfI/HjttsGjnnzt+ruXoOIx4A+cII5KTZT1swUK/wVfiCyPfh jnH/QszDgTfcD4J5lbWX1p5s0emKddwDGMHuDw5J5+Pfv0HFLxSGeqNFHXYj4ZIT Zm03hbXPnxo/vd2BFyCaO4nfw/H4lyjrspnP4hBid9HOXpUfBVJ3Jss8kfwfV4Qs Kj3wfTxQMDAI8joEYyoIx3T1KKMe6g2UuzpWTwRXwl27WcV5CcjjaKu54RxeHITW ZMpZrygkQZBYz2AOLLNbZ1D6NzBlCA== =4Cuw -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 28 11:54:36 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB67A12000F for ; Thu, 28 Mar 2019 11:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 ShKxUrH3CGGH for ; Thu, 28 Mar 2019 11:54:31 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3515F120313 for ; Thu, 28 Mar 2019 11:54:26 -0700 (PDT) Received: from [47.143.125.151] (helo=Williams-MacBook-Pro.local) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1h9aAT-0002v0-0z; Thu, 28 Mar 2019 14:54:25 -0400 Date: Thu, 28 Mar 2019 11:54:23 -0700 From: Bill Frantz To: Justus Winter cc: openpgp@ietf.org X-Priority: 3 In-Reply-To: <878swzp4fb.fsf@europa.jade-hamburg.de> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4.3 (480) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79bbb8b28946efe7db03e133594f3c9b02350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 47.143.125.151 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 18:54:34 -0000 On 3/28/19 at 5:30 AM, justuswinter@gmail.com (Justus Winter) wrote: >For me, using an unbounded amount of memory is not an option for a >component processing OpenPGP data if we want to build robust systems >on top. Can't you follow Jon's advice: On 3/20/19 at 12:36 PM, joncallas=3D40icloud.com@dmarc.ietf.org=20 (Jon Callas) wrote: >To address your point, as I said in my long missive, you can do=20 >this today. No changes are needed to the protocol. All you have=20 >to do is put a compression preference on your key that says no=20 >compression, and then you won=E2=80=99t get compression. (Well, to be=20 >completely correct, if someone compresses then they=E2=80=99re=20 >non-compliant to the standard.) Repeating myself, I support and=20 >encourage implementations to do that by default. You can then treat any message that uses compression as=20 malicious and refuse to process it. Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | When it comes to the world | Periwinkle (408)356-8506 | around us, is there any choice | 16345=20 Englewood Ave www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos,=20 CA 95032 From nobody Thu Mar 28 12:33:45 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EABCD12032E for ; Thu, 28 Mar 2019 12:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com 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 rTGskooPmFuo for ; Thu, 28 Mar 2019 12:33:42 -0700 (PDT) Received: from mr85p00im-zteg06021901.me.com (mr85p00im-zteg06021901.me.com [17.58.23.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F111A120282 for ; Thu, 28 Mar 2019 12:33:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1553801621; bh=tdEZRuGlVe0kH1HfknFqp3a69PquUapQqfg+Db42Bq0=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=ar3bIEVGBNOOLbspuxVdcNKr9ou0Zk7y3Uh9wst5/8002LtiBM24iSkWT7gtJ8919 gEDIoFTscjhn0gu1SfljOM2ORKSBXOvrKOKJlXyqBFUw438+evFSH0G3/3hwPs2asL wnQx6KEVwhzeCFqwg/rgAzkguwNLpVovLEkYLwkVPl4UI9uOluPJKiPwslQqweG5Yd lpHqrSUv0py8v3HKxGuO7EIEyyY0fARiLIPKBrQWD1zIVPWJcqUynI8WzlOkQxYBHR Ki09vi1Ra3rIrwzWQIVq/ItjnC4CeolcyQQgLWKFBWoaUzIgGlGDlmaCgmYM8HNXlr 5tS5y1HKKbT+g== Received: from [10.125.12.152] (67-207-120-150.static.wiline.com [67.207.120.150]) by mr85p00im-zteg06021901.me.com (Postfix) with ESMTPSA id 056747201AA; Thu, 28 Mar 2019 19:33:40 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Jon Callas In-Reply-To: Date: Thu, 28 Mar 2019 12:33:39 -0700 Cc: Jon Callas , Tobias Mueller , Werner Koch , "openpgp@ietf.org OpenPGP" , "Neal H. Walfield" , Vincent Breitmoser Content-Transfer-Encoding: quoted-printable Message-Id: References: <87d0n174w6.fsf@wheatstone.g10code.de> <87mumh33nc.wl-neal@walfield.org> <3GFS71V7BTJNZ.29C5TO8OY0O44@my.amazin.horse> <87r2bax5u2.wl-neal@walfield.org> <87pnqtwot9.wl-neal@walfield.org> <0f7f492bf18145f96e70886ba19ba290.squirrel@mail2.ihtfp.org> <87lg1gwelf.wl-neal@walfield.org> <61e3fb9d194d0b47f21be8e176daa0b9b6c5d0a5.camel@cryptobitch.de> <87sgvkihd1.wl-neal@walfield.org> <241225ce914a1843b48dab304c760151fe05b764.camel@cryptobitch.de> <87imwfj3oq.wl-neal@walfield.org> <65e588255c689d329546c3908dac112896d029ca.camel@cryptobitch.de> To: Derek Atkins X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-28_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=773 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1903280126 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 19:33:44 -0000 > On Mar 27, 2019, at 8:50 AM, Derek Atkins wrote: >=20 > In my mind, each chunk is its own AEAD ciphertext. So the chunking is > happening *during* AEAD encryption, and not after encryption. I.e., = the > chunking and AEAD encryption should be tied together such that the = chunk > header is part of the AEAD protection and the chunk data is the AEAD > encrypted data. >=20 > This approach does, IMHO, map directly into the RFC definition. This is exactly what I presumed would be done =E2=80=94 each chunk is an = AEAD segment. I presumed that one would probably put a chunk number as = Additional Data, and that the nonce context would carry over from one = chunk to the next in some reasonable way. That=E2=80=99s directly analogous to the present chunking mechanism, = which uses CFB as a stream. Jon From nobody Thu Mar 28 14:27:37 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D552F1202C1 for ; Thu, 28 Mar 2019 14:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com 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 CtHgpeqzED3P for ; Thu, 28 Mar 2019 14:27:34 -0700 (PDT) Received: from mr85p00im-zteg06012001.me.com (mr85p00im-zteg06012001.me.com [17.58.23.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28E0712003F for ; Thu, 28 Mar 2019 14:27:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1553808453; bh=JYfh3O61d/f5M3Ngg2rrw+SzVE5awiD4HmTNNS68e8o=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=m1Fz5zTtmuwemxlOSRdacg/tSt8Vo6pybq5FqFjExWGo+y46wJ3HIraQwHj0V49h+ RxAmBCjMgJkBMi2IPMg9kXbD1xcM6WDg/vAIPGY8RGU3XYRLsVOMgjecJgJVIxjvhP 44Hs9DCyfuzqWXYYeBLjbnEGVwvqu2u57UHmlA9SWEIZtqd78ikkhHnyy9lp4r4P+Z XOEV4/0x+giNy386s8allbogR4sn2LM/uVjiZUEGen1bxv9Ll7BkoIPYKwJKJjh7Rc Y4YT1zSxBpQ28wQPkakiw1EP9jO7JQe72POAqhyEVpR11Xa4FfuZOsFWEjo9HgP025 UaxzBpw/Q9RMw== Received: from [10.125.12.152] (67-207-120-150.static.wiline.com [67.207.120.150]) by mr85p00im-zteg06012001.me.com (Postfix) with ESMTPSA id 1B526A001AC; Thu, 28 Mar 2019 21:27:33 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Jon Callas In-Reply-To: <878swzp4fb.fsf@europa.jade-hamburg.de> Date: Thu, 28 Mar 2019 14:27:27 -0700 Cc: Jon Callas , openpgp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> To: Justus Winter X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-28_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1903280138 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 21:27:36 -0000 > On Mar 28, 2019, at 5:30 AM, Justus Winter = wrote: >=20 [=E2=80=A6] > In the context of processing OpenPGP data, currently there is no > relation between the size of the encrypted message and the size of the > decrypted message. This is due to compression. =20 This isn=E2=80=99t precisely true. Certainly, compression is the biggest = factor here, but it is not the only one. There are many factors that = make it hard to know the finished size of an OpenPGP message a priori. = These include ASCII armor, TEXT mode plaintext, and others. It only gets = worse inside the plaintext where there is typically in emails = quoted-printable, further base64, both, and other bits of brain damage = caused by the accretion of many things that were good ideas at the time. >=20 > For me, using an unbounded amount of memory is not an option for a > component processing OpenPGP data if we want to build robust systems > on top. Okay, prior to this working group, when there was running code without a = consensus rough or not, this problem existed. Even with compression, PGP = 2 ran on DOS machines with a max of 640K of RAM. There are many = similarly constrained systems that run OpenPGP implementations. >=20 > Therefore, we need to process OpenPGP data in bounded space. Since > there can be no relation between encrypted and decrypted message size > due to compression, the only option I see is to provide a streaming > API, which let's us process data in constant space. I=E2=80=99m not quite sure what you mean when you say =E2=80=9Cbounded = space=E2=80=9D because one interpretation of that is obviously false. = OpenPGP has always supported being able to process messages where the = encryptor does not know the size ahead of time. That=E2=80=99s why we = have indeterminate lengths and chunking. I presume you mean that the implementation has to have constraints on = its resources. This is certainly true; there are no unconstrained = systems. It=E2=80=99s also true that there are going to be messages that = your implementation can=E2=80=99t process well. For example, RFC 4880 = allows a partial body length (a chunk) to be 2^30 octets, and that could = be irritating to handle. One of (perhaps unstated) goals of OpenPGP is that it allow for highly = constrained implementations. This was a huge consideration in both 2440 = and 4880. There are things that are designs the way they are because the = working group felt strongly that things have to be one-pass. There were = many debates about the MDC that boil down to it (and this is also the = reason why HMAC wasn=E2=80=99t used, but there more history there, = including that while HMAC existed when the MDC was designed, we did not = yet have a proof of security for it. >=20 > [Now, when I say constant space, implementations could still decide to > use, say, 30 megabytes of buffer space. Then, most emails will fit > into this buffer, and we can detect truncated messages before we hand > out one byte to the downstream application. This is what we do in > Sequoia. Note, however, that the consumer decides how much data to > buffer before releasing the first data, and not the producer. If we > decide to even allow 128 megabyte chunks, than the producer can > *force* the consumer to allocate 128 megabytes, or either not process > the message or do it unsafely.] Or the consumer could return an error and say it can=E2=80=99t decode = it. >=20 > Now, as efail demonstrated, we need to protect against ciphertext > modifications, and we need to do it in a way that does not bring back > the problems with requiring unbounded space that we're trying to > address with streaming in the first place. Efail is primarily a problem with MIME encoding and layering violations. = It works just as much with S/MIME as OpenPGP. Perhaps I=E2=80=99m = missing something, but I don=E2=80=99t see how Efail is relevant to = resource bounds. >=20 > Therefore, we need to use chunking and authenticate message prefixes. > We need to use chunks that are reasonably small, and this size should > preferably not be configurable. We should consider performance > constraints and pick one suitable size. Configurable chunk sizes > bring complexity and increase the attack surface, as was pointed out > in this thread. >=20 I=E2=80=99m with you on a lot of this, but I don=E2=80=99t know what you = mean by =E2=80=9Cconfigurable=E2=80=9D? Do you mean that there should be = one chunk size only? If so, what size do you propose? 32 Meg or = thereabouts (2^25 is in that ball park)? If so, would that mean that all = messages smaller than your chunk size would be a single chunk?=20 > The only argument for a configurable chunk size that came out of this > thread is to be able to fit the entire message into one chunk. That=E2=80=99s not the way I understand the discussion. The way I = understand it, there are people who desire to have single-chunk messages = of a rather large size. At present, the non-AEAD chunks can be any power = of 2 up to 2^30 (but the first one has to be at least 2^9). I don=E2=80=99= t see the request for variable (is that the same thing as configurable?) = chunk sizes to be anything other than the analogue of the present = situation. >=20 > I appreciate the desire to protect against truncation. But, > truncation is pretty common when we transmit data, so I'd argue that > application developers are more likely to expect and gracefully deal > with truncated data than with ciphertext being manipulated or the PGP > implementation consuming unbounded amounts of memory. Does this mean that you think that message truncation is an error that = OpenPGP doesn=E2=80=99t need to guard against? That=E2=80=99s the way I interpret the first line in the paragraph above = (=E2=80=9CI appreciate =E2=80=A6 But,=E2=80=A6=E2=80=9D). If so, = that=E2=80=99s counter to the long-standing consensus of the working = group. It=E2=80=99s the whole reason we have MDCs and the reason why = they were aggressively pushed in the implementations and non-MDC packets = browbeaten into doing MDCs. See the non-normative discussion in section = 5.13 of 4880. >=20 > Now, you may say that even if the PGP implementation doesn't buffer > the plaintext, the downstream consumer must buffer it in order to > detect truncation. But that is not always true. As pointed out in > this thread, you can use some kind of transaction scheme to only > commit data once it has been confirmed to be not truncated. I think I understand. Are you noting that because of the one-pass nature = of OpenPGP, it=E2=80=99s possible to process arbitrary amounts of data = and not know that there=E2=80=99s an error until the end? This is = certainly true of MDCs, because of the one-pass desire. If you make an = implementation that has AEAD chunks, it=E2=80=99s possible that you = could be processing correct chunks for an indefinite amount of time, and = then get an AEAD failure that calls into question the integrity of the = whole stream that led up to that. Is that what you=E2=80=99re pointing out? >=20 >=20 > I have implemented AEAD in Sequoia, and I have evaluated the > implementations in GnuPG and RNP. Every implementation is either > unsafe, not robust, or does not implement the proposal. Tell us more. What problems did you find? >=20 > What is proposed in RFC4880-bis06 can not be implemented safely. If = the > working group produces a standard that cannot be implemented safely, I > consider that a grave failure of the standardization effort. Okay, you=E2=80=99ve lost me. What can=E2=80=99t be implemented safely and why? In my reading of this, I think I have identified two points you=E2=80=99re= making. (1) It=E2=80=99s possible for a chunk to be larger than reasonable = processing resources. (2) It=E2=80=99s possible for a long stream to have an error in the last = chunk that signals an error wayyyyyy in the past. Handling (1) is reasonably easy. Return an error. This situation exists = today. It=E2=80=99s possible to make partial bodies of a gigabyte each, = and an implementation may not be able to handle that. Return an error. Handling (2) is also easy, you return an error. This might be = unsatisfying, because the error might be in the past, and lots of stuff = already handled. Is this your objection? Jon From nobody Thu Mar 28 15:05:05 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1193B120418 for ; Thu, 28 Mar 2019 15:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=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 KdRGT3j-sKgi for ; Thu, 28 Mar 2019 15:05:00 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 80AAE1203DF for ; Thu, 28 Mar 2019 15:05:00 -0700 (PDT) Received: from p57b22663.dip0.t-ipconnect.de ([87.178.38.99] helo=chu.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1h9d8r-0007G7-Eg; Thu, 28 Mar 2019 22:04:57 +0000 Date: Thu, 28 Mar 2019 23:04:56 +0100 Message-ID: <8736n63bav.wl-neal@walfield.org> From: "Neal H. Walfield" To: Jon Callas Cc: Justus Winter , openpgp@ietf.org, Jon Callas In-Reply-To: References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-2022-JP Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 22:05:04 -0000 At Thu, 28 Mar 2019 14:27:27 -0700, Jon Callas wrote: > > For me, using an unbounded amount of memory is not an option for a > > component processing OpenPGP data if we want to build robust systems > > on top. > > Okay, prior to this working group, when there was running code > without a consensus rough or not, this problem existed. Even with > compression, PGP 2 ran on DOS machines with a max of 640K of > RAM. There are many similarly constrained systems that run OpenPGP > implementations. Until now, OpenPGP didn't require buffering data. A decrypted AEAD chunk MUST only be released when it has been authenticated. In the current proposal, AEAD chunks are potentially unbounded (well, up to 4 exabytes...) in size. No one can decrypt such chunks without cheating, i.e., releasing unauthenticated plaintext. > > Therefore, we need to process OpenPGP data in bounded space. Since > > there can be no relation between encrypted and decrypted message size > > due to compression, the only option I see is to provide a streaming > > API, which let's us process data in constant space. > > I$B!G(Bm not quite sure what you mean when you say $B!H(Bbounded space$B!I(B > because one interpretation of that is obviously false. OpenPGP has > always supported being able to process messages where the encryptor > does not know the size ahead of time. That$B!G(Bs why we have > indeterminate lengths and chunking. [snip] > For example, RFC 4880 allows a partial body length (a chunk) to be > 2^30 octets, and that could be irritating to handle. indeterminate lengths and partial body chunking don't prohibit the implementation from releasing the text early; there is no requirement to buffer the whole chunk. > One of (perhaps unstated) goals of OpenPGP is that it allow for > highly constrained implementations. This was a huge consideration in > both 2440 and 4880. We are arguing within this tradition. We want highly constrained systems to be able to process (nearly) all OpenPGP messages in a *conforming* manner. AEAD mandates buffering whole chunks, because unauthenticated plaintext MUST NOT be released. By limiting chunks to some kilobytes in size, highly constrained systems will be able to process these messages without releasing unauthenticated plaintext. > Efail is primarily a problem with MIME encoding and layering violations. It works just as much with S/MIME as OpenPGP. Perhaps I$B!G(Bm missing something, but I don$B!G(Bt see how Efail is relevant to resource bounds. EFAIL is also about ciphertext modification. If an implementation never releases unauthenticated plaintext, then ciphertext modification is not possible. Highly constrained systems can do this if the chunk size is limited to something they can handle. > > Therefore, we need to use chunking and authenticate message prefixes. > > We need to use chunks that are reasonably small, and this size should > > preferably not be configurable. We should consider performance > > constraints and pick one suitable size. Configurable chunk sizes > > bring complexity and increase the attack surface, as was pointed out > > in this thread. > > > > I$B!G(Bm with you on a lot of this, but I don$B!G(Bt know what you mean by $B!H(Bconfigurable$B!I(B? Do you mean that there should be one chunk size only? If so, what size do you propose? 32 Meg or thereabouts (2^25 is in that ball park)? If so, would that mean that all messages smaller than your chunk size would be a single chunk? Configurable means that the chunk size is not fixed by the standard. There are two proposals right now: we either fix the chunk size to 16kb (support by Justus, Sebastian and I) or to 256kb (preferred by Bart from Proton Mail, since that is what they are using in practice). > > I appreciate the desire to protect against truncation. But, > > truncation is pretty common when we transmit data, so I'd argue that > > application developers are more likely to expect and gracefully deal > > with truncated data than with ciphertext being manipulated or the PGP > > implementation consuming unbounded amounts of memory. > > Does this mean that you think that message truncation is an error that OpenPGP doesn$B!G(Bt need to guard against? > > That$B!G(Bs the way I interpret the first line in the paragraph above ($B!H(BI appreciate $B!D(B But,$B!D!I(B). If so, that$B!G(Bs counter to the long-standing consensus of the working group. It$B!G(Bs the whole reason we have MDCs and the reason why they were aggressively pushed in the implementations and non-MDC packets browbeaten into doing MDCs. See the non-normative discussion in section 5.13 of 4880. Either you stream or you protect against truncation. I don't see how you can do both. That doesn't mean you can't detect truncation and signal that it occurred. Indeed, that is a property that MDC and signatures provide. But, then it is up to the application to recover. (Perhaps the application, with or without the help of the OpenPGP implementation, simply buffers the whole message or a sufficiently large prefix. But, that is built on top. We want OpenPGP to remain streamable.) > > I have implemented AEAD in Sequoia, and I have evaluated the > > implementations in GnuPG and RNP. Every implementation is either > > unsafe, not robust, or does not implement the proposal. > > Tell us more. What problems did you find? Sequoia is written in Rust, and in Rust out of memory errors are fatal. Handling a 4 exabyte chunk would result in an out of memory error, and termination of the process. Both GnuPG and RNP process unauthenticated plaintext. They release the plaintext for further processing before it is authenticated by the AEAD tag. > In my reading of this, I think I have identified two points you$B!G(Bre making. > > (1) It$B!G(Bs possible for a chunk to be larger than reasonable processing resources. > (2) It$B!G(Bs possible for a long stream to have an error in the last chunk that signals an error wayyyyyy in the past. > > Handling (1) is reasonably easy. Return an error. This situation exists today. It$B!G(Bs possible to make partial bodies of a gigabyte each, and an implementation may not be able to handle that. Return an error. I don't understand why partial bodies are relevant here. They are quite easy to implement using a small buffer even given large partial body chunks. The issue with returning an error in the face of large AEAD chunks is that it is completely gratuitous. If the sender had only used a small chunk size, it would have been possible to authenticate the ciphertext! What is the advantage of large AEAD chunks (serious question!)? It seems their only effect is to encourage the release of unauthenticated plaintext. > Handling (2) is also easy, you return an error. This might be unsatisfying, because the error might be in the past, and lots of stuff already handled. Is this your objection? Supporting stream means allowing for truncation. We want streaming, and we are prepared to handle truncation should it occur. Thanks, :) Neal From nobody Thu Mar 28 16:48:01 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8776A12041F for ; Thu, 28 Mar 2019 16:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com 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 ddjFW5eX_Bnq for ; Thu, 28 Mar 2019 16:47:53 -0700 (PDT) Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D354C12040B for ; Thu, 28 Mar 2019 16:47:52 -0700 (PDT) Date: Thu, 28 Mar 2019 23:47:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1553816870; bh=FMPL+an91tdgGZe5DhlAeq/LYoSfTzDh05uEWB72/6E=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=tL3+jk9DgOwGY9ktEAlif/peMjPPb67KOf3N+gHlvBr281tdSnfgPwSkEQCnbKY6+ JAJKhNfC9HuExyGuqkG+fe60j+HCI7a3N7oiHDGO+H+AYY2ZazY5jtKkuCPt+Gx8Ua AcY+C3g5hBJ8fW8nv46Yv3hsnBWYoyW6S6s8GfkU= To: "Neal H. Walfield" From: Bart Butler Cc: Jon Callas , "openpgp@ietf.org" , Justus Winter , Jon Callas Reply-To: Bart Butler Message-ID: In-Reply-To: <8736n63bav.wl-neal@walfield.org> References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <8736n63bav.wl-neal@walfield.org> Feedback-ID: XShtE-_o2KLy9dSshc6ANALRnvTQ9U24aqXW2ympbGschdpHbU6GYCTUCtfmGhY9HmOyP1Uweyandwh1AVDFrQ==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="---------------------e7b0eb1e008dbf82cc41ae97faf6f661"; charset=UTF-8 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 23:47:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------e7b0eb1e008dbf82cc41ae97faf6f661 Content-Type: multipart/mixed;boundary=---------------------46f29f4505eab5e3bad105d52045434a -----------------------46f29f4505eab5e3bad105d52045434a Content-Transfer-Encoding: quoted-printable Content-Type: text/plain;charset=utf-8 Hi Neal, Maybe a reasonable compromise is, as we discussed a while ago, simply an u= pper bound on the chunk size rather than fixing it to a single value. What= 's a reasonable upper bound for constrained systems? 4MB? And for others: what IS the use case for really large chunks? In the limit= of the message being one giant chunk, AEAD becomes essentially our curren= t MDC and loses all additional value it has in terms of streaming, which i= s detecting errors/modifications early rather than at the last possible mo= ment. Why allow producers to undermine this, given its the reason for its = existence? I agree with Jon that it's difficult to foresee future use cases, which is= why I don't favor removing the size entirely--if some compelling use case= for larger sizes appears, or for having a variety of small sizes (more li= kely IMHO), then great. But I have yet to see a compelling use case for really large AEAD chunks, = and two compelling reasons not to have them (embedded systems and general = poor UX in terms of not being able to error out early). So do we really no= t want to do some kind of reasonable upper limit in the RFC? It would be o= ne sentence in the RFC and minimal work for existing implementations to ca= p the AEAD chunk size to reasonable value. -Bart =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original M= essage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Thursday, March 28, 2019 3:04 PM, Neal H. Walfield = wrote: > At Thu, 28 Mar 2019 14:27:27 -0700, > Jon Callas wrote: > = > > > For me, using an unbounded amount of memory is not an option for a > > > component processing OpenPGP data if we want to build robust systems > > > on top. > > = > > Okay, prior to this working group, when there was running code > > without a consensus rough or not, this problem existed. Even with > > compression, PGP 2 ran on DOS machines with a max of 640K of > > RAM. There are many similarly constrained systems that run OpenPGP > > implementations. > = > Until now, OpenPGP didn't require buffering data. A decrypted AEAD > chunk MUST only be released when it has been authenticated. In the > current proposal, AEAD chunks are potentially unbounded (well, up to 4 > exabytes...) in size. No one can decrypt such chunks without > cheating, i.e., releasing unauthenticated plaintext. > = > > > Therefore, we need to process OpenPGP data in bounded space. Since > > > there can be no relation between encrypted and decrypted message siz= e > > > due to compression, the only option I see is to provide a streaming > > > API, which let's us process data in constant space. > > = > > I=E2=80=99m not quite sure what you mean when you say =E2=80=9Cbounded= space=E2=80=9D > > because one interpretation of that is obviously false. OpenPGP has > > always supported being able to process messages where the encryptor > > does not know the size ahead of time. That=E2=80=99s why we have > > indeterminate lengths and chunking. > = > [snip] > = > > For example, RFC 4880 allows a partial body length (a chunk) to be > > 2^30 octets, and that could be irritating to handle. > = > indeterminate lengths and partial body chunking don't prohibit the > implementation from releasing the text early; there is no requirement > to buffer the whole chunk. > = > > One of (perhaps unstated) goals of OpenPGP is that it allow for > > highly constrained implementations. This was a huge consideration in > > both 2440 and 4880. > = > We are arguing within this tradition. We want highly constrained > systems to be able to process (nearly) all OpenPGP messages in a > conforming manner. AEAD mandates buffering whole chunks, because > unauthenticated plaintext MUST NOT be released. By limiting chunks to > some kilobytes in size, highly constrained systems will be able to > process these messages without releasing unauthenticated plaintext. > = > > Efail is primarily a problem with MIME encoding and layering violation= s. It works just as much with S/MIME as OpenPGP. Perhaps I=E2=80=99m missi= ng something, but I don=E2=80=99t see how Efail is relevant to resource bo= unds. > = > EFAIL is also about ciphertext modification. If an implementation > never releases unauthenticated plaintext, then ciphertext modification > is not possible. Highly constrained systems can do this if the chunk > size is limited to something they can handle. > = > > > Therefore, we need to use chunking and authenticate message prefixes= . > > > We need to use chunks that are reasonably small, and this size shoul= d > > > preferably not be configurable. We should consider performance > > > constraints and pick one suitable size. Configurable chunk sizes > > > bring complexity and increase the attack surface, as was pointed out > > > in this thread. > > = > > I=E2=80=99m with you on a lot of this, but I don=E2=80=99t know what y= ou mean by =E2=80=9Cconfigurable=E2=80=9D? Do you mean that there should b= e one chunk size only? If so, what size do you propose? 32 Meg or thereabo= uts (2^25 is in that ball park)? If so, would that mean that all messages = smaller than your chunk size would be a single chunk? > = > Configurable means that the chunk size is not fixed by the standard. > There are two proposals right now: we either fix the chunk size to > 16kb (support by Justus, Sebastian and I) or to 256kb (preferred by > Bart from Proton Mail, since that is what they are using in practice). > = > > > I appreciate the desire to protect against truncation. But, > > > truncation is pretty common when we transmit data, so I'd argue that > > > application developers are more likely to expect and gracefully deal > > > with truncated data than with ciphertext being manipulated or the PG= P > > > implementation consuming unbounded amounts of memory. > > = > > Does this mean that you think that message truncation is an error that= OpenPGP doesn=E2=80=99t need to guard against? > > That=E2=80=99s the way I interpret the first line in the paragraph abo= ve (=E2=80=9CI appreciate =E2=80=A6 But,=E2=80=A6=E2=80=9D). If so, that=E2= =80=99s counter to the long-standing consensus of the working group. It=E2= =80=99s the whole reason we have MDCs and the reason why they were aggres= sively pushed in the implementations and non-MDC packets browbeaten into d= oing MDCs. See the non-normative discussion in section 5.13 of 4880. > = > Either you stream or you protect against truncation. I don't see how > you can do both. That doesn't mean you can't detect truncation and > signal that it occurred. Indeed, that is a property that MDC and > signatures provide. But, then it is up to the application to recover. > (Perhaps the application, with or without the help of the OpenPGP > implementation, simply buffers the whole message or a sufficiently > large prefix. But, that is built on top. We want OpenPGP to remain > streamable.) > = > > > I have implemented AEAD in Sequoia, and I have evaluated the > > > implementations in GnuPG and RNP. Every implementation is either > > > unsafe, not robust, or does not implement the proposal. > > = > > Tell us more. What problems did you find? > = > Sequoia is written in Rust, and in Rust out of memory errors are > fatal. Handling a 4 exabyte chunk would result in an out of memory > error, and termination of the process. > = > Both GnuPG and RNP process unauthenticated plaintext. They release > the plaintext for further processing before it is authenticated by the > AEAD tag. > = > > In my reading of this, I think I have identified two points you=E2=80=99= re making. > > (1) It=E2=80=99s possible for a chunk to be larger than reasonable pro= cessing resources. > > (2) It=E2=80=99s possible for a long stream to have an error in the la= st chunk that signals an error wayyyyyy in the past. > > Handling (1) is reasonably easy. Return an error. This situation exist= s today. It=E2=80=99s possible to make partial bodies of a gigabyte each, = and an implementation may not be able to handle that. Return an error. > = > I don't understand why partial bodies are relevant here. They are > quite easy to implement using a small buffer even given large partial > body chunks. > = > The issue with returning an error in the face of large AEAD chunks is > that it is completely gratuitous. If the sender had only used a small > chunk size, it would have been possible to authenticate the > ciphertext! > = > What is the advantage of large AEAD chunks (serious question!)? It > seems their only effect is to encourage the release of unauthenticated > plaintext. > = > > Handling (2) is also easy, you return an error. This might be unsatisf= ying, because the error might be in the past, and lots of stuff already ha= ndled. Is this your objection? > = > Supporting stream means allowing for truncation. We want streaming, > and we are prepared to handle truncation should it occur. > = > Thanks, > = > :) Neal > = > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp -----------------------46f29f4505eab5e3bad105d52045434a-- -----------------------e7b0eb1e008dbf82cc41ae97faf6f661 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail Comment: https://protonmail.com wl4EARYKAAYFAlydXSMACgkQmQVEZe8zHkTKRAD7BwJMcCsRf30lZ8nsKP+6 fIG7KI1HnafEKBcAFnAi2mQA/jBO34SwEcaPRYcLnG2sY3+Z/rCgLMUVXVeY SP/GZA4O =cUTI -----END PGP SIGNATURE----- -----------------------e7b0eb1e008dbf82cc41ae97faf6f661-- From nobody Thu Mar 28 16:58:40 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91AA1120342 for ; Thu, 28 Mar 2019 16:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ruhr-uni-bochum.de 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 U-bemqG8gN2Z for ; Thu, 28 Mar 2019 16:58:34 -0700 (PDT) Received: from out1.mail.ruhr-uni-bochum.de (out1.mail.ruhr-uni-bochum.de [IPv6:2a05:3e00:8:1001::8693:3595]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 564BA120308 for ; Thu, 28 Mar 2019 16:58:34 -0700 (PDT) Received: from mx1.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by out1.mail.ruhr-uni-bochum.de (Postfix mo-ext) with ESMTP id 44VhfJ0PGLz4ww0 for ; Fri, 29 Mar 2019 00:58:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ruhr-uni-bochum.de; s=mail-2017; t=1553817528; bh=rM9X5NMmmpZv/YuI3MYT7wA2iLMnixeipxcqkMDiCaY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=o6smD6xJ0dWG+SGknlAfZJIZ4T+aVVxaMULxtXqYQdzQKz/JMXJzbvZMBQMib7+SX HExXJ16+LXbQF+ouI3N+Vy5qq6jtxUG4P4Wekkz8ZYqvtvl+O/LQ/ysux6y4U3Q7OB Kgw141QCk/gdQVH039XIjlYYg6tl4yItNHSDugpQ= Received: from out1.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by mx1.mail.ruhr-uni-bochum.de (Postfix idis) with ESMTP id 44VhfH6p7gz4ww1 for ; Fri, 29 Mar 2019 00:58:47 +0100 (CET) X-Envelope-Sender: X-RUB-Notes: Internal origin=134.147.42.227 Received: from mail1.mail.ruhr-uni-bochum.de (mail1.mail.ruhr-uni-bochum.de [134.147.42.227]) by out1.mail.ruhr-uni-bochum.de (Postfix mi-int) with ESMTP id 44VhfH6Vlyz4ww0 for ; Fri, 29 Mar 2019 00:58:47 +0100 (CET) Received: from [192.168.142.139] (p4FE3FD47.dip0.t-ipconnect.de [79.227.253.71]) by mail1.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 44Vhdy2w5rzytS for ; Fri, 29 Mar 2019 00:58:30 +0100 (CET) To: openpgp@ietf.org References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> From: Marcus Brinkmann Openpgp: preference=signencrypt Message-ID: Date: Fri, 29 Mar 2019 00:58:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.4 at mail1.mail.ruhr-uni-bochum.de X-Virus-Status: Clean Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 23:58:39 -0000 The main question here is: What should a conforming application look like? The current behaviour of GnuPG is that it will process internally (e.g., through the decompression and signature verification layer) and output externally unauthenticated plaintext. If an AEAD chunk is modified by an attacker, GnuPG will detect the modification and cancel the operation, but only at the end of each chunk. Due to the asynchronous buffer management in GnuPG, quite often some part of the modified chunk has then already been processed and output, depending on the particular state of the buffers, the buffer size and the chunk size. This behaviour increases the surface for chosen ciphertext attacks and possibly adaptive chosen plaintext attacks (if an oracle is exposed). The criticism here is mainly targeted at the following reasoning: If the AEAD chunk size is not bounded to reasonable length, any conforming implementation will have to implement a mode of operation that is similar to the one currently implemented in GnuPG. As a consequence, to decrease development cost, most implementations will _only_ have this one implementation (as opposed to two implementations, one for large chunks and one for reasonably short chunks). This assumption is strengthened by the observation that GnuPG is de-facto norm-setting, due to its popularity and the lack of standardization activity. Again: What should a conforming implementation look like? The current draft proposal will lead, I think, to a world where most conforming OpenPGP implementations will never benefit from the non-malleability properties of AEAD cipher modes. A proposal restricting the chunk length to a reasonable value will lead, I hope, to a world where most OpenPGP implementations will benefit from the non-malleability of AEAD. There are many other areas where the OpenPGP standard does not specify reasonable lengths, but implementations do impose such restrictions. In my opinion, this is a mistake rather than a precedent to follow. Thanks, Marcus On 3/28/19 10:27 PM, Jon Callas wrote: > > >> On Mar 28, 2019, at 5:30 AM, Justus Winter wrote: >> > > […] > >> In the context of processing OpenPGP data, currently there is no >> relation between the size of the encrypted message and the size of the >> decrypted message. This is due to compression. > > This isn’t precisely true. Certainly, compression is the biggest factor here, but it is not the only one. There are many factors that make it hard to know the finished size of an OpenPGP message a priori. These include ASCII armor, TEXT mode plaintext, and others. It only gets worse inside the plaintext where there is typically in emails quoted-printable, further base64, both, and other bits of brain damage caused by the accretion of many things that were good ideas at the time. > >> >> For me, using an unbounded amount of memory is not an option for a >> component processing OpenPGP data if we want to build robust systems >> on top. > > Okay, prior to this working group, when there was running code without a consensus rough or not, this problem existed. Even with compression, PGP 2 ran on DOS machines with a max of 640K of RAM. There are many similarly constrained systems that run OpenPGP implementations. > >> >> Therefore, we need to process OpenPGP data in bounded space. Since >> there can be no relation between encrypted and decrypted message size >> due to compression, the only option I see is to provide a streaming >> API, which let's us process data in constant space. > > I’m not quite sure what you mean when you say “bounded space” because one interpretation of that is obviously false. OpenPGP has always supported being able to process messages where the encryptor does not know the size ahead of time. That’s why we have indeterminate lengths and chunking. > > I presume you mean that the implementation has to have constraints on its resources. This is certainly true; there are no unconstrained systems. It’s also true that there are going to be messages that your implementation can’t process well. For example, RFC 4880 allows a partial body length (a chunk) to be 2^30 octets, and that could be irritating to handle. > > One of (perhaps unstated) goals of OpenPGP is that it allow for highly constrained implementations. This was a huge consideration in both 2440 and 4880. There are things that are designs the way they are because the working group felt strongly that things have to be one-pass. There were many debates about the MDC that boil down to it (and this is also the reason why HMAC wasn’t used, but there more history there, including that while HMAC existed when the MDC was designed, we did not yet have a proof of security for it. > >> >> [Now, when I say constant space, implementations could still decide to >> use, say, 30 megabytes of buffer space. Then, most emails will fit >> into this buffer, and we can detect truncated messages before we hand >> out one byte to the downstream application. This is what we do in >> Sequoia. Note, however, that the consumer decides how much data to >> buffer before releasing the first data, and not the producer. If we >> decide to even allow 128 megabyte chunks, than the producer can >> *force* the consumer to allocate 128 megabytes, or either not process >> the message or do it unsafely.] > > Or the consumer could return an error and say it can’t decode it. > >> >> Now, as efail demonstrated, we need to protect against ciphertext >> modifications, and we need to do it in a way that does not bring back >> the problems with requiring unbounded space that we're trying to >> address with streaming in the first place. > > Efail is primarily a problem with MIME encoding and layering violations. It works just as much with S/MIME as OpenPGP. Perhaps I’m missing something, but I don’t see how Efail is relevant to resource bounds. > >> >> Therefore, we need to use chunking and authenticate message prefixes. >> We need to use chunks that are reasonably small, and this size should >> preferably not be configurable. We should consider performance >> constraints and pick one suitable size. Configurable chunk sizes >> bring complexity and increase the attack surface, as was pointed out >> in this thread. >> > > I’m with you on a lot of this, but I don’t know what you mean by “configurable”? Do you mean that there should be one chunk size only? If so, what size do you propose? 32 Meg or thereabouts (2^25 is in that ball park)? If so, would that mean that all messages smaller than your chunk size would be a single chunk? > >> The only argument for a configurable chunk size that came out of this >> thread is to be able to fit the entire message into one chunk. > > That’s not the way I understand the discussion. The way I understand it, there are people who desire to have single-chunk messages of a rather large size. At present, the non-AEAD chunks can be any power of 2 up to 2^30 (but the first one has to be at least 2^9). I don’t see the request for variable (is that the same thing as configurable?) chunk sizes to be anything other than the analogue of the present situation. > >> >> I appreciate the desire to protect against truncation. But, >> truncation is pretty common when we transmit data, so I'd argue that >> application developers are more likely to expect and gracefully deal >> with truncated data than with ciphertext being manipulated or the PGP >> implementation consuming unbounded amounts of memory. > > Does this mean that you think that message truncation is an error that OpenPGP doesn’t need to guard against? > > That’s the way I interpret the first line in the paragraph above (“I appreciate … But,…”). If so, that’s counter to the long-standing consensus of the working group. It’s the whole reason we have MDCs and the reason why they were aggressively pushed in the implementations and non-MDC packets browbeaten into doing MDCs. See the non-normative discussion in section 5.13 of 4880. > >> >> Now, you may say that even if the PGP implementation doesn't buffer >> the plaintext, the downstream consumer must buffer it in order to >> detect truncation. But that is not always true. As pointed out in >> this thread, you can use some kind of transaction scheme to only >> commit data once it has been confirmed to be not truncated. > > I think I understand. Are you noting that because of the one-pass nature of OpenPGP, it’s possible to process arbitrary amounts of data and not know that there’s an error until the end? This is certainly true of MDCs, because of the one-pass desire. If you make an implementation that has AEAD chunks, it’s possible that you could be processing correct chunks for an indefinite amount of time, and then get an AEAD failure that calls into question the integrity of the whole stream that led up to that. > > Is that what you’re pointing out? > >> >> >> I have implemented AEAD in Sequoia, and I have evaluated the >> implementations in GnuPG and RNP. Every implementation is either >> unsafe, not robust, or does not implement the proposal. > > Tell us more. What problems did you find? > >> >> What is proposed in RFC4880-bis06 can not be implemented safely. If the >> working group produces a standard that cannot be implemented safely, I >> consider that a grave failure of the standardization effort. > > Okay, you’ve lost me. > > What can’t be implemented safely and why? > > In my reading of this, I think I have identified two points you’re making. > > (1) It’s possible for a chunk to be larger than reasonable processing resources. > (2) It’s possible for a long stream to have an error in the last chunk that signals an error wayyyyyy in the past. > > Handling (1) is reasonably easy. Return an error. This situation exists today. It’s possible to make partial bodies of a gigabyte each, and an implementation may not be able to handle that. Return an error. > > Handling (2) is also easy, you return an error. This might be unsatisfying, because the error might be in the past, and lots of stuff already handled. Is this your objection? > > Jon > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > -- Dipl.-Math. Marcus Brinkmann Lehrstuhl für Netz- und Datensicherheit Ruhr Universität Bochum Universitätsstr. 150, Geb. ID 2/461 D-44780 Bochum Telefon: +49 (0) 234 / 32-25030 http://www.nds.rub.de/chair/people/mbrinkmann From nobody Thu Mar 28 17:10:37 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA7B120071 for ; Thu, 28 Mar 2019 17:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Pd5Hp3PkQLHq for ; Thu, 28 Mar 2019 17:10:33 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3CBC120058 for ; Thu, 28 Mar 2019 17:10:31 -0700 (PDT) Received: from [47.143.125.151] (helo=Williams-MacBook-Pro.local) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1h9f6G-0004lG-Cx; Thu, 28 Mar 2019 20:10:24 -0400 Date: Thu, 28 Mar 2019 17:10:23 -0700 From: Bill Frantz To: Bart Butler cc: "Neal H. Walfield" , openpgp@ietf.org, Justus Winter , Jon Callas , Jon Callas X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4.3 (480) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec792f9a4961f53749a450bc229ccda9271c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 47.143.125.151 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 00:10:35 -0000 On 3/28/19 at 4:47 PM,=20 bartbutler=3D40protonmail.com@dmarc.ietf.org (Bart Butler) wrote: >Maybe a reasonable compromise is, as we discussed a while ago,=20 >simply an upper bound on the chunk size rather than fixing it=20 >to a single value. What's a reasonable upper bound for=20 >constrained systems? 4MB? The Arduino Uno, which the web site says is the most popular=20 Arduino in the line=20 , has: Flash Memory 32 KB (ATmega328P) of which 0.5 KB used by bootloader SRAM 2 KB (ATmega328P) EEPROM 1 KB (ATmega328P) So it might be able to use a chunk up to 1KB without having to=20 do the kind of pipelining that leads to security bugs and messy code. YMMV! In general, when asked about the smallest target for crypto=20 algorithms, I think it was in the cryptography mailing list, the=20 consensus was an 8 bit microprocessor with 64K of addressing=20 would always be the target. People will always find a use for=20 cheaper and smaller processors and 8 bits with 64K addresses=20 seems to be where we have settled. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | Truth and love must prevail | Periwinkle (408)356-8506 | over lies and hate. | 16345=20 Englewood Ave www.pwpconsult.com | - Vaclav Havel | Los Gatos,=20 CA 95032 From nobody Thu Mar 28 19:19:47 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0ABE1200EA for ; Thu, 28 Mar 2019 19:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com 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 xtvLrXv8t9NS for ; Thu, 28 Mar 2019 19:19:43 -0700 (PDT) Received: from mr85p00im-ztdg06011801.me.com (mr85p00im-ztdg06011801.me.com [17.58.23.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD84812001A for ; Thu, 28 Mar 2019 19:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1553825982; bh=7bzuQxAeNddbxdLtvjLclOo5se2q7S0Um+j1uuDo5Mk=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=T62depTQlOR/T2i1p2g/Ep7/9fko1B6xKDy2oCDlAMLdHMw/WZIpBZNoT0aji4RWS AIdOOQkA6PzPEDoFpeirjfFFGhxBSvAaNR7orYC2dF2W3glAftqmCQP6a2D7T3I9Im nto4sKM4ZJHWbinl5B7tbsp8PGVMaWZ89f+HmX73beTZIFywlTfsFS1McTG5h7JI/2 eHSnDp4R9DxUt+BL7RKA8j4B6bxMTVv0SNtLUZEvTXDDXzjKFAwg2n+4KHMR0/gXO7 ccM3zUVfcaIsMctiQdAfxlg5KMiQi71ED7HKJ+0P65cy8Xp97MOF/mvzyT+eztX6FD FMq+jj0A7FvFQ== Received: from [192.168.7.69] (thing1.merrymeet.com [173.164.244.99]) by mr85p00im-ztdg06011801.me.com (Postfix) with ESMTPSA id 8DB40C013C; Fri, 29 Mar 2019 02:19:41 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Jon Callas In-Reply-To: <8736n63bav.wl-neal@walfield.org> Date: Thu, 28 Mar 2019 19:19:39 -0700 Cc: Jon Callas , Jon Callas , Justus Winter , openpgp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <8736n63bav.wl-neal@walfield.org> To: "Neal H. Walfield" X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-29_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1903290016 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 02:19:46 -0000 I wrote a point-by-point reply and decided that that=E2=80=99s not = productive. I=E2=80=99m going to try to cut to the chase on this, so = forgive me if I have dodged an important point. I=E2=80=99m happy to = come back to it later. Like some interim replies, particularly Bart Butler, I thought we had a = rough consensus and that it was approximately: * MUST support 16KB chunks. * SHOULD support 256K chunks, as these are common (Protonmail). * MAY support larger up to the present very large size. * MAY reject or error out on chunks larger than 16KB, but repeating = ourselves, SHOULD support 256K. I think it=E2=80=99s also reasonable to just simplify it by making be = MUST support up to 256K. I don=E2=80=99t like getting rid of the SHOULD = clause, thus making it be either 16K or off in squishy land, but I = wouldn=E2=80=99t wring my wrists, I=E2=80=99d merely be a bit unhappy. I could also get behind a hard limit of 2^30 on the grounds that = that=E2=80=99s what we had for partial body lengths, but I understand = the comment that there are things like multi-terabyte S3 buckets and out = and out forbidding those to be single-chunk is a bit churlish, but only = a bit. If we really want to tie a bow around everything, then define some = notation or other marker so that an implementation can mark in a key = what the max chunk size is. How=E2=80=99s that? Now with some other points, I found myself going especially Socratic = because the missives that you and Justus wrote weren=E2=80=99t = *actionable*. When I was editor, a thing I would say from time to time = is at about 90% of the time someone would say, =E2=80=9CPlease change X = to Y for reason Z=E2=80=9D it would be a no-brainer to do so. Most of = the remaining 10% would end up with some reasonable debate than then an = answer. But if someone said, =E2=80=9CI think X is wrong=E2=80=9D then = 90% of the time nothing would happen because there=E2=80=99s nothing = actionable there, meaning that there=E2=80=99s no clear point for the = editor to be doing. All of these standards are at some level compromises = and there=E2=80=99s an old aphorism that the best compromise is one = where everyone is equally unhappy. In my particular case, I thought I mostly agreed with where you wanted = to go, but I completely disagreed with some of your premises, and = disagreed with some of the reasoning that got us to the conclusion I = agreed with. That=E2=80=99s why I was being so Socratic. I thought = before the missives today that we had a rough consensus and that I = agreed with y=E2=80=99all at some basic level. Then I thought we really = disagreed, and I gradually realized that we agree on the destination, = but not on the path of how to get there. If I may give some advice, it is better to make sure that your requests = are actionable. If they=E2=80=99re not, then you=E2=80=99re less likely = to get what you want, if for no other reason than the rest of us don=E2=80= =99t know what you want, we=E2=80=99re having to guess. The basic = argument that you were making =E2=80=94 that implementations such as = yours need tight constraints =E2=80=94 is one we all can get behind. The = other side here =E2=80=94 they want to do something kinda wacky (like = terabyte chunks) =E2=80=94 can be pushed off into the land of MAYs.=20 Okay, anyway. How=E2=80=99s that proposal I wrote above? Does it work for you? Does it = need tweaks?=20 Jon From nobody Thu Mar 28 20:06:29 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03AB41202DD for ; Thu, 28 Mar 2019 20:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 u94GQbgRjXud for ; Thu, 28 Mar 2019 20:06:25 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9D60120161 for ; Thu, 28 Mar 2019 20:06:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1553828785; x=1585364785; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NFdc1DCxIvXT4o28Bo+1C2+VOjz7bT/tlcKUtKVhk/I=; b=l6S1ACFrOPeKBL9EdKVrA9cvZezMHD1fzhfIpYcQlxvwwQuEQ790NODd U7lXi1emrykswq9sCrIC3VL9timsPHA1BNuzSZnKVmZS4S64OUfAaUgme yED+8Hcvwk/nw3CiRI9l0EaZiA/M9kRcCdlWXTqiGhi/9HToVlCi3nxHd nySmNQqSCDe+MERaQoEqFqxns/J1+SB/D3db7tgbnhf+WlHn4VX30Dv/9 ce+qvFBmBcJUdFFCSqElpIvBRH0PAi+mNg68xi24F5SsCLSskz40pwniJ 6F2P3hZmYMxF513gIvWPEzA42GoaeJ5p0lyuVe6R45Dsm0YY21Cfp0P0w A==; X-IronPort-AV: E=Sophos;i="5.60,283,1549882800"; d="scan'208";a="53614780" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.5 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-d.UoA.auckland.ac.nz) ([10.6.2.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 29 Mar 2019 16:06:17 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 29 Mar 2019 16:06:16 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Fri, 29 Mar 2019 16:06:15 +1300 From: Peter Gutmann To: Jon Callas , Justus Winter CC: "openpgp@ietf.org" , Jon Callas Thread-Topic: [openpgp] AEAD Chunk Size Thread-Index: AQHU5WH/TXThz2b5WUWEfgPFCGcCuqYgtWOAgAE4c+U= Date: Fri, 29 Mar 2019 03:06:15 +0000 Message-ID: <1553828768692.59292@cs.auckland.ac.nz> References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 03:06:28 -0000 Jon Callas writes:=0A= =0A= >Okay, prior to this working group, when there was running code without a= =0A= >consensus rough or not, this problem existed. Even with compression, PGP 2= =0A= >ran on DOS machines with a max of 640K of RAM.=0A= =0A= The constraint there was 64K, not 640K, the x86 segment size. Also, the wa= y=0A= PGP then handled it was to use intermediate files for everything, every sin= gle=0A= transformation wrote its own intermediate file to disk. Including, in the= =0A= worst case, prepending a single literal byte to the data.=0A= =0A= That's probably not a good example to cite :-).=0A= =0A= Peter.=0A= From nobody Thu Mar 28 20:17:10 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C23812016F for ; Thu, 28 Mar 2019 20:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 6kZhovazLFED for ; Thu, 28 Mar 2019 20:17:07 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71C2F120161 for ; Thu, 28 Mar 2019 20:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1553829426; x=1585365426; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IOlZmt17cvlZl9ChYtgsHW5upPNNGljv0h65JrSotNQ=; b=PKAsVdYyVk9pGsWpJV7ElHUyLDUx9m8F5453Yhy13QD7b9FKH1p7ZGZd p22lABTnVhHvN25dbsbs9uiFCs/AdR4yCOfaQuccqqvpgdneAxRMLtjJr THrsNtr2qr+K/cpj2IBKxk6Tbv37g57A4BclrEUn2yMeFBU+wAL0Jf47a EaC2tHI4VF6fenq/8CGFSVK9+CnDtYQzmPr/WHXNl+SwjLYTY3rKoypQ+ VOm1d5xGeeitC0QUU6MUxCyNmBOUsFMmkwJCJET1P+wfzNQZ4GJYWuhth Ao03bf48XIF3UqgwNUqk1CXiWLTm7RuYduNf+jDLuEuT3rGduGvmBM0jz g==; X-IronPort-AV: E=Sophos;i="5.60,283,1549882800"; d="scan'208";a="53616315" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.5 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-d.UoA.auckland.ac.nz) ([10.6.2.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 29 Mar 2019 16:17:04 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 29 Mar 2019 16:17:04 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Fri, 29 Mar 2019 16:17:04 +1300 From: Peter Gutmann To: "Neal H. Walfield" , Jon Callas CC: "openpgp@ietf.org" , Justus Winter , Jon Callas Thread-Topic: [openpgp] AEAD Chunk Size Thread-Index: AQHU5WH/TXThz2b5WUWEfgPFCGcCuqYgtWOAgAAKeQCAATDsKA== Date: Fri, 29 Mar 2019 03:17:03 +0000 Message-ID: <1553829416285.5270@cs.auckland.ac.nz> References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> , <8736n63bav.wl-neal@walfield.org> In-Reply-To: <8736n63bav.wl-neal@walfield.org> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 03:17:09 -0000 Neal H. Walfield writes:=0A= =0A= >Until now, OpenPGP didn't require buffering data. A decrypted AEAD chunk= =0A= >MUST only be released when it has been authenticated. In the current=0A= >proposal, AEAD chunks are potentially unbounded (well, up to 4 exabytes...= )=0A= >in size. No one can decrypt such chunks without cheating, i.e., releasing= =0A= >unauthenticated plaintext.=0A= =0A= This has been considered before, e.g. with S/MIME's authenticated encryptio= n:=0A= =0A= https://tools.ietf.org/html/rfc6476#section-6=0A= =0A= and so far doesn't seem to have caused any major problems. That is, it's n= ot=0A= that there's a perfect solution, it's that actual problem situations seem t= o=0A= be pretty rare.=0A= =0A= If you want to do it right, you'd really want some formal academic treatmen= t=0A= rather than guessing at chunk sizes and what may or may not be needed, i.e.= =0A= typical message size X, typical chunk size Y gives these security bounds. = PGP=0A= is typically used to encrypt data at rest (make the chunk size the file siz= e)=0A= or short email messages (chunk size doesn't matter, it's short). That leav= es=0A= a remainder of large emails, which we know exist but don't know how frequen= t=0A= they are or how often they're sent or from what sorts of systems.=0A= =0A= Without hard data on what's actually needed, we're just bikeshedding... whi= le=0A= blindfolded.=0A= =0A= Peter.=0A= From nobody Thu Mar 28 20:30:05 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35AE0120175 for ; Thu, 28 Mar 2019 20:30:04 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 XfGL9NCeBhba for ; Thu, 28 Mar 2019 20:30:02 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCBA7120169 for ; Thu, 28 Mar 2019 20:30:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1553830202; x=1585366202; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=n02UIkwa9nEh0ngGGma4SrcS+IN74sb4pO+ScUZfV0Y=; b=is8LJw6w2NzKphui9PIl5AzXj/fHmDkUfaGLhP6O6xp8MSi4mwqZbYeR mKqwrcau9EX4ZudIhmoDz/9ZoVCVRndZwXRWU2xcJnuhC327Nlu72dj/M yceEXF9z9mqyyOJ/lsC8Q4biXrYzzSucDhD4hlnqBNn82LSAFZGs+QqVx D5s7HGIBrM1gBKgtMOY55is2hY6femPEYJzT2E18JY4Pob7g4KZSXwHLW IPsqe3bDQ13cPgr8GUheN92/aLwFChp+7sobobtZ3KqScyNcMkcgtaexa nkSfkzJ7JY5OG35t5MoaUKGB5XSOfobhnoNUGuE4c0FTPO0Wf3YX/tQsY A==; X-IronPort-AV: E=Sophos;i="5.60,283,1549882800"; d="scan'208";a="53617940" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.3 - Outgoing - Outgoing Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-tdc-b.UoA.auckland.ac.nz) ([10.6.3.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 29 Mar 2019 16:30:00 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-b.UoA.auckland.ac.nz (10.6.3.3) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 29 Mar 2019 16:29:59 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Fri, 29 Mar 2019 16:29:59 +1300 From: Peter Gutmann To: "Neal H. Walfield" , Jon Callas CC: "openpgp@ietf.org" , Justus Winter , Jon Callas Thread-Topic: [openpgp] AEAD Chunk Size Thread-Index: AQHU5WH/TXThz2b5WUWEfgPFCGcCuqYgtWOAgAAKeQCAATDsKIAAAsbW Date: Fri, 29 Mar 2019 03:29:58 +0000 Message-ID: <1553830192011.47001@cs.auckland.ac.nz> References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> , <8736n63bav.wl-neal@walfield.org>,<1553829416285.5270@cs.auckland.ac.nz> In-Reply-To: <1553829416285.5270@cs.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 03:30:04 -0000 I wrote:=0A= =0A= >PGP is typically used to encrypt data at rest (make the chunk size the fil= e=0A= >size)=0A= =0A= Another thing with that particular case, if you get a MAC failure decryptin= g=0A= data at rest do you really care? It's more likely a bit-flip somewhere than= =0A= someone trying to tamper with your archived sales records from 2003, and I= =0A= suspect most people would rather have slightly corrupted data than no data = at=0A= all.=0A= =0A= That's the nice thing about the standard block cipher modes, they recover f= rom=0A= errors. In... oh, approximately 100% of the encrypted data I have lying=0A= around, I'll happily ignore any auth errors, I just want the plaintext back= .=0A= So while it's fun and geeky to dream up something using the latest trendy A= EAD=0A= modes, is it something that (a) is necessary and (b) people who aren't geek= s=0A= care about?=0A= =0A= Peter.=0A= From nobody Thu Mar 28 20:33:10 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAACC12016F for ; Thu, 28 Mar 2019 20:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 ZXdsTwQ-szp7 for ; Thu, 28 Mar 2019 20:33:06 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5FD5120133 for ; Thu, 28 Mar 2019 20:33:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1553830385; x=1585366385; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IT1Tcte4yGjCFlyyM/I3aXrswmiFH30n7cvCJKPP55w=; b=ldUMZCHuHlxHpFNg8FJis/qLoRbKQm9sddTZeV4cwpQNVkWce4IQC4cY ft+cj858tYxltn1tKpqIlZwFD79AKr+6IfqNNN+6F57YAYu+oGjnDPcoC zpxNrYDAhsPvQ0sdAsVhXf6mfDIV/QW8LajW7DZujoXD/6yTirqd7RE5L 9K1V+sTKeUcawCnOopVn8ORirBLg2cwSYfVOOe3E/kkfHzizPYEw1ls7s mk4oFq8Gr33OkrS6ELJqWPs11IglkaRBWEl3ZLF7anKkj2sjiapK/FOvI lm3fQUD+1T85vzk9aUTGmJ5W6TjjB86yQQCvpjfRv+jFwkhQXDf9tJ666 g==; X-IronPort-AV: E=Sophos;i="5.60,283,1549882800"; d="scan'208";a="53618377" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.9 - Outgoing - Outgoing Received: from uxcn13-tdc-e.uoa.auckland.ac.nz ([10.6.3.9]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 29 Mar 2019 16:33:03 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-e.UoA.auckland.ac.nz (10.6.3.9) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 29 Mar 2019 16:33:03 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Fri, 29 Mar 2019 16:33:03 +1300 From: Peter Gutmann To: Bill Frantz , Bart Butler CC: "openpgp@ietf.org" , Justus Winter , "Neal H. Walfield" , Jon Callas , Jon Callas Thread-Topic: [openpgp] AEAD Chunk Size Thread-Index: AQHU5WH/TXThz2b5WUWEfgPFCGcCuqYgtWOAgAAKeQCAABy9AIAABlCAgAESgl8= Date: Fri, 29 Mar 2019 03:33:03 +0000 Message-ID: <1553830376146.79046@cs.auckland.ac.nz> References: , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 03:33:08 -0000 Bill Frantz writes:=0A= =0A= >The Arduino Uno, which the web site says is the most popular Arduino in th= e=0A= >line=0A= >, has:=0A= >=0A= > Flash Memory 32 KB (ATmega328P) of which 0.5 KB used by bootloader=0A= > SRAM 2 KB (ATmega328P)=0A= > EEPROM 1 KB (ATmega328P)=0A= >=0A= >So it might be able to use a chunk up to 1KB without having to do the kind= of=0A= >pipelining that leads to security bugs and messy code.=0A= =0A= And where does the PGP code and data memory itself fit in all this?=0A= =0A= Peter.=0A= From nobody Thu Mar 28 21:40:09 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C59C61201C3 for ; Thu, 28 Mar 2019 21:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 qzG4wy9NE5lY for ; Thu, 28 Mar 2019 21:40:05 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 508F71201A6 for ; Thu, 28 Mar 2019 21:40:04 -0700 (PDT) Received: from [47.143.125.151] (helo=Williams-MacBook-Pro.local) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1h9jJ5-0001FI-BQ; Fri, 29 Mar 2019 00:39:55 -0400 Date: Thu, 28 Mar 2019 21:39:54 -0700 From: Bill Frantz To: Peter Gutmann , Bart Butler cc: openpgp@ietf.org, Justus Winter , "Neal H. Walfield" , Jon Callas , Jon Callas X-Priority: 3 In-Reply-To: <1553830376146.79046@cs.auckland.ac.nz> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4.3 (480) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79a456044a3aadf2163d0b7f915088aa7a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 47.143.125.151 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 04:40:08 -0000 On 3/29/19 at 8:33 PM, pgut001@cs.auckland.ac.nz (Peter Gutmann) wrote: >Bill Frantz writes: > >>The Arduino Uno, which the web site says is the most popular Arduino in t= he >>line >>, has: >> >>Flash Memory 32 KB (ATmega328P) of which 0.5 KB used by bootloader >>SRAM 2 KB (ATmega328P) >>EEPROM 1 KB (ATmega328P) >> >>So it might be able to use a chunk up to 1KB without having to do the kin= d of >>pipelining that leads to security bugs and messy code. > >And where does the PGP code and data memory itself fit in all this? > >Peter. Well, we had a version of PGP running on an original IBM PC.=20 With careful implementation, you might get the code into 32K=20 program memory using the 2K R/W memory for buffers and working=20 memory. You also might slip implementing all of the SHOULDs and=20 perhaps some of the inappropriate MUSTs. You would probably have=20 to also always make the tradeoff for space and not performance. Remember, the original question was asked by an enbedded system=20 developer. How small do they go? If they're looking at Raspberry=20 Pi size machines, then they really have it comparatively easy. Cheers - Bill ------------------------------------------------------------------------ Bill Frantz |"Insofar as the propositions of mathematics=20 refer to 408-356-8506 | reality, they are not certain; and insofar=20 they are www.pwpconsult.com | certain, they do not refer to reality.=E2=80=9D=20 -- Einstein From nobody Fri Mar 29 02:08:06 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E279C120261 for ; Fri, 29 Mar 2019 02:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=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 9D0KdLXS6tLT for ; Fri, 29 Mar 2019 02:07:58 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 BCB35120257 for ; Fri, 29 Mar 2019 02:07:58 -0700 (PDT) Received: from p57b22663.dip0.t-ipconnect.de ([87.178.38.99] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1h9nUR-0003fo-I0; Fri, 29 Mar 2019 09:07:55 +0000 Date: Fri, 29 Mar 2019 10:07:54 +0100 Message-ID: <87ftr6giad.wl-neal@walfield.org> From: "Neal H. Walfield" To: Jon Callas Cc: openpgp@ietf.org, Justus Winter , Jon Callas In-Reply-To: References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <8736n63bav.wl-neal@walfield.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-2022-JP Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 09:08:03 -0000 On Fri, 29 Mar 2019 03:19:39 +0100, Jon Callas wrote: > Like some interim replies, particularly Bart Butler, I thought we had a rough consensus and that it was approximately: > > * MUST support 16KB chunks. > * SHOULD support 256K chunks, as these are common (Protonmail). > * MAY support larger up to the present very large size. > * MAY reject or error out on chunks larger than 16KB, but repeating ourselves, SHOULD support 256K. I still think this is a bad idea. And my discussions offline with Justus and Marcus suggest that they also don't agree with this. As I understand Sebastian's position, he also doesn't agree: https://mailarchive.ietf.org/arch/msg/openpgp/SfVIqqwtYnBSOyhmdh8DnoFtlEw Bart and Sunny are also for reducing the range of allowable chunk sizes: https://mailarchive.ietf.org/arch/msg/openpgp/VN-lWmTK6JXxPKnluO7IbQJT52Y The proposal that I put forward removed the chunk size byte and standardized a single, fixed chunk size. I suggested 16kb, but given Bart's arguments, I was willing to compromise on 256kb: https://mailarchive.ietf.org/arch/msg/openpgp/JukTMAMY-RUoHsHxVxyZNht96R4 I also suggested using a different packet tag, and marking 20 as reserved to avoid breaking users of the current AEAD packet: https://mailarchive.ietf.org/arch/msg/openpgp/2SitJh7vA4cHvWGkbAMSzf1Zkio https://mailarchive.ietf.org/arch/msg/openpgp/WvaisWDd9WzoKXL1FyHDeZNtZ2U > I could also get behind a hard limit of 2^30 on the grounds that that$B!G(Bs what we had for partial body lengths, but I understand the comment that there are things like multi-terabyte S3 buckets and out and out forbidding those to be single-chunk is a bit churlish, but only a bit. This is the bit that I don't understand. Clearly you see some advantage to having large chunk sizes. I've asked several times on this list, but no one can tell me what concrete advantages large chunk sizes have. (Tobias has suggested completely removing chunking, which does protect against truncation attacks, but it sacrifices the ability to work with O(1)-sized buffers, i.e., streaming.) Can you please tell me why large chunk sizes are helpful? > If we really want to tie a bow around everything, then define some notation or other marker so that an implementation can mark in a key what the max chunk size is. > > How$B!G(Bs that? Please don't add even more complexity! Again, what are the advantages of choosing one chunk size over another? Ferguson, Schneier and Kohno write in "Cryptography Engineering": "There are already enough insecure fast systems; we don't need another one" (2.9) and "The more complex a system, the more likely it has security problems... complexity is the worst enemy of security" (2.10) I feel like making the chunk size configurable adds complexity whose only justification is some hand wavy "well, in the future it might help...". Please help me understand why large/variable chunk sizes are useful. > Now with some other points, I found myself going especially Socratic > because the missives that you and Justus wrote weren$B!G(Bt > *actionable*. When I was editor, a thing I would say from time to > time is at about 90% of the time someone would say, $B!H(BPlease change X > to Y for reason Z$B!I(B it would be a no-brainer to do so. Most of the > remaining 10% would end up with some reasonable debate than then an > answer. But if someone said, $B!H(BI think X is wrong$B!I(B then 90% of the > time nothing would happen because there$B!G(Bs nothing actionable there, > meaning that there$B!G(Bs no clear point for the editor to be doing. All > of these standards are at some level compromises and there$B!G(Bs an old > aphorism that the best compromise is one where everyone is equally > unhappy. I don't understand why you think I haven't been concrete :/. In my original email, I provided a concrete patch to 4880bis: https://mailarchive.ietf.org/arch/msg/openpgp/XH098WlJe8lkOypIaB1IXTde2sY But, let me try to use your framing: I propose that we remove the chunk size parameter from the AEAD header and fix it to a small value (e.g., 64 KB or 256 KB), because 1.) no one has shown that a large chunk size is useful, 2.) large chunk sizes encourage implementations to release unauthenticated plaintext, which is a serious security concern [1], 3.) if an implementation releases unauthenticated plaintext for large chunks, then an attacker can always convince it to release unauthenticated plaintext for the first chunk in a message [2], 4.) making the chunk size variable increases complexity, which is a security concern. [1] https://mailarchive.ietf.org/arch/msg/openpgp/fmQgRm94jhvPLEOi0J-o7A8LpkY but RNP appears to do the same. [2] https://mailarchive.ietf.org/arch/msg/openpgp/WvaisWDd9WzoKXL1FyHDeZNtZ2U, starting at "Let's assume..." > In my particular case, I thought I mostly agreed with where you wanted to go, but I completely disagreed with some of your premises, and disagreed with some of the reasoning that got us to the conclusion I agreed with. That$B!G(Bs why I was being so Socratic. I thought before the missives today that we had a rough consensus and that I agreed with y$B!G(Ball at some basic level. Then I thought we really disagreed, and I gradually realized that we agree on the destination, but not on the path of how to get there. As I understand your position, you want to allow implementations a broad degree of flexibility in choosing the chunk size. Can you please explain why this is useful? I've reread your messages, but beyond what appears to me to be some hand wavy performance argument, and an apparent misunderstand (chunk size != message size) [3], neither of which are convincing, I can't find any other arguments. I'm sorry if you did and I didn't understand. [3] I believe that if we limit it to 16K, we *will* regret that, for performance or other reasons. And while some of the upper sizes are presently absurdly large, one never knows what happens a couple decades from now. Moreover, forbidding it says that we state now that no one could ever have a reasonable use; my experience is that categorical statements like that are just asking the fates to bite us in an uncomfortable place. Amazon S3 increased their max object size to 5TB a few years ago. I$B!G(Bm not saying it should be that large, but I think this is a pretty convincing argument that 16K is too small. https://mailarchive.ietf.org/arch/msg/openpgp/PLbg_sFze2H1INrwz_l1Uz1tPGE > If I may give some advice, it is better to make sure that your requests are actionable. If they$B!G(Bre not, then you$B!G(Bre less likely to get what you want, if for no other reason than the rest of us don$B!G(Bt know what you want, we$B!G(Bre having to guess. The basic argument that you were making $B!=(B that implementations such as yours need tight constraints $B!=(B is one we all can get behind. The other side here $B!=(B they want to do something kinda wacky (like terabyte chunks) $B!=(B can be pushed off into the land of MAYs. I'm a bit confused. In my original mail, I included a PR: https://mailarchive.ietf.org/arch/msg/openpgp/XH098WlJe8lkOypIaB1IXTde2sY Was that not actionable enough? Should I link to the PR more often? I feel that I need answers to two questions regarding the "allow large chunk size" position. I recently asked them, but I have gotten a response. Here they are again: I've spent some time thinking about use cases for different chunk sizes, and I can't come up with any modulo some, IMHO, insignificant performance tweaks. Can you please give some examples of use cases that would profit from different chunk sizes? What should / would you recommend an implementation do if it encounters a chunk that it can't buffer? I see two choices: report an error, or release unauthenticated plaintext. https://mailarchive.ietf.org/arch/msg/openpgp/m9hd4FwdvIUWKt1MWQfzBq3JahY Regarding our implementation: it doesn't actually have tight resource constraints. Our primary goal is to write a secure implementation. (BFrom that goal, we derived the constraint that we must always work in a bounded amount of space. The current version of AEAD doesn't allow this without potentially rejecting messages that other implementations can process by being insecure (releasing unauthenticated plaintext), which we don't want to do. But, my concerns are not only about my implementation. I'm concerned about the ecosystem. And, the current proposal encourages insecure implementations as demonstrated by GnuPG and RNP processing unauthenticated plaintext. I think the standard should not proactively make it harder to write a secure implementation. And that is what I see the AEAD chunk size doing. Thanks, Neal P.S. I hope it is clear that I'm trying to engage in a constructive manner. I sincerely haven't understand your position, and I really want to. From nobody Fri Mar 29 02:23:47 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADE5512047A for ; Fri, 29 Mar 2019 02:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=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 4NTTRgoQZTmX for ; Fri, 29 Mar 2019 02:23:37 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 A66D81203CE for ; Fri, 29 Mar 2019 02:23:37 -0700 (PDT) Received: from p57b22663.dip0.t-ipconnect.de ([87.178.38.99] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1h9njT-0003ro-TW; Fri, 29 Mar 2019 09:23:27 +0000 Date: Fri, 29 Mar 2019 10:23:27 +0100 Message-ID: <87ef6qghkg.wl-neal@walfield.org> From: "Neal H. Walfield" To: Peter Gutmann Cc: Jon Callas , "openpgp@ietf.org" , Justus Winter , Jon Callas In-Reply-To: <1553829416285.5270@cs.auckland.ac.nz> References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 09:23:47 -0000 On Fri, 29 Mar 2019 04:17:03 +0100, Peter Gutmann wrote: > Neal H. Walfield writes: > >Until now, OpenPGP didn't require buffering data. A decrypted AEAD chunk > >MUST only be released when it has been authenticated. In the current > >proposal, AEAD chunks are potentially unbounded (well, up to 4 exabytes...) > >in size. No one can decrypt such chunks without cheating, i.e., releasing > >unauthenticated plaintext. > > This has been considered before, e.g. with S/MIME's authenticated encryption: > > https://tools.ietf.org/html/rfc6476#section-6 > > and so far doesn't seem to have caused any major problems. That is, it's not > that there's a perfect solution, it's that actual problem situations seem to > be pretty rare. The advice seems pretty good: The exact solution to these issues is somewhat implementation- specific, with some suggested mitigations being as follows: implementations should buffer the entire message if possible and verify the MAC before performing any decryption. If this isn't possible due to streaming or message-size constraints, then ** implementations should consider breaking long messages into a ** sequence of smaller ones, each of which can be processed atomically ** as above. If even this isn't possible, then implementations should make obvious to the caller or user that an authentication failure has occurred and that the previously returned or output data shouldn't be used. Finally, any data-formatting problem, such as obviously truncated data or missing trailing data, should be treated as a MAC verification failure even if the rest of the data was processed correctly. It seems to me that we can take this advice at the protocol layer and largely avoid the security concerns. We just always use small chunks. > If you want to do it right, you'd really want some formal academic treatment > rather than guessing at chunk sizes and what may or may not be needed, i.e. > typical message size X, typical chunk size Y gives these security bounds. PGP > is typically used to encrypt data at rest (make the chunk size the file size) > or short email messages (chunk size doesn't matter, it's short). That leaves > a remainder of large emails, which we know exist but don't know how frequent > they are or how often they're sent or from what sorts of systems. I'm having trouble imagining why a larger chunk size would ever be better in either of these cases. - File encryption: smaller chunk size means finding errors faster - Large emails: smaller chunk size means that it is possible to preview the email, which is helpful on mobile connections. Please help me understand when a large chunk size could be better. Thanks, :) Neal From nobody Fri Mar 29 02:52:56 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B624A1200FB for ; Fri, 29 Mar 2019 02:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ruhr-uni-bochum.de 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 Bpi87SVh59FI for ; Fri, 29 Mar 2019 02:52:52 -0700 (PDT) Received: from out3.mail.ruhr-uni-bochum.de (out3.mail.ruhr-uni-bochum.de [134.147.53.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FEFD120074 for ; Fri, 29 Mar 2019 02:52:52 -0700 (PDT) Received: from mx3.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by out3.mail.ruhr-uni-bochum.de (Postfix mo-ext) with ESMTP id 44Vxqh0JRFz8SXX for ; Fri, 29 Mar 2019 10:52:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ruhr-uni-bochum.de; s=mail-2017; t=1553853168; bh=zkClrZF4xYhzotee4PHrEBU8mYwtu97p8n52UjOxC6Y=; h=Subject:To:References:From:Date:In-Reply-To:From; b=SxwHHYB4xnmrYBjeHm9PzGw1p4Rvh7LcCNTdqGh4PLarNMG7nhLJXgPjs5Fe6u3rO R/QVD+pIlE7Onm4jAfWEn2Yep4iFOtJUYXk9tFoLo7x9yfoWb1zwQ80w/mUwelZ2BA UxibW1QcBLsxFBlMOi9iHW+QRxH5H5pxG+h0AILY= Received: from out3.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by mx3.mail.ruhr-uni-bochum.de (Postfix idis) with ESMTP id 44Vxqg57Lrz8SRP for ; Fri, 29 Mar 2019 10:52:47 +0100 (CET) X-Envelope-Sender: X-RUB-Notes: Internal origin=134.147.42.227 Received: from mail1.mail.ruhr-uni-bochum.de (mail1.mail.ruhr-uni-bochum.de [134.147.42.227]) by out3.mail.ruhr-uni-bochum.de (Postfix mi-int) with ESMTP id 44Vxqg3Ndpz8Scq for ; Fri, 29 Mar 2019 10:52:47 +0100 (CET) Received: from [192.168.142.139] (p5B0498DC.dip0.t-ipconnect.de [91.4.152.220]) by mail1.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 44Vxqg0g8Zzyty for ; Fri, 29 Mar 2019 10:52:47 +0100 (CET) To: openpgp@ietf.org References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <8736n63bav.wl-neal@walfield.org> From: Marcus Brinkmann Openpgp: preference=signencrypt Message-ID: Date: Fri, 29 Mar 2019 10:52:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.4 at mail1.mail.ruhr-uni-bochum.de X-Virus-Status: Clean Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 09:52:56 -0000 Hi, Just to set the record straight: I made two very specific actionable proposal on this very list 9 months ago. * Limit the maximum chunk size to a small value: https://mhonarc.domainunion.de/archive/html/ietf-openpgp/2018-06/msg00029.html * Forbid outputting unauthenticated plaintext: https://mhonarc.domainunion.de/archive/html/ietf-openpgp/2018-06/msg00030.html Also, I think it is instructive to look at the history of the chunk size and how we got here in the first place. This is the original proposed text by Brian M. Carlson: > An implementation MUST support chunk size octets with values from 0 to 10. An implementation MAY support other chunk sizes. Chunk size octets with values larger than 127 are reserved for future extensions. https://gitlab.com/bk2204/rfc4880bis/commit/353520abd5be34d9980a0f1ea77a07ba1837d03a This is what the editor put into the draft standard without discussion: > An implementation MUST support chunk size octets with values from 0 to 56. Chunk size octets with other values are reserved for future extensions. https://mhonarc.domainunion.de/archive/html/ietf-openpgp/2017-07/msg00010.html His reasoning was this: "Given that larger values are optional, implementations will need limit C to 10. I consider this too low for practical purposes. We should require all implementations to support the same range. Given that we have a 64 bit counter the maximum value for C should be 57 - I would even say 56 so that we avoid signed and signed problems in the number of octets." So, here is an actionable item: Go back to the original proposal by Brian M. Carlson. It gives implementations a reasonable limit to stick to, while it allows for larger chunks for special use cases. Thanks, Marcus From nobody Fri Mar 29 04:48:21 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DB11202ED for ; Fri, 29 Mar 2019 04:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ruhr-uni-bochum.de 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 yk641AovqVoj for ; Fri, 29 Mar 2019 04:48:09 -0700 (PDT) Received: from out3.mail.ruhr-uni-bochum.de (out3.mail.ruhr-uni-bochum.de [IPv6:2a05:3e00:8:1001::8693:359b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 505EC120456 for ; Fri, 29 Mar 2019 04:48:07 -0700 (PDT) Received: from mx3.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by out3.mail.ruhr-uni-bochum.de (Postfix mo-ext) with ESMTP id 44W0Ng1f3vz8SqZ for ; Fri, 29 Mar 2019 12:48:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ruhr-uni-bochum.de; s=mail-2017; t=1553860083; bh=8Sat+CnntjQX+qcyDZz+o63V5g3fTzf+vA8kyYaq6vY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=PBx+hs/INc2Zg2IsjXM4vkx/nMb2sAkbzYsw3NWDKhfQcLEKfYhfNFG13msfatXVa Blwq8p0UbcLdSykL5bWx7s6r59yDd8izZvteTrdJDQ+lYxuuyX5L0lGTWH43IpSbq1 elJrUS/eHWlyq7FvBpN2cENyVlaLrxf6LxL5CUJo= Received: from out3.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by mx3.mail.ruhr-uni-bochum.de (Postfix idis) with ESMTP id 44W0NX1nLTz8SdG for ; Fri, 29 Mar 2019 12:47:56 +0100 (CET) X-Envelope-Sender: X-RUB-Notes: Internal origin=134.147.42.227 Received: from mail1.mail.ruhr-uni-bochum.de (mail1.mail.ruhr-uni-bochum.de [134.147.42.227]) by out3.mail.ruhr-uni-bochum.de (Postfix mi-int) with ESMTP id 44W0NV2fZ1z8Snx for ; Fri, 29 Mar 2019 12:47:53 +0100 (CET) Received: from [IPv6:2a05:3e00:1:59:d34a:df34:3a81:7663] (dyn-366718a343fda43d95001000.eduroam.ipv6.ruhr-uni-bochum.de [IPv6:2a05:3e00:1:59:d34a:df34:3a81:7663]) by mail1.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 44W0NT6QKjzytX for ; Fri, 29 Mar 2019 12:47:53 +0100 (CET) To: openpgp@ietf.org References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <8736n63bav.wl-neal@walfield.org> From: Marcus Brinkmann Openpgp: preference=signencrypt Message-ID: <3d86539c-c9de-2194-bbfb-1442bdc8c327@ruhr-uni-bochum.de> Date: Fri, 29 Mar 2019 12:47:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.4 at mail1.mail.ruhr-uni-bochum.de X-Virus-Status: Clean Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 11:48:19 -0000 On 3/29/19 3:19 AM, Jon Callas wrote: > I wrote a point-by-point reply and decided that that’s not productive. I’m going to try to cut to the chase on this, so forgive me if I have dodged an important point. I’m happy to come back to it later. > > Like some interim replies, particularly Bart Butler, I thought we had a rough consensus and that it was approximately: > > * MUST support 16KB chunks. > * SHOULD support 256K chunks, as these are common (Protonmail). > * MAY support larger up to the present very large size. > * MAY reject or error out on chunks larger than 16KB, but repeating ourselves, SHOULD support 256K. > > I think it’s also reasonable to just simplify it by making be MUST support up to 256K. I don’t like getting rid of the SHOULD clause, thus making it be either 16K or off in squishy land, but I wouldn’t wring my wrists, I’d merely be a bit unhappy. > > I could also get behind a hard limit of 2^30 on the grounds that that’s what we had for partial body lengths, but I understand the comment that there are things like multi-terabyte S3 buckets and out and out forbidding those to be single-chunk is a bit churlish, but only a bit. > > If we really want to tie a bow around everything, then define some notation or other marker so that an implementation can mark in a key what the max chunk size is. > > How’s that? FWIW, I think that's reasonable. It is very similar to the original OpenPGP AEAD proposal by Brian M. Carlson, which just had "MUST support up to 64KB chunks" and "MAY support larger chunks". That original proposal is simpler than yours, but given that Protonmail already uses larger chunk sizes, that's ok. From the perspective of mobile and desktop devices, 64KB and 256KB are similarly reasonable. There is a little bit of tension here, because any increase in the MUST area may give trouble to constraint devices, who should be able to hold a single chunk in memory if they are interested in non-malleability. The difference between 16KB and 256KB can matter here. So, I guess I understand why you introduced the SHOULD requirement, although it makes things more complicated. Thanks, Marcus From nobody Fri Mar 29 05:53:54 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D216F1202B1 for ; Fri, 29 Mar 2019 05:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 Hrp8WD3hH7Xf for ; Fri, 29 Mar 2019 05:53:50 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D68A51202A1 for ; Fri, 29 Mar 2019 05:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1553864030; x=1585400030; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TGOrZjhKFuDxwSIRv2GRWR6XaJi4I3dDrqMl193Vw1g=; b=BvjjxtFaptn1Xs2oSTUgzBFS2Ui8bfaUcK17K/zKJoA8KAc3Wi42lgdg xLDQj+O7HhN1AFxnHIEPy6l5UzU9RhMWBUdbTQLk54lrgJ/HSaEyg5Drj 5N6Kg9TxNcQ/OhFgrJm2b3u9izdqRq1DOJkPPBJywrijnRyxw5815LBu/ o45nyNra4p2EBNPKEEVzALqvoS5b86oFW4mfiKYpHAoK56uldqRH0f4dK OS/wNnTlgTcE06qBfwxwWNh+GIyzXLq/u+7HP83O70qNngg7+nTjwdVoQ QU30FzznEwMWl8sO1gccjLZ2nE6o3qvmk08dni6MnUZaitVe4Y2veXmB3 w==; X-IronPort-AV: E=Sophos;i="5.60,284,1549882800"; d="scan'208";a="53654432" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.9 - Outgoing - Outgoing Received: from uxcn13-tdc-e.uoa.auckland.ac.nz ([10.6.3.9]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 30 Mar 2019 01:53:43 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-e.UoA.auckland.ac.nz (10.6.3.9) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 30 Mar 2019 01:53:43 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Sat, 30 Mar 2019 01:53:43 +1300 From: Peter Gutmann To: "Neal H. Walfield" CC: Jon Callas , "openpgp@ietf.org" , Justus Winter , Jon Callas Thread-Topic: [openpgp] AEAD Chunk Size Thread-Index: AQHU5WH/TXThz2b5WUWEfgPFCGcCuqYgtWOAgAAKeQCAATDsKP//jKeAgAEUouc= Date: Fri, 29 Mar 2019 12:53:42 +0000 Message-ID: <1553864014737.31739@cs.auckland.ac.nz> References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> , <87ef6qghkg.wl-neal@walfield.org> In-Reply-To: <87ef6qghkg.wl-neal@walfield.org> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 12:53:53 -0000 Neal H. Walfield writes:=0A= =0A= >I'm having trouble imagining why a larger chunk size would ever be better = in=0A= >either of these cases.=0A= >=0A= > - File encryption: smaller chunk size means finding errors faster=0A= =0A= See my followup messages, for data at rest you probably don't care about=0A= errors at all, and if you really do then having the report at the whole-fil= e=0A= level is fine. What's the benefit gained from knowing that the 64kB block = at=0A= offset xyz is corrupt?=0A= =0A= As I mentioned earlier, we really need some data on real-world use cases=0A= rather than hypothesising problematic corner cases that will rarely, if eve= r,=0A= occur.=0A= =0A= Peter.=0A= From nobody Fri Mar 29 06:20:29 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF79120279 for ; Fri, 29 Mar 2019 06:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 0LLitqt_NByq for ; Fri, 29 Mar 2019 06:20:24 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 70EB4120252 for ; Fri, 29 Mar 2019 06:20:24 -0700 (PDT) Received: from p57b22663.dip0.t-ipconnect.de ([87.178.38.99] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1h9rQj-0006gl-Kx; Fri, 29 Mar 2019 13:20:21 +0000 Date: Fri, 29 Mar 2019 14:20:21 +0100 Message-ID: <87d0m9hl62.wl-neal@walfield.org> From: "Neal H. Walfield" To: Peter Gutmann Cc: "openpgp@ietf.org" , Justus Winter , Jon Callas , Jon Callas In-Reply-To: <1553864014737.31739@cs.auckland.ac.nz> References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 13:20:27 -0000 On Fri, 29 Mar 2019 13:53:42 +0100, Peter Gutmann wrote: > > Neal H. Walfield writes: > > >I'm having trouble imagining why a larger chunk size would ever be better in > >either of these cases. > > > > - File encryption: smaller chunk size means finding errors faster > > See my followup messages, for data at rest you probably don't care about > errors at all, and if you really do then having the report at the whole-file > level is fine. What's the benefit gained from knowing that the 64kB block at > offset xyz is corrupt? But what is the cost? I would say there is basically none. So it makes no sense to me to optimize for this case. It's irrelevant. So, why make the important case (when you actually do want to stream) more complicated? > As I mentioned earlier, we really need some data on real-world use cases > rather than hypothesising problematic corner cases that will rarely, if ever, > occur. Efail occured. Why is that not enough? From nobody Fri Mar 29 06:43:50 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08AEA12036B for ; Fri, 29 Mar 2019 06:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 RAZXLP112a-D for ; Fri, 29 Mar 2019 06:43:40 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 744C1120254 for ; Fri, 29 Mar 2019 06:43:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1553867019; x=1585403019; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TU78U/Fchkjnddw4xuxdSe0aXkjkLrDlxXH9daOZAPc=; b=hYuXIpcA41EqNfVdAlYCyS/QJv2QgZWlGkb3wZQb2Fteva8ZrnQwSWm8 RaEKES60yKTLfj5h/8yRPd6sWyVJVEq2GXdcHJUM6leTRXWZs8jCHpna9 ADQfena+q4HlajyapNOHvWBUK0uu1r4gmcLFGlmzO21yl9zei2D22o9/L YgvA5gqZCw96uT0EjxmwKnFqBGR9kuJOnUfMVB9TWC11OZPgGSTzL5KY0 1ra4gtbJR38U4W1u15ucIDZMxRRcaAJkGX0FP8g5ZLyQs5Jjoywd8f3GM wkNGnb3sA1IJsHLEF0cPGJhDDIViMTzNAIP0UI0bBZu9eNcHJ2N1xYaX2 Q==; X-IronPort-AV: E=Sophos;i="5.60,284,1549882800"; d="scan'208";a="53656676" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.5 - Outgoing - Outgoing Received: from uxcn13-ogg-d.uoa.auckland.ac.nz ([10.6.2.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 30 Mar 2019 02:43:36 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 30 Mar 2019 02:43:36 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Sat, 30 Mar 2019 02:43:36 +1300 From: Peter Gutmann To: "Neal H. Walfield" CC: "openpgp@ietf.org" , Justus Winter , Jon Callas , Jon Callas Thread-Topic: [openpgp] AEAD Chunk Size Thread-Index: AQHU5WH/TXThz2b5WUWEfgPFCGcCuqYgtWOAgAAKeQCAATDsKP//jKeAgAEUouf//y2OgIAA4CBQ Date: Fri, 29 Mar 2019 13:43:35 +0000 Message-ID: <1553867007783.37940@cs.auckland.ac.nz> References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> , <87d0m9hl62.wl-neal@walfield.org> In-Reply-To: <87d0m9hl62.wl-neal@walfield.org> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 13:43:49 -0000 Neal H. Walfield writes:=0A= =0A= >But what is the cost? I would say there is basically none. So it makes n= o=0A= >sense to me to optimize for this case. It's irrelevant.=0A= =0A= There is a significant cost in terms of implementing, debugging, and intero= p-=0A= testing every implementation that wants to do this. If no-one cares about= =0A= auth protection of data at rest, and in the complete absence of real-world= =0A= data I'm going to claim no-one does because you can't prove otherwise, usin= g=0A= what we currently have has zero cost because it's already implemented. Add= ing=0A= blocked auth protection has a distinctly nonzero cost.=0A= =0A= >Efail occured. Why is that not enough?=0A= =0A= That was due to broken email apps. If I can convince your email app to=0A= forward the plaintext of a decrypted message to me, you lose no matter what= =0A= encryption mechanism you use.=0A= =0A= Admittedly CBC/CFB made this easier, but it was the email apps that needed= =0A= fixing, not PGP.=0A= =0A= I'm not saying it's not worth addressing, but before endlessly debating=0A= solutions we need to figure out what problem we're solving. "We have this= =0A= cool AEAD mode lying around and want to apply it to something" isn't a=0A= problem, or at least not a problem that a PGP user cares about solving, it'= s=0A= something interesting for geeks to play with.=0A= =0A= In the last five years or so I've received approximately zero PGP-encrypted= =0A= emails, and I'm one of the people who helped write the thing. OTOH I've=0A= probably encrypted gigabytes of data with it, almost always symmetric-key w= ith=0A= the key communicated out of band. In none of those cases would blocked aut= h=0A= protection have been useful.=0A= =0A= Peter.=0A= From nobody Fri Mar 29 07:37:26 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A671202AE for ; Fri, 29 Mar 2019 07:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 qS5M1lK0UTJ7 for ; Fri, 29 Mar 2019 07:37:17 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 EBE2E120249 for ; Fri, 29 Mar 2019 07:37:16 -0700 (PDT) Received: from p57b22663.dip0.t-ipconnect.de ([87.178.38.99] helo=chu.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1h9sd7-0007bi-A2; Fri, 29 Mar 2019 14:37:13 +0000 Date: Fri, 29 Mar 2019 15:37:12 +0100 Message-ID: <87zhpd21d3.wl-neal@walfield.org> From: "Neal H. Walfield" To: Peter Gutmann Cc: "openpgp@ietf.org" , Justus Winter , Jon Callas , Jon Callas In-Reply-To: <1553867007783.37940@cs.auckland.ac.nz> References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 14:37:20 -0000 At Fri, 29 Mar 2019 13:43:35 +0000, Peter Gutmann wrote: > Neal H. Walfield writes: > >But what is the cost? I would say there is basically none. So it makes no > >sense to me to optimize for this case. It's irrelevant. > > There is a significant cost in terms of implementing, debugging, and interop- > testing every implementation that wants to do this. If no-one cares about > auth protection of data at rest, and in the complete absence of real-world > data I'm going to claim no-one does because you can't prove otherwise, using > what we currently have has zero cost because it's already implemented. Adding > blocked auth protection has a distinctly nonzero cost. Ok. Is your position that the working group should remove AEAD from 4880bis until there is an academic study proving people need it? > >Efail occured. Why is that not enough? > > That was due to broken email apps. If I can convince your email app to > forward the plaintext of a decrypted message to me, you lose no matter what > encryption mechanism you use. > > Admittedly CBC/CFB made this easier, but it was the email apps that needed > fixing, not PGP. I see it differently. I would say it was a combination of the email applications needing fixing and PGP needing fixing. PGP encourages implementations to support streaming, and most do. But, using 4880, this means that an application may see plaintext from unauthenticated ciphertext. Efail shows how that can be exploited by ***modifying the ciphertext*** (a PGP problem) to create a potential exfiltration channel. Using chunked AEAD correctly, this type of attack is not possible: it is possible to stream, and only release plaintext from authenticated ciphertext. Now, applications could have protected themselves from this attack if they had backed out the message on MDC failure. But, they didn't. And, I'd argue that a major reason that they didn't was because this type of attack is not well understood by application developers. Application developers understand truncation. But, ciphertext modification is something that most have probably never heard of. Since we can protect application developers from ciphertext modification, I would argue that not doing so is negligent. So, if we are distributing blame, and I'd rather not play that game, then I'd place 90% of the blame on the WG and the PGP implementations, and only 10% on the mail application developers. From nobody Fri Mar 29 12:59:29 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0229120327 for ; Fri, 29 Mar 2019 12:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com 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 hkCSDT0dvE6b for ; Fri, 29 Mar 2019 12:59:24 -0700 (PDT) Received: from mr85p00im-hyfv06011301.me.com (mr85p00im-hyfv06011301.me.com [17.58.23.184]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8731F12031B for ; Fri, 29 Mar 2019 12:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1553889562; bh=KsHG4YfkRhwmK3811A5D+IGdknmLGkPXk2sD4qLR0Lg=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=iKzUbW9uRKfdLK6IZ4S5Y5pKV9JCOLj94v6jsQhNSkWpP1IMr283IHP6WCJR04y/E kVIJvk2/u8/vXoflN4hZYF5ZYuHRgKWLTORJEkwsbpBfgyFq2x/77bW6Kfr5CE8Gwc h7FL+nYhSnaz/eTVO+Ds5h2tF0gADGJuh9vmxNxOdxNx/YURaZs0FcfnLpcu+UJy8O PhZD6GXT8RBG+dNFA9qro5gFkqWGF6cgiTZilWeklm3CEKUAW1d2fZ5O/WneoC/EeW jtj/rZyY73ACscqGp0SFmJizerDjYdRmzATaJMTjerzd0Jmcp63LmlPXrLvUWDlQYG XzCsvMc904NRw== Received: from [192.168.7.69] (thing1.merrymeet.com [173.164.244.99]) by mr85p00im-hyfv06011301.me.com (Postfix) with ESMTPSA id 5FB0E580215; Fri, 29 Mar 2019 19:59:22 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Jon Callas In-Reply-To: <87ftr6giad.wl-neal@walfield.org> Date: Fri, 29 Mar 2019 12:59:21 -0700 Cc: Jon Callas , Jon Callas , "openpgp@ietf.org OpenPGP" , Justus Winter Content-Transfer-Encoding: quoted-printable Message-Id: References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <8736n63bav.wl-neal@walfield.org> <87ftr6giad.wl-neal@walfield.org> To: "Neal H. Walfield" X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-29_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1903290137 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 19:59:28 -0000 > On Mar 29, 2019, at 2:07 AM, Neal H. Walfield = wrote: >=20 > On Fri, 29 Mar 2019 03:19:39 +0100, > Jon Callas wrote: >> Like some interim replies, particularly Bart Butler, I thought we had = a rough consensus and that it was approximately: >>=20 >> * MUST support 16KB chunks. >> * SHOULD support 256K chunks, as these are common (Protonmail). >> * MAY support larger up to the present very large size. >> * MAY reject or error out on chunks larger than 16KB, but repeating = ourselves, SHOULD support 256K. >=20 > I still think this is a bad idea. =20 Noted. It was a position that I threw out because I thought it = encompassed a lot of things that people said and also allows you, the = implementer to say, =E2=80=9Cscrew it, we=E2=80=99re doing 256K only and = to heck with all of you=E2=80=9D and it would meet the standard. You = could even implement 64K, thus generating a brinksmanship debate with = you and Protonmail and I don=E2=80=99t have to listen to it. I think that my proposal above is flawed because there=E2=80=99s this = squishy space between 64K and 256K, and really hoped someone would = either say, =E2=80=9CFine. I=E2=80=99ll give up on 256K=E2=80=9D or = =E2=80=9CFine. 256K is fine.=E2=80=9D And then we=E2=80=99d modify the = proposal and probably be done. It was, however a position I thought we = might reason from. >> I could also get behind a hard limit of 2^30 on the grounds that = that=E2=80=99s what we had for partial body lengths, but I understand = the comment that there are things like multi-terabyte S3 buckets and out = and out forbidding those to be single-chunk is a bit churlish, but only = a bit. >=20 > This is the bit that I don't understand. Clearly you see some > advantage to having large chunk sizes. Well, actually what I was doing there was offering a number lower than = 2^whatever for the max max max oh-dear-god-why-do-you-want-to-do-this = size at a (to me) very, very generous gigabyte to the other side on the = max size that you can then safely ignore. >=20 > But, let me try to use your framing: >=20 > I propose that we remove the chunk size parameter from the AEAD header > and fix it to a small value (e.g., 64 KB or 256 KB), because 1.) no > one has shown that a large chunk size is useful, 2.) large chunk sizes > encourage implementations to release unauthenticated plaintext, which > is a serious security concern [1], 3.) if an implementation releases > unauthenticated plaintext for large chunks, then an attacker can > always convince it to release unauthenticated plaintext for the first > chunk in a message [2], 4.) making the chunk size variable increases > complexity, which is a security concern. This isn=E2=80=99t actionable. There=E2=80=99s a lot of rationale here, but not an actual proposal. My proposal (left at the top of this missive for easy referral) was a = concrete proposal. The above paragraph has a lot of justification in it = and is interesting polemic but it is not an actual proposal. If you had said: * Chunk size is 256K. Always. If you have less than 256K, pad it with = zeroes. Then that would be a proposal. > As I understand your position, you want to allow implementations a > broad degree of flexibility in choosing the chunk size. Can you > please explain why this is useful? I've reread your messages, but > beyond what appears to me to be some hand wavy performance argument, > and an apparent misunderstand (chunk size !=3D message size) [3], > neither of which are convincing, I can't find any other arguments. > I'm sorry if you did and I didn't understand. You don=E2=80=99t understand my position. My position is that there are a bunch of people (like you, at least I = think you) who want to build a general-purpose implementation that you = hope will be used all over the place. You have a legitimate need for = small chunks. There are other people who observe that there=E2=80=99s also a = legitimate need for huge chunks because they want to do storage = encryption on very large things and =E2=80=94 well, they have = considerations that I=E2=80=99m not paying a lot of attention to. My proposal above lets them do their thing and lets you ignore them. = That=E2=80=99s my position. Making as many people happy as possible. >=20 > I'm a bit confused. In my original mail, I included a PR: >=20 > = https://mailarchive.ietf.org/arch/msg/openpgp/XH098WlJe8lkOypIaB1IXTde2sY >=20 > Was that not actionable enough? Should I link to the PR more often? It would help, but even better would be to send what the proposal is. I = really did read it and it=E2=80=99s a patch file. Patch files are hard = for humans to read. It=E2=80=99s really nice to have a redline, but = it=E2=80=99s also nice to know what the full thing is without having to = mentally emulate git. >=20 > I've spent some time thinking about use cases for different chunk > sizes, and I can't come up with any modulo some, IMHO, insignificant > performance tweaks. Can you please give some examples of use cases > that would profit from different chunk sizes? I=E2=80=99m not the one proposing the large chunk sizes. And as I = understand the people who are doing it, performance isn=E2=80=99t their = issue, data integrity is. There=E2=80=99s a dilemma in here. One is that there=E2=80=99s a belief that=20 >=20 > What should / would you recommend an implementation do if it > encounters a chunk that it can't buffer? I see two choices: report > an error, or release unauthenticated plaintext. Report an error. I=E2=80=99ve said that many times. > Regarding our implementation: it doesn't actually have tight resource > constraints. Our primary goal is to write a secure implementation. Okay, so you=E2=80=99re arguing resources when you don=E2=80=99t really = mean it. Gotcha. I thought that was the case that the things you were = saying didn=E2=80=99t jibe together. > =46rom that goal, we derived the constraint that we must always work = in > a bounded amount of space. The current version of AEAD doesn't allow > this without potentially rejecting messages that other implementations > can process by being insecure (releasing unauthenticated plaintext), > which we don't want to do. That constraint is a long-standing meta-requirement in OpenPGP, so cool. However, I detect that there is an impossible-to-solve problem here, and = I=E2=80=99ll outline it in another note later. >=20 > But, my concerns are not only about my implementation. I'm concerned > about the ecosystem. And, the current proposal encourages insecure > implementations as demonstrated by GnuPG and RNP processing > unauthenticated plaintext. I think the standard should not > proactively make it harder to write a secure implementation. And that > is what I see the AEAD chunk size doing. I think I understand where you=E2=80=99re coming from, but this is a = standards organization. Standards are concerned with interoperability = between implementors. I learned that from Jeff Schiller ages ago. Think = of a standard as being like a dictionary and grammar. When you send me a = message, I use that grammar/dictionary to determine what it means. = Similtharly, if I want to encode a message that I want you to = understand, then I encode it according to that grammar as well. My proposal above says to an encoder that the safest thing to do is to = use a chunk size of 64K. Everyone can decode that, and you=E2=80=99re = fine. Many, many, many of them are going to be okay with 256K, and odds = are that anyone of any import will do fine with it. (That=E2=80=99s what = the SHOULD means). It also says there are people out in Lala-land who = might be playing with chunks that are out to 2^whatever, and that=E2=80=99= s kinda cool, but ignore them.=20 That=E2=80=99s why I made it. It gives a sandbox for people who want to = go out on the edge that the mainstream can ignore. >=20 >=20 > Thanks, >=20 > Neal >=20 > P.S. I hope it is clear that I'm trying to engage in a constructive > manner. I sincerely haven't understand your position, and I really > want to. I think that=E2=80=99s because I=E2=80=99m trying to support a community = of people who have reasonable, differing needs, and you want to mandate = your implementation ideas on the universe. I apologize if that=E2=80=99s = harsh, but it=E2=80=99s what I perceive. If I=E2=80=99m mistaken, let me = know. Jon From nobody Fri Mar 29 13:19:44 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C895512032A for ; Fri, 29 Mar 2019 13:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6VaAfIwv5LKT for ; Fri, 29 Mar 2019 13:19:38 -0700 (PDT) Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 5379812033B for ; Fri, 29 Mar 2019 13:19:19 -0700 (PDT) Received: by mail-it1-x135.google.com with SMTP id f22so5874205ita.3 for ; Fri, 29 Mar 2019 13:19:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sShOZcrAZSzYl8s4fpZuw2R6rttzb2LcpxtdU8tZS7M=; b=ijLqC/hYzkxU65azGNk3qKDamC/Y1DwZHX5wNSXm09SOz9aE7gpdmzEa4eq8NP0Q8g mEhW58lORelwebsbp15plQ5/kEcYDyc8Hq2qk2NRcAyYbwEi7oOZJkC0KEmIVjeduJeD kxvQ4XJLQn9dzSZanjBVeOf1mAaG8LXgQxxRx2wcZbl70KZEMyiXSrwigvpQ2f3hMUnN DEZd6QqH+61x4ePrByrOYb83nWLQj9UlL/tZVicydnPTYabO3FPHIM/c/WfoRfJcBW0T khm5Fo/ueyIHZYi6Vzm/g26gEI7A0QllWcYNUbnVWGP0/ZIm3FCP3IggzEHifI2V8zS3 IFcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sShOZcrAZSzYl8s4fpZuw2R6rttzb2LcpxtdU8tZS7M=; b=fQkVPNB7ZWF67V12bw7M038KggHfHl5AzM/wpaOVS6JFDARv889grpyohyqp/mFB/v rjEbGao1DXGv6QEMvB4zlJ2Nze+5qW9xfo+jKwW6rBDLE1yJadjIyQM2Nt8jdTJ4Kh8z Ykr5JIVtRdEbTp3NyZuRiTP9LjXVwI8PIdOXTR6NynoLhshi2wpissaY5LLSpTeIk5a8 /cf+hYTmVYzxx5NnEm1TfwwZtkN9PwIU4AVvzVjofT7gxIMhUJYCLbeYaCSWj3QvP97W vsA2YMqMtMZW0dw7yoBP/UxTEucuwpFRJW2pIwT12wAb0UIqpVuRGBEHjksEu4XJHbsF wD+w== X-Gm-Message-State: APjAAAUsDb3S8je4NXv/rgP6lN5QUDmSkKXBLQCQr1w6vNVnLAcuOH72 +RKY5+iXkAsze5MpOu0DaxTQQsMZw0WZ5PwvfOg= X-Google-Smtp-Source: APXvYqyvrw5JNLfdkhLosMsJvktKyWHkXk9xKNEMSc0/+KhU5qw252JGCqCxVu1McbHX6zPxrosHVBLWXpLNtgIlRcw= X-Received: by 2002:a24:e346:: with SMTP id d67mr6381778ith.42.1553890758461; Fri, 29 Mar 2019 13:19:18 -0700 (PDT) MIME-Version: 1.0 References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <8736n63bav.wl-neal@walfield.org> <87ftr6giad.wl-neal@walfield.org> In-Reply-To: From: Wyllys Ingersoll Date: Fri, 29 Mar 2019 16:19:07 -0400 Message-ID: To: Jon Callas Cc: "Neal H. Walfield" , "openpgp@ietf.org OpenPGP" , Justus Winter , Jon Callas Content-Type: multipart/alternative; boundary="000000000000ad8e910585416205" Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 20:19:42 -0000 --000000000000ad8e910585416205 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As an implementor (iPGMail on iOS), I strongly support Jon's suggestion (16K "MUST", 256K "SHOULD", everything else "MAY"). I dont want to deal with lots of optional sizes that just introduce complexity with little practical benefit beyond some outliers that want to consume huge files in one big bite. Mobile devices are somewhat memory limited (though that is every growing), but 64K or 256K is certainly not a problem. -Wyllys Ingersoll On Fri, Mar 29, 2019 at 3:59 PM Jon Callas wrote: > > > > On Mar 29, 2019, at 2:07 AM, Neal H. Walfield wrote= : > > > > On Fri, 29 Mar 2019 03:19:39 +0100, > > Jon Callas wrote: > >> Like some interim replies, particularly Bart Butler, I thought we had = a > rough consensus and that it was approximately: > >> > >> * MUST support 16KB chunks. > >> * SHOULD support 256K chunks, as these are common (Protonmail). > >> * MAY support larger up to the present very large size. > >> * MAY reject or error out on chunks larger than 16KB, but repeating > ourselves, SHOULD support 256K. > > > > I still think this is a bad idea. > > Noted. It was a position that I threw out because I thought it encompasse= d > a lot of things that people said and also allows you, the implementer to > say, =E2=80=9Cscrew it, we=E2=80=99re doing 256K only and to heck with al= l of you=E2=80=9D and it > would meet the standard. You could even implement 64K, thus generating a > brinksmanship debate with you and Protonmail and I don=E2=80=99t have to = listen to > it. > > I think that my proposal above is flawed because there=E2=80=99s this squ= ishy > space between 64K and 256K, and really hoped someone would either say, > =E2=80=9CFine. I=E2=80=99ll give up on 256K=E2=80=9D or =E2=80=9CFine. 25= 6K is fine.=E2=80=9D And then we=E2=80=99d modify > the proposal and probably be done. It was, however a position I thought w= e > might reason from. > > >> I could also get behind a hard limit of 2^30 on the grounds that that= =E2=80=99s > what we had for partial body lengths, but I understand the comment that > there are things like multi-terabyte S3 buckets and out and out forbiddin= g > those to be single-chunk is a bit churlish, but only a bit. > > > > This is the bit that I don't understand. Clearly you see some > > advantage to having large chunk sizes. > > Well, actually what I was doing there was offering a number lower than > 2^whatever for the max max max oh-dear-god-why-do-you-want-to-do-this siz= e > at a (to me) very, very generous gigabyte to the other side on the max si= ze > that you can then safely ignore. > > > > > > But, let me try to use your framing: > > > > I propose that we remove the chunk size parameter from the AEAD header > > and fix it to a small value (e.g., 64 KB or 256 KB), because 1.) no > > one has shown that a large chunk size is useful, 2.) large chunk sizes > > encourage implementations to release unauthenticated plaintext, which > > is a serious security concern [1], 3.) if an implementation releases > > unauthenticated plaintext for large chunks, then an attacker can > > always convince it to release unauthenticated plaintext for the first > > chunk in a message [2], 4.) making the chunk size variable increases > > complexity, which is a security concern. > > This isn=E2=80=99t actionable. > > There=E2=80=99s a lot of rationale here, but not an actual proposal. > > My proposal (left at the top of this missive for easy referral) was a > concrete proposal. The above paragraph has a lot of justification in it a= nd > is interesting polemic but it is not an actual proposal. > > If you had said: > > * Chunk size is 256K. Always. If you have less than 256K, pad it with > zeroes. > > Then that would be a proposal. > > > As I understand your position, you want to allow implementations a > > broad degree of flexibility in choosing the chunk size. Can you > > please explain why this is useful? I've reread your messages, but > > beyond what appears to me to be some hand wavy performance argument, > > and an apparent misunderstand (chunk size !=3D message size) [3], > > neither of which are convincing, I can't find any other arguments. > > I'm sorry if you did and I didn't understand. > > You don=E2=80=99t understand my position. > > My position is that there are a bunch of people (like you, at least I > think you) who want to build a general-purpose implementation that you ho= pe > will be used all over the place. You have a legitimate need for small > chunks. > > There are other people who observe that there=E2=80=99s also a legitimate= need for > huge chunks because they want to do storage encryption on very large thin= gs > and =E2=80=94 well, they have considerations that I=E2=80=99m not paying = a lot of attention > to. > > My proposal above lets them do their thing and lets you ignore them. > That=E2=80=99s my position. Making as many people happy as possible. > > > > > I'm a bit confused. In my original mail, I included a PR: > > > > > https://mailarchive.ietf.org/arch/msg/openpgp/XH098WlJe8lkOypIaB1IXTde2sY > > > > Was that not actionable enough? Should I link to the PR more often? > > It would help, but even better would be to send what the proposal is. I > really did read it and it=E2=80=99s a patch file. Patch files are hard fo= r humans > to read. It=E2=80=99s really nice to have a redline, but it=E2=80=99s als= o nice to know > what the full thing is without having to mentally emulate git. > > > > > I've spent some time thinking about use cases for different chunk > > sizes, and I can't come up with any modulo some, IMHO, insignificant > > performance tweaks. Can you please give some examples of use cases > > that would profit from different chunk sizes? > > I=E2=80=99m not the one proposing the large chunk sizes. And as I underst= and the > people who are doing it, performance isn=E2=80=99t their issue, data inte= grity is. > > There=E2=80=99s a dilemma in here. > > One is that there=E2=80=99s a belief that > > > > > What should / would you recommend an implementation do if it > > encounters a chunk that it can't buffer? I see two choices: report > > an error, or release unauthenticated plaintext. > > Report an error. I=E2=80=99ve said that many times. > > > Regarding our implementation: it doesn't actually have tight resource > > constraints. Our primary goal is to write a secure implementation. > > Okay, so you=E2=80=99re arguing resources when you don=E2=80=99t really m= ean it. Gotcha. I > thought that was the case that the things you were saying didn=E2=80=99t = jibe > together. > > > From that goal, we derived the constraint that we must always work in > > a bounded amount of space. The current version of AEAD doesn't allow > > this without potentially rejecting messages that other implementations > > can process by being insecure (releasing unauthenticated plaintext), > > which we don't want to do. > > That constraint is a long-standing meta-requirement in OpenPGP, so cool. > > However, I detect that there is an impossible-to-solve problem here, and > I=E2=80=99ll outline it in another note later. > > > > > But, my concerns are not only about my implementation. I'm concerned > > about the ecosystem. And, the current proposal encourages insecure > > implementations as demonstrated by GnuPG and RNP processing > > unauthenticated plaintext. I think the standard should not > > proactively make it harder to write a secure implementation. And that > > is what I see the AEAD chunk size doing. > > I think I understand where you=E2=80=99re coming from, but this is a stan= dards > organization. Standards are concerned with interoperability between > implementors. I learned that from Jeff Schiller ages ago. Think of a > standard as being like a dictionary and grammar. When you send me a > message, I use that grammar/dictionary to determine what it means. > Similtharly, if I want to encode a message that I want you to understand, > then I encode it according to that grammar as well. > > My proposal above says to an encoder that the safest thing to do is to us= e > a chunk size of 64K. Everyone can decode that, and you=E2=80=99re fine. M= any, many, > many of them are going to be okay with 256K, and odds are that anyone of > any import will do fine with it. (That=E2=80=99s what the SHOULD means). = It also > says there are people out in Lala-land who might be playing with chunks > that are out to 2^whatever, and that=E2=80=99s kinda cool, but ignore the= m. > > That=E2=80=99s why I made it. It gives a sandbox for people who want to g= o out on > the edge that the mainstream can ignore. > > > > > > > Thanks, > > > > Neal > > > > P.S. I hope it is clear that I'm trying to engage in a constructive > > manner. I sincerely haven't understand your position, and I really > > want to. > > I think that=E2=80=99s because I=E2=80=99m trying to support a community = of people who > have reasonable, differing needs, and you want to mandate your > implementation ideas on the universe. I apologize if that=E2=80=99s harsh= , but it=E2=80=99s > what I perceive. If I=E2=80=99m mistaken, let me know. > > Jon > > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > --000000000000ad8e910585416205 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As an implementor (iPGMail on iOS), I strongly support Jon= 's suggestion (16K "MUST", 256K "SHOULD", everythin= g else "MAY").=C2=A0 I dont want to deal with lots of optional si= zes that just introduce complexity with little practical benefit beyond som= e outliers that want to consume huge files in one big bite.=C2=A0 Mobile de= vices are somewhat memory limited (though that is every growing), but 64K o= r 256K is certainly not a problem.

-Wyllys Ingersoll


On Fri, Mar 29, 2019 at 3:59 PM Jon Callas <joncallas= =3D40icloud.com@dmarc.ietf.o= rg> wrote:
neal@walfield.org> wrote:
>
> On Fri, 29 Mar 2019 03:19:39 +0100,
> Jon Callas wrote:
>> Like some interim replies, particularly Bart Butler, I thought we = had a rough consensus and that it was approximately:
>>
>> * MUST support 16KB chunks.
>> * SHOULD support 256K chunks, as these are common (Protonmail). >> * MAY support larger up to the present very large size.
>> * MAY reject or error out on chunks larger than 16KB, but repeatin= g ourselves, SHOULD support 256K.
>
> I still think this is a bad idea.=C2=A0

Noted. It was a position that I threw out because I thought it encompassed = a lot of things that people said and also allows you, the implementer to sa= y, =E2=80=9Cscrew it, we=E2=80=99re doing 256K only and to heck with all of= you=E2=80=9D and it would meet the standard. You could even implement 64K,= thus generating a brinksmanship debate with you and Protonmail and I don= =E2=80=99t have to listen to it.

I think that my proposal above is flawed because there=E2=80=99s this squis= hy space between 64K and 256K, and really hoped someone would either say, = =E2=80=9CFine. I=E2=80=99ll give up on 256K=E2=80=9D or =E2=80=9CFine. 256K= is fine.=E2=80=9D And then we=E2=80=99d modify the proposal and probably b= e done. It was, however a position I thought we might reason from.

>> I could also get behind a hard limit of 2^30 on the grounds that t= hat=E2=80=99s what we had for partial body lengths, but I understand the co= mment that there are things like multi-terabyte S3 buckets and out and out = forbidding those to be single-chunk is a bit churlish, but only a bit.
>
> This is the bit that I don't understand.=C2=A0 Clearly you see som= e
> advantage to having large chunk sizes.

Well, actually what I was doing there was offering a number lower than 2^wh= atever for the max max max oh-dear-god-why-do-you-want-to-do-this size at a= (to me) very, very generous gigabyte to the other side on the max size tha= t you can then safely ignore.


>
> But, let me try to use your framing:
>
> I propose that we remove the chunk size parameter from the AEAD header=
> and fix it to a small value (e.g., 64 KB or 256 KB), because 1.) no > one has shown that a large chunk size is useful, 2.) large chunk sizes=
> encourage implementations to release unauthenticated plaintext, which<= br> > is a serious security concern [1], 3.) if an implementation releases > unauthenticated plaintext for large chunks, then an attacker can
> always convince it to release unauthenticated plaintext for the first<= br> > chunk in a message [2], 4.) making the chunk size variable increases > complexity, which is a security concern.

This isn=E2=80=99t actionable.

There=E2=80=99s a lot of rationale here, but not an actual proposal.

My proposal (left at the top of this missive for easy referral) was a concr= ete proposal. The above paragraph has a lot of justification in it and is i= nteresting polemic but it is not an actual proposal.

If you had said:

* Chunk size is 256K. Always. If you have less than 256K, pad it with zeroe= s.

Then that would be a proposal.

> As I understand your position, you want to allow implementations a
> broad degree of flexibility in choosing the chunk size.=C2=A0 Can you<= br> > please explain why this is useful?=C2=A0 I've reread your messages= , but
> beyond what appears to me to be some hand wavy performance argument, > and an apparent misunderstand (chunk size !=3D message size) [3],
> neither of which are convincing, I can't find any other arguments.=
> I'm sorry if you did and I didn't understand.

You don=E2=80=99t understand my position.

My position is that there are a bunch of people (like you, at least I think= you) who want to build a general-purpose implementation that you hope will= be used all over the place. You have a legitimate need for small chunks.
There are other people who observe that there=E2=80=99s also a legitimate n= eed for huge chunks because they want to do storage encryption on very larg= e things and =E2=80=94 well, they have considerations that I=E2=80=99m not = paying a lot of attention to.

My proposal above lets them do their thing and lets you ignore them. That= =E2=80=99s my position. Making as many people happy as possible.

>
> I'm a bit confused.=C2=A0 In my original mail, I included a PR: >
>=C2=A0 https://mailarch= ive.ietf.org/arch/msg/openpgp/XH098WlJe8lkOypIaB1IXTde2sY
>
> Was that not actionable enough?=C2=A0 Should I link to the PR more oft= en?

It would help, but even better would be to send what the proposal is. I rea= lly did read it and it=E2=80=99s a patch file. Patch files are hard for hum= ans to read. It=E2=80=99s really nice to have a redline, but it=E2=80=99s a= lso nice to know what the full thing is without having to mentally emulate = git.

>
>=C2=A0 I've spent some time thinking about use cases for different = chunk
>=C2=A0 sizes, and I can't come up with any modulo some, IMHO, insig= nificant
>=C2=A0 performance tweaks.=C2=A0 Can you please give some examples of u= se cases
>=C2=A0 that would profit from different chunk sizes?

I=E2=80=99m not the one proposing the large chunk sizes. And as I understan= d the people who are doing it, performance isn=E2=80=99t their issue, data = integrity is.

There=E2=80=99s a dilemma in here.

One is that there=E2=80=99s a belief that

>
>=C2=A0 What should / would you recommend an implementation do if it
>=C2=A0 encounters a chunk that it can't buffer?=C2=A0 I see two cho= ices: report
>=C2=A0 an error, or release unauthenticated plaintext.

Report an error. I=E2=80=99ve said that many times.

> Regarding our implementation: it doesn't actually have tight resou= rce
> constraints.=C2=A0 Our primary goal is to write a secure implementatio= n.

Okay, so you=E2=80=99re arguing resources when you don=E2=80=99t really mea= n it. Gotcha. I thought that was the case that the things you were saying d= idn=E2=80=99t jibe together.

> From that goal, we derived the constraint that we must always work in<= br> > a bounded amount of space.=C2=A0 The current version of AEAD doesn'= ;t allow
> this without potentially rejecting messages that other implementations=
> can process by being insecure (releasing unauthenticated plaintext), > which we don't want to do.

That constraint is a long-standing meta-requirement in OpenPGP, so cool.
However, I detect that there is an impossible-to-solve problem here, and I= =E2=80=99ll outline it in another note later.

>
> But, my concerns are not only about my implementation.=C2=A0 I'm c= oncerned
> about the ecosystem.=C2=A0 And, the current proposal encourages insecu= re
> implementations as demonstrated by GnuPG and RNP processing
> unauthenticated plaintext.=C2=A0 I think the standard should not
> proactively make it harder to write a secure implementation.=C2=A0 And= that
> is what I see the AEAD chunk size doing.

I think I understand where you=E2=80=99re coming from, but this is a standa= rds organization. Standards are concerned with interoperability between imp= lementors. I learned that from Jeff Schiller ages ago. Think of a standard = as being like a dictionary and grammar. When you send me a message, I use t= hat grammar/dictionary to determine what it means. Similtharly, if I want t= o encode a message that I want you to understand, then I encode it accordin= g to that grammar as well.

My proposal above says to an encoder that the safest thing to do is to use = a chunk size of 64K. Everyone can decode that, and you=E2=80=99re fine. Man= y, many, many of them are going to be okay with 256K, and odds are that any= one of any import will do fine with it. (That=E2=80=99s what the SHOULD mea= ns). It also says there are people out in Lala-land who might be playing wi= th chunks that are out to 2^whatever, and that=E2=80=99s kinda cool, but ig= nore them.

That=E2=80=99s why I made it. It gives a sandbox for people who want to go = out on the edge that the mainstream can ignore.

>
>
> Thanks,
>
> Neal
>
> P.S. I hope it is clear that I'm trying to engage in a constructiv= e
> manner.=C2=A0 I sincerely haven't understand your position, and I = really
> want to.

I think that=E2=80=99s because I=E2=80=99m trying to support a community of= people who have reasonable, differing needs, and you want to mandate your = implementation ideas on the universe. I apologize if that=E2=80=99s harsh, = but it=E2=80=99s what I perceive. If I=E2=80=99m mistaken, let me know.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Jon


_______________________________________________
openpgp mailing list
openpgp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/openpgp
--000000000000ad8e910585416205-- From nobody Fri Mar 29 13:39:19 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD7112032A for ; Fri, 29 Mar 2019 13:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com 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 Ro9pEAgSNwiW for ; Fri, 29 Mar 2019 13:39:16 -0700 (PDT) Received: from mr85p00im-zteg06011501.me.com (mr85p00im-zteg06011501.me.com [17.58.23.182]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FC3812034F for ; Fri, 29 Mar 2019 13:39:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1553891954; bh=rzBQlrKvpervuKs+3H6uvkmLdMFQ2Z/yeN7p9oWfMH8=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=XRgtIaojbJ4V05oZVdNxNIf5s9FSrVyoZcpTJQsj1j7R066Clx0R1pJ/u7MqY3kGX lWJkYRi1SXsCSxwWDpJRAPKAwEqzzRiygsJzOi37xHFcAiRTEN9KoGTGV2NBP2nK56 A69PgjpZNeRJikUTnvcbS69JpR6l5g9cDO0cKQB1rG8IFwIREJDLxjuN/lH8AoTpYX cGA4uI+y1Ble8+8Uccucsgzyw7p78Y7WSx6Z7njUshDqGViLVrF07Z8DBE2qy8Mp+U egYJ/Rf3S7pt0MamghLu7mpO551sYMiFRWShR4MBPxjc9RrjZDMs5AMebuHotkvvse EIEkAu8U7AUsA== Received: from [192.168.7.69] (thing1.merrymeet.com [173.164.244.99]) by mr85p00im-zteg06011501.me.com (Postfix) with ESMTPSA id A1A392A00DE; Fri, 29 Mar 2019 20:39:14 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Jon Callas In-Reply-To: Date: Fri, 29 Mar 2019 13:39:13 -0700 Cc: Jon Callas , openpgp@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <8736n63bav.wl-neal@walfield.org> To: Marcus Brinkmann X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-29_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=647 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1903290142 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 20:39:18 -0000 > On Mar 29, 2019, at 2:52 AM, Marcus Brinkmann = wrote: >=20 > Hi, >=20 > Just to set the record straight: I made two very specific actionable > proposal on this very list 9 months ago. Yes, you did, and really, that=E2=80=99s the one that I think we=E2=80=99v= e been debating from. Summarizing, you said max chunk size of 64K. There has been a lot of quibbling from there, like the Protonmail people = saying 256K, and others wanting some other things. Your proposal was the starting point from the one I kicked out = yesterday. Jon From nobody Fri Mar 29 13:42:51 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E124012034F for ; Fri, 29 Mar 2019 13:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com 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 Ckc-k-FSj7EM for ; Fri, 29 Mar 2019 13:42:48 -0700 (PDT) Received: from mr85p00im-ztdg06011801.me.com (mr85p00im-ztdg06011801.me.com [17.58.23.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1139812035E for ; Fri, 29 Mar 2019 13:42:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1553892167; bh=cKrYi3yb4SvrGk6gY0BD8z07XgoSCuPffuSL7E+7QQE=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=uJZwqPYAV8c8sadkww4jl1TVx6+EiPAxRl6Lf6DhNPL2l3UZDBVADRAMESaB9plUg 2+GeK/sNXxUHqRlLfesXgycshViD2Q4zd5gtRr5x7R6JyCbFxyezf+3dhcMlh99/UC VnhvM/FG1ey8SEuWlxFb+hYq0saxxSt0OPhK6MtGEaJjolkxGCgk5C8NOjPAtXmpWi FYCBGYR4vkQicZ68hTavsW9qKXdvry8OocCs57AQ5hWm1Q37s9NwUekfYfoKbR5VTw oJX/l3B+iXHBMwL+RKCp7eAXqyb/ul+c6NKMkolB/XcjLdqt17DGdnzwA6WQ2zX7GN IgO1gAMaePYaA== Received: from [192.168.7.69] (thing1.merrymeet.com [173.164.244.99]) by mr85p00im-ztdg06011801.me.com (Postfix) with ESMTPSA id 22D6BC0125; Fri, 29 Mar 2019 20:42:47 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Jon Callas In-Reply-To: <87d0m9hl62.wl-neal@walfield.org> Date: Fri, 29 Mar 2019 13:42:46 -0700 Cc: Jon Callas , Peter Gutmann , "openpgp@ietf.org" , Justus Winter Content-Transfer-Encoding: quoted-printable Message-Id: References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <87d0m9hl62.wl-neal@walfield.org> To: "Neal H. Walfield" X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-29_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=467 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1903290142 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 20:42:50 -0000 > On Mar 29, 2019, at 6:20 AM, Neal H. Walfield = wrote: >=20 >> As I mentioned earlier, we really need some data on real-world use = cases >> rather than hypothesising problematic corner cases that will rarely, = if ever, >> occur. >=20 > Efail occured. Why is that not enough? Many of us think that Efail is orthogonal to this problem and = consequently while it=E2=80=99s a real issue, as a rationale, it=E2=80=99s= lacking. You might disagree with us, and I respect that. Nonetheless, I find = Efail to be unconvincing. I=E2=80=99d love to debate this further, but = do you have *another* rationale, or it only Efail? Jon From nobody Fri Mar 29 13:49:06 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8FD3120356 for ; Fri, 29 Mar 2019 13:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com 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 we7gO5ZmaBB5 for ; Fri, 29 Mar 2019 13:49:01 -0700 (PDT) Received: from mr85p00im-zteg06022001.me.com (mr85p00im-zteg06022001.me.com [17.58.23.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5052120366 for ; Fri, 29 Mar 2019 13:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1553892541; bh=fs6gred3Je7rUtRv8bGcTj+JBbMwY0m+gjIcQPczZFQ=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=vjzmRVJzNmPSNbb/Bh7TZnVPH6rCiZAJ9t7lNzzrId8MLF1mi0+ZOx8vXZ/FMYnNC WgKYNjtMFyqz6ViraMIn5rOEKXxuC6O3HaqmKHhUjdcEuIHoCYYcO1+8Fi9grh+ucQ I0A9Inm+FcqfrpkDf8rRLRepX6BNaHrLc5Z6Fom+Ck8WT4tjXge/j+VqLWwW4kLWKE uuGYU1hoffbDav88VZN2PuNz9X6FrzhyUXY7gYWwrmKxtLhVwzEiXbQIEMMEhTyPPd wdlt2LNYXuoH+KqRvW7v+aqWZOJwJ2wJBTOKhM//s9I1LbIdi6kNFrwcV9BHIieZ/w Qu1y4DtoPRMzg== Received: from [192.168.7.69] (thing1.merrymeet.com [173.164.244.99]) by mr85p00im-zteg06022001.me.com (Postfix) with ESMTPSA id BF5809000DE; Fri, 29 Mar 2019 20:49:00 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Jon Callas In-Reply-To: <87zhpd21d3.wl-neal@walfield.org> Date: Fri, 29 Mar 2019 13:48:59 -0700 Cc: Jon Callas , Peter Gutmann , "openpgp@ietf.org" , Justus Winter , Jon Callas Content-Transfer-Encoding: quoted-printable Message-Id: References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <87zhpd21d3.wl-neal@walfield.org> To: "Neal H. Walfield" X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-29_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=800 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1903290143 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 20:49:04 -0000 > On Mar 29, 2019, at 7:37 AM, Neal H. Walfield = wrote: >=20 >=20 > Ok. Is your position that the working group should remove AEAD from > 4880bis until there is an academic study proving people need it? I think that if Peter wanted to remove AEAD, he=E2=80=99d just say that. But no, the whole reason he and I and others are debating is that we = think that AEAD in OpenPGP is a Good Idea. >=20 >>> Efail occured. Why is that not enough? >>=20 >> That was due to broken email apps. If I can convince your email app = to >> forward the plaintext of a decrypted message to me, you lose no = matter what >> encryption mechanism you use. >>=20 >> Admittedly CBC/CFB made this easier, but it was the email apps that = needed >> fixing, not PGP. >=20 > I see it differently. I would say it was a combination of the email > applications needing fixing and PGP needing fixing. Before I go further, it=E2=80=99s OpenPGP. This working group is = OpenPGP. PGP is a software product owned by Symantec. It implements OpenPGP, as = well as S/MIME, X.509, and a whole lot of other things. >=20 > PGP encourages implementations to support streaming, and most do. > But, using 4880, this means that an application may see plaintext from > unauthenticated ciphertext. Efail shows how that can be exploited by > ***modifying the ciphertext*** (a PGP problem) to create a potential > exfiltration channel. Using chunked AEAD correctly, this type of > attack is not possible: it is possible to stream, and only release > plaintext from authenticated ciphertext. >=20 > Now, applications could have protected themselves from this attack if > they had backed out the message on MDC failure. But, they didn't. > And, I'd argue that a major reason that they didn't was because this > type of attack is not well understood by application developers. > Application developers understand truncation. But, ciphertext > modification is something that most have probably never heard of. > Since we can protect application developers from ciphertext > modification, I would argue that not doing so is negligent. >=20 > So, if we are distributing blame, and I'd rather not play that game, > then I'd place 90% of the blame on the WG and the PGP implementations, > and only 10% on the mail application developers. Then why does it work with S/MIME? Do they get 90% too? That brings us up to 190% of the blame, which might be called for, given = that it is a major cluster, but I think it=E2=80=99s orthogonal to what = we=E2=80=99re talking about here. How about if we just work on AEAD instead of debating Efail? Especially = since we agree on AEAD being needed. Jon From nobody Fri Mar 29 15:30:25 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC81120333 for ; Fri, 29 Mar 2019 15:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.45 X-Spam-Level: X-Spam-Status: No, score=-3.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com 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 ZkmB7-Vfh963 for ; Fri, 29 Mar 2019 15:30:22 -0700 (PDT) Received: from mr85p00im-hyfv06021301.me.com (mr85p00im-hyfv06021301.me.com [17.58.23.188]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5ED4120307 for ; Fri, 29 Mar 2019 15:30:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1553898621; bh=KkiQBx43gA+C7Klsf+JEORpQAhsL9rqlaw4aIx8v7gw=; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To; b=TtvSnXTbS0lstN78AMXcMnsFrSVbILP/YqWnQ2Ef1zRpSAU+hem8hgaip91AGkcnW /FjTMXfxJpZSb9Xe3D6n86x7P6cCvmfBzUeJweBr94RFxzOTTXoAqRKCJUibq2S0Us a7Uk/EdIEjYZmA4hUvrqIu3Cc6lEVmrS9CXRQWEj4A+Gs/UMF8UnoD8H1xemb/CKiX XTgIINyIw+grB+IOR83W0zPNdEWmaPR3T/Yw1D8D2AjiifQcGhjj7Nrjl7bOXrrt0o L6MK/0ArWWt/kLDx4dDu4Ct6vgU3XY8m5+K9y6D9ANHKSlRiLN4XWAk5EkecFYAs07 g18KSn88CEoGg== Received: from [192.168.7.69] (thing1.merrymeet.com [173.164.244.99]) by mr85p00im-hyfv06021301.me.com (Postfix) with ESMTPSA id AAABE4015C; Fri, 29 Mar 2019 22:30:16 +0000 (UTC) From: Jon Callas Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: Date: Fri, 29 Mar 2019 15:30:15 -0700 Cc: Jon Callas To: "openpgp@ietf.org" X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-29_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1903290152 Archived-At: Subject: [openpgp] The AEAD Conundrum as it pertains to OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 22:30:24 -0000 I=E2=80=99m going to lay this out quasi-rigorously. Or at least as = rigorously as I feel like doing. In this missive, I am going to show that the stated goals of AEAD in = OpenPGP are impossible to obtain, and that one of the goals is going to = have to give. Premises: (O1) An OpenPGP implementation MUST be able to process a message of = arbitrary size. (O2) An OpenPGP implementation MUST have a reasonable bound on memory; = in fact, it must be possible to make an OpenPGP implementation that = works on some tightly-bound system. Not as tight as an Arduino, but = really tight. (A1) An AEAD implementation must be all or nothing; by this we mean that = if it detects an error in the authentication, it must return an error = and no plaintext. (A2) An AEAD implementation must never release unauthenticated plaintext A1 and A2 are almost the same thing. I mean A1 to say you can=E2=80=99t = release plaintext that you know is bad. I mean A2 to say that you = can=E2=80=99t release plaintext that you don=E2=80=99t know is good. I = am this positing that there is something that at least one bit that = didn=E2=80=99t fail, but doesn=E2=80=99t yet pass. In short, we have = known good data, known bad data, and something in the middle. I also = presume that we will be able to put the middle stuff into either the = pass or fail buckets, we just can=E2=80=99t yet. Example: There=E2=80=99s a 10 byte data blob. 9 bytes have come in on = the wire. Those nine bytes are in that middle area where we don=E2=80=99t= know (yet) if they=E2=80=99re good or bad. We presume that we *will* = know, but there=E2=80=99s exponential backoff happening in the = interpipes and so we gotta wait. Should the connection break, then = we=E2=80=99ll consider them to be bad, because of premise A2. Thus: O1 and O2 tell us that we must have a chunking system. Since a message = can be of arbitrary size and we have to have a memory bound, we have to = process things in chunks.=20 =46rom A1 and A2, we know that any given chunk gets released either as a = unified whole, either good or bad. Consider this small example. Alice sends to Bob =E2=80=9CAXBX=E2=80=9D and somewhere along the way, = Eve modifies the B. When Bob receives it, his implementation detects the = error perfectly, knowing that the third position was modified. (How? = Beats me.) Despite knowing that the AX is good, Bob=E2=80=99s = implementation tosses the whole thing away and tells Bob there was an = error. Okay, now let=E2=80=99s look at =E2=80=9CAXXBX=E2=80=9D and again, Eve = modified the B. (How? My presumption is that Eve is modifying the next = to the last byte, but there are other explanations.) Same as the case = above, toss the whole thing out. Ditto for =E2=80=9CAXXXBX=E2=80=9D and = so on.=20 I am thus creating the set of messages M where each m =E2=88=88 M is of = the form =E2=80=9CA=E2=80=9D followed by some number of =E2=80=9CX=E2=80=9D= s and then =E2=80=9CBX=E2=80=9D. In each of these, Eve modifies the B. I = think that we can agree that for all of these messages, the message gets = rejected because Eve modified the penultimate byte. In short, all = messages m =E2=88=88 M are invalid and must be rejected, with an error = message and no plaintext. But wait... Consider the case with =E2=80=9CAXX...BX=E2=80=9D where the B falls on = the first byte of the second chunk. The first chunk is valid and gets released, but there=E2=80=99s an error = in the second chunk, so we error and reject. This is a contradiction; we have a message that is in error, and yet = we=E2=80=99ve released almost all of it. What this means is that you cannot both satisfy O1 and O2 along with A1 = and A2. QED. Discussion: In the AEAD discussion we=E2=80=99ve had, we=E2=80=99re wanting to do = what I just showed is impossible. A strict reading of AEAD semantics = along with arbitrary message sizes is contradictory. Obviously, we *can* relax the semantics to say that we only mean = O1,O2,A1,A2 within a chunk. That=E2=80=99s easy. Similarly, we can *approximate* strict behavior in many circumstances. = Example: consider decrypting a large file, and we validate each chunk = and write it to the file, then when we get to the end, we clean up the = file, delete it, and return an error. There are many places where this = sort of backtracking is indistinguishable from the strict semantics. Nonetheless, there are places where you must release plaintext that will = be processed by some other system (imagine a shell session) and then you = learn there is an error. Moving finger writes, and so forth and so on. I also want to note that the smaller the chunk size, the bigger this = contradiction is a real issue. That=E2=80=99s why I started with = something small in my layout of it. It seems utterly obvious to me that = with a four-byte message we must, must, must reject it and burn it with = fire. But if it was a petabyte with an indeterminate length (we don=E2=80=99= t know it=E2=80=99s over until it=E2=80=99s over)? Ennnnnnh, sure, = whatever; it doesn=E2=80=99t bother me that we don=E2=80=99t learn it = right away. Even for 256K, I=E2=80=99m not bothered. I=E2=80=99m willing = to nod and say, =E2=80=9CYeah, it=E2=80=99s a problem, but not a big = one=E2=80=9D at 64K, even. But even as we approach smaller and smaller = messages, I believe that the solution is that you have as large a chunk = as is reasonable. Bigger chunk means better security. This affects the AEAD discussion in some ways that I=E2=80=99ve noticed. Some of the agitation has been over wanting to preserve the strict AEAD = behavior, in both directions. The major reason for an arbitrarily large = chunk size is that you cannot in all cases both chunk and preserve = strict semantics. You have to pick one, and relax (or give up on) the = other. As I said, in many cases this doesn=E2=80=99t matter, and as many of us = (like Peter Gutmann and I) have noted, OpenPGP is most often used for = something that is more like storage than communications, so you can do = the emulation fallback. If I am decrypting a file, an S3 bucket, or even = a MIME part in an email, I can backtrack. In an interactive protocol = like TLS, backtracking is not possible in general. In fact, I=E2=80=99m = hard pressed to think of a specific where it=E2=80=99s possible. I believe that underlying this is a confusion about encryption = semantics. There are often huge semantic differences between interactive = protocols and static protocols when it comes to classes of errors. There = are many breaks that are interactive-only. The breaks of PKCS#1 V1.5, = almost all compression problems, and more are huge problems in an = interactive protocol, and within epsilon of zero-problem for many, many = deltas. I think this is a source of many things that I=E2=80=99ve thought were = confusing. I am happy with some looseness on the AEAD semantics. In short, this = problem doesn=E2=80=99t really bother me, and I can cope with, =E2=80=9Cju= st deal with it=E2=80=9D as an answer to the contradiction I lay out. = However, I recognize that not everyone is that way, and there are people = who have really good reasons for wanting strict semantics. I am puzzled = that the people who are most concerned about strict security appear to = be the once who are most adamant about small chunks. And that makes me = at least raise an eyebrow. I think that the best solution for us all is some compromise similar to = the one that I laid out yesterday. Make a chunk size that=E2=80=99s = reasonable (64K, 256K, 10K, who cares) and *allow* people who want more = to go there knowing that they will be trading strict security for = interoperability. The tighter the AEAD semantics, the more you need to = allow for larger chunks. I believe that the more you believe tight = security is necessary, then the more *willing* you ought to be to allow = people with special needs to go off in the weeds on their own. Since = that is not the case =E2=80=94 the people who want strict semantics are = arguing for small chunks and listing their belief in strictness as a = reason for small chunks, I am confused. Jon From nobody Fri Mar 29 17:20:00 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5204120059 for ; Fri, 29 Mar 2019 17:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (3072-bit key) header.d=crustytoothpaste.net 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 UgQ7WHn5sN5I for ; Fri, 29 Mar 2019 17:19:57 -0700 (PDT) Received: from injection.crustytoothpaste.net (injection.crustytoothpaste.net [192.241.140.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6C0F12001E for ; Fri, 29 Mar 2019 17:19:56 -0700 (PDT) Received: from genre.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:cd73:609e:99e6:698f]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by injection.crustytoothpaste.net (Postfix) with ESMTPSA id B0D2C60446; Sat, 30 Mar 2019 00:19:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net; s=default; t=1553905195; bh=2x80Xf7gCE1aX4bQLPQ1YPOIL/qfwuY01GsqpT36Rdc=; h=Date:From:To:Cc:Subject:References:Content-Type: Content-Disposition:In-Reply-To:From:Reply-To:Subject:Date:To:CC: Resent-Date:Resent-From:Resent-To:Resent-Cc:In-Reply-To:References: Content-Type:Content-Disposition; b=beJKjrsmdrd5hNTjSSk64Q/O1DFZLqgzA627Zv14TbB7Ztr97TnkVLnQOKKxAscWQ mXnRJFmitvucuj6BRwGZE24k66tbsWpoYUjPML7ZIFE37kjA38aJ97Z5/7TLvgWyu6 vmkCPHPd46rX4j6msf3yoEuOSYTpNqa/IOax9rQMd/NpdAEjnu3HOA/CMvWVofAcaf L9RYDcu8eCfH9gSWSjJdF+vXNKaeLtfS5TtorCDz3tQtaWze9PcLjdyQ/qxYruKB1c xZHxbJRTgX8HtENN/S9zXWHSxLm93KX8Q8A0M2nPH3pekvnWO5Vn+K9b0PS7PidX18 ITwNgsw0QqwcESvubxJMk/ekWJ6ZNsst18bunYZZEFWgEVZZy3s4hChzPu6BEC8o4f YRMUGqzni4n58QDE1GEyyJAVH/wJFkhAyK00R0Y34e92Q82y5CY/12OzsYWKNkshT+ 6QmxFknFpztRP0fVlGfoGrAoTuC2cfc6C1Sl5H2YK1thdAkoPlQ Date: Sat, 30 Mar 2019 00:19:49 +0000 From: "brian m. carlson" To: Jon Callas Cc: "Neal H. Walfield" , openpgp@ietf.org, Justus Winter , Jon Callas Message-ID: <20190330001949.GB12419@genre.crustytoothpaste.net> References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <8736n63bav.wl-neal@walfield.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UHN/qo2QbUvPLonB" Content-Disposition: inline In-Reply-To: X-Machine: Running on genre using GNU/Linux on x86_64 (Linux kernel 4.19.0-4-amd64) User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 127.0.1.1 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2019 00:19:59 -0000 --UHN/qo2QbUvPLonB Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 28, 2019 at 07:19:39PM -0700, Jon Callas wrote: > I wrote a point-by-point reply and decided that that=E2=80=99s not produc= tive. I=E2=80=99m going to try to cut to the chase on this, so forgive me i= f I have dodged an important point. I=E2=80=99m happy to come back to it la= ter. >=20 > Like some interim replies, particularly Bart Butler, I thought we had a r= ough consensus and that it was approximately: >=20 > * MUST support 16KB chunks. > * SHOULD support 256K chunks, as these are common (Protonmail). > * MAY support larger up to the present very large size. > * MAY reject or error out on chunks larger than 16KB, but repeating ourse= lves, SHOULD support 256K. I think this is fine. It covers what's requires for interoperability, it makes prudent suggestions, and it allows people leeway if they know they're the only one consuming their data. If people like my original proposal, that's also fine with me (as would be expected). --=20 brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 --UHN/qo2QbUvPLonB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.2.14 (GNU/Linux) iQIzBAABCgAdFiEEX8OngXdrJt+H9ww3v1NdgR9S9osFAlyetiQACgkQv1NdgR9S 9osG9Q/9EMUecuU2jPjKcb9dDPr/ECnxzUquOyEqMXFQvAiLlJ6yR7uXcUPLveNx R5i6SSecgHM44+YHwzVaUdr49gdjvSS3KIiadtWXwtSwFT0zM5i2X1AH4XaX2LLZ mmbjtDECyw+YxuF/XiIJIToNOGOn0qo5qZqfiH+SirYx41xVRtE2iY6EScZDVB64 YhtE0Tulss7IpN6P0CjA5G0PjOx+OBL/4B7uvm8tx/YjhNbiohBF6PUedx9UpK6E 1Tpg8r5BIh/Q6o9hLBw7W4l2nvPTm3bnTx2UbGrVdsfnvLCqAkKeI1UTLlh0lLYl CxbjSDDmwlLtcJ3jT31+TBVD7Sf1xyEyQvIGQLTXw2ruD/gWoK6BbSqA5zJejXq2 WiP3ERxh6RRMcmPNV52VcAxOtli+fU4c1D4Kxl+7cc9ntqdSfVn17CdPJh5vmf9n VKx6G9BoYNlipjtLwoNBGUWC7f6zkYfZgbgCKX33lnUqa+i7pcW5aRch9ljXUc0u OKFz8NnNBBfNTraXJWEuSn4ATlUrJBeIDnIqDJj/wHmo40teFYX0vZcI98gUc9pf 5ZKcj8YImEFC+1YEdjeRaLeyZM8h2zKuSie1uFD/mQc25vSjNqB045M/drTLoHlm 7xNwiiVfdsvgyYxZLBff+HBhSrPiIGPs1o7ITlb9Fmwjh6hiDC8= =C7c3 -----END PGP SIGNATURE----- --UHN/qo2QbUvPLonB-- From nobody Fri Mar 29 19:18:07 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238A4120090 for ; Fri, 29 Mar 2019 19:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com 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 MgWEHNgs3tjl for ; Fri, 29 Mar 2019 19:18:02 -0700 (PDT) Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13EAF12006A for ; Fri, 29 Mar 2019 19:18:02 -0700 (PDT) Date: Sat, 30 Mar 2019 02:17:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1553912279; bh=Bbw46eNaDo0Id7afYPNU73BhzH6J6Rdo1A9yn+rKUak=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=cUvvtEhZHr4INKcpvyGYrd2+nLQL5OI92XVfT2DKJXVGTLUNL9tq018r3Mut3jo5B /ptOb7agmWVLVpCQOrJryXnN7K8Gm+7G29ZUfAir1OFMFBIcHH9auuZliZDPj3DgTp fi8IZA+3s6twGyN6x7qC47Zilai63S1UqOop1QSU= To: Jon Callas From: Bart Butler Cc: "Neal H. Walfield" , "openpgp@ietf.org" , Justus Winter , Jon Callas , Peter Gutmann Reply-To: Bart Butler Message-ID: <2di2bK8m-7HtDeoUEH9oPqs-bL-IKSE0CjkgFShPMLOlUyeDBVkVGApdjnIpS6YRAeKU3ibGCZCtwLden-N6zK5W4fqIghRGDa5dU720nEs=@protonmail.com> In-Reply-To: References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <87d0m9hl62.wl-neal@walfield.org> Feedback-ID: XShtE-_o2KLy9dSshc6ANALRnvTQ9U24aqXW2ympbGschdpHbU6GYCTUCtfmGhY9HmOyP1Uweyandwh1AVDFrQ==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="---------------------8742fc61603bbff7f35b1fcf95e6a382"; charset=UTF-8 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2019 02:18:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------8742fc61603bbff7f35b1fcf95e6a382 Content-Type: multipart/mixed;boundary=---------------------c2f7f0f395d59f4b003b2de74b2ac641 -----------------------c2f7f0f395d59f4b003b2de74b2ac641 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain;charset=utf-8 Hi Jon, As others have noted, there is a lot of confusion on this thread, some of = which you touched in your AEAD Conundrum message, like when we say AEAD sh= ould not release unauthenticated plaintext, do we mean the entire message = or the chunk? Another piece of confusion is that Efail isn't a single vulnerability, it = was several vulnerabilities related (at best) thematically. So to be very specific, for the purpose of the following discussion, the a= dvantage of smaller AEAD chunks is specifically to prevent Efail-style cip= hertext malleability/gadget attacks, and the prohibition on releasing unau= thenticated plaintext is applied to individual chunks, which is sufficient= to foil this kind of attack in email. The kind of attack we are talking about is fundamentally about exfiltratio= n of plaintext data to an attacker-controlled endpoint. Borrowing from you= r AEAD Conundrum message, if the first chunk passes and is released, and t= he second chunk fails, that is OK, at least for email, because the part th= at was modified (the second chunk) is never released, so you get a truncat= ed message and an error, but the truncated message without the modificatio= ns isn't going to exfiltrate itself. Now if releasing ANY authenticated chunk of a message that hasn't been ful= ly authenticated (in an AEAD sense) is a real problem for your application= , I'd argue that you're trying to make AEAD do something it's not suited f= or and you should enforce this in your application if it applies to you, p= robably by not streaming. So to recap, small-chunk AEAD provides specific value in preventing cipher= text malleability/gadget attacks, particularly in HTML email, which is a c= ommon use case. What value does large-chunk AEAD actually provide? What I'm getting from t= he AEAD Conundrum message is that it's a way for the message encrypter to = leverage the "don't release unauthenticated chunks" prohibition to force t= he decrypter to decrypt the whole message before releasing anything. Why d= o we want to give the message creator this kind of power? Why should the m= essage creator be given the choice to force her recipient to either decryp= t the entire message before release or be less safe than she would have be= en with smaller chunks? Coming back to Neal's point, it's really hard to see any sort of value in = really large AEAD chunks, because the performance overhead is negligible a= t that point and the only security 'benefit' that I can see is the encrypt= er trying to use the spec to force the decrypter to not stream, which does= not seem like something at all desirable. -Bart P.S. ProtonMail doesn't use V5 keys or the new draft yet, but some users o= f OpenPGP.js have started using them with 256kB chunks, so we are not argu= ing on behalf of ourselves for the 256kB chunk size. The proposed language= seems more or less OK in this regard, as most implementations will presum= ably keep 256kB support so these early adopters will not lose interoperabi= lity with their messages. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original M= essage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Friday, March 29, 2019 1:42 PM, Jon Callas wrote: > = > = > > On Mar 29, 2019, at 6:20 AM, Neal H. Walfield neal@walfield.org wrote: > > = > > > As I mentioned earlier, we really need some data on real-world use c= ases > > > rather than hypothesising problematic corner cases that will rarely,= if ever, > > > occur. > > = > > Efail occured. Why is that not enough? > = > Many of us think that Efail is orthogonal to this problem and consequent= ly while it=E2=80=99s a real issue, as a rationale, it=E2=80=99s lacking. > = > You might disagree with us, and I respect that. Nonetheless, I find Efai= l to be unconvincing. I=E2=80=99d love to debate this further, but do you = have another rationale, or it only Efail? > = > Jon > = > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp -----------------------c2f7f0f395d59f4b003b2de74b2ac641-- -----------------------8742fc61603bbff7f35b1fcf95e6a382 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail Comment: https://protonmail.com wl4EARYKAAYFAlye0dEACgkQmQVEZe8zHkQLewD7B+FQt0olUI/78EPG9pQz wpKwxQfhRPQmElWC703vlugBALTgxvRbSTUsU7J8lM1bf+oUaELVGVtemUsF n28lzPUD =k+fi -----END PGP SIGNATURE----- -----------------------8742fc61603bbff7f35b1fcf95e6a382-- From nobody Sat Mar 30 08:04:57 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E94D91201EC for ; Sat, 30 Mar 2019 08:04:54 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 MigbwSl230w4 for ; Sat, 30 Mar 2019 08:04:53 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06ED31201EB for ; Sat, 30 Mar 2019 08:04:52 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x2UF4cUT001350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 30 Mar 2019 11:04:40 -0400 Date: Sat, 30 Mar 2019 10:04:38 -0500 From: Benjamin Kaduk To: Bart Butler Cc: Jon Callas , "openpgp@ietf.org" , Justus Winter , "Neal H. Walfield" , Jon Callas , Peter Gutmann Message-ID: <20190330150438.GS35679@kduck.mit.edu> References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <87d0m9hl62.wl-neal@walfield.org> <2di2bK8m-7HtDeoUEH9oPqs-bL-IKSE0CjkgFShPMLOlUyeDBVkVGApdjnIpS6YRAeKU3ibGCZCtwLden-N6zK5W4fqIghRGDa5dU720nEs=@protonmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2di2bK8m-7HtDeoUEH9oPqs-bL-IKSE0CjkgFShPMLOlUyeDBVkVGApdjnIpS6YRAeKU3ibGCZCtwLden-N6zK5W4fqIghRGDa5dU720nEs=@protonmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2019 15:04:55 -0000 My apologies for being only an occasional participant in this thread (and it will likely take me another week before I can reply again), but there are a few points I would like to make. On Sat, Mar 30, 2019 at 02:17:55AM +0000, Bart Butler wrote: > Hi Jon, > > As others have noted, there is a lot of confusion on this thread, some of which you touched in your AEAD Conundrum message, like when we say AEAD should not release unauthenticated plaintext, do we mean the entire message or the chunk? It's really quite something to have gone through a week's worth all in one go. There are many people writing out careful descriptions of how they see things, and yet we still seem to be talking past each other at times. I propose that we use "plaintext corresponding to non-modified ciphertex" for the non-malleability protection that is provided by an AEAD authentication tag on a single chunk, and "fully authenticated complete plaintext" for the output after processing an entire message (i.e., all chunks) with guarantee of non-truncation. (Are there other cases in between that we care about?) > Another piece of confusion is that Efail isn't a single vulnerability, it was several vulnerabilities related (at best) thematically. > > So to be very specific, for the purpose of the following discussion, the advantage of smaller AEAD chunks is specifically to prevent Efail-style ciphertext malleability/gadget attacks, and the prohibition on releasing unauthenticated plaintext is applied to individual chunks, which is sufficient to foil this kind of attack in email. > > The kind of attack we are talking about is fundamentally about exfiltration of plaintext data to an attacker-controlled endpoint. Borrowing from your AEAD Conundrum message, if the first chunk passes and is released, and the second chunk fails, that is OK, at least for email, because the part that was modified (the second chunk) is never released, so you get a truncated message and an error, but the truncated message without the modifications isn't going to exfiltrate itself. One concern that I have (and is only tangentially related to this quoted part) is that I want to make it easy for implementations to "do the right thing" when ciphertext is modified, i.e., return an error, and specifically to return an error without releasing any plaintext that originates from the modified ciphertext. The current openpgp ecosystem does not seem to be very compliant to that desired behavior, and part of that may be due to a lack of philosophical support/help from the spec. > Now if releasing ANY authenticated chunk of a message that hasn't been fully authenticated (in an AEAD sense) is a real problem for your application, I'd argue that you're trying to make AEAD do something it's not suited for and you should enforce this in your application if it applies to you, probably by not streaming. > > So to recap, small-chunk AEAD provides specific value in preventing ciphertext malleability/gadget attacks, particularly in HTML email, which is a common use case. > > What value does large-chunk AEAD actually provide? What I'm getting from the AEAD Conundrum message is that it's a way for the message encrypter to leverage the "don't release unauthenticated chunks" prohibition to force the decrypter to decrypt the whole message before releasing anything. Why do we want to give the message creator this kind of power? Why should the message creator be given the choice to force her recipient to either decrypt the entire message before release or be less safe than she would have been with smaller chunks? > > Coming back to Neal's point, it's really hard to see any sort of value in really large AEAD chunks, because the performance overhead is negligible at that point and the only security 'benefit' that I can see is the encrypter trying to use the spec to force the decrypter to not stream, which does not seem like something at all desirable. I'm still not sure I understand the point of very large chunks, since once they get really big an implementation is choosing between streaming plaintext from potentially modified ciphertext or return an error without even attempting to process the chunk. I'm not convinced that the second will win out in implementations if we alow very large chunks. Some other notes, not relating to anything specifically quoted from this message (but derived from other parts of the thread): TLS allows for arbitrarily variable-length chunks because it is a synchronous transport for higher-level application streams and the application may have arbitrary message sizes. OpenPGP is used in an asynchronous model, where a message generator can be modelled to make all its actions before the receiver processes anything, and there is only one-directional communication within the OpenPGP format. So there does not seem to be much demand for "take all the bytes that you have so far and send them right now", and AFAICT the message generator can just wait until end of data arrives or enough data to make a complete chunk arrives. So from that point of view, there is not much argument in favor of varying the chunk size within a single message, and possibly even across messages (i.e., this line of reasoning would be okay with a single chunk size fixed for everyone as a protocol constant). There are of course other factors that may come into play, like constrained systems and such, but we can treat those separately. I also have a use case for authentication of large chunks of data at rest: they allow me to use a cheap bulk storage service that provides (best-effort) replication and archiving but has poor physical security. So I encrypt my data to myself and put it in storage, but when I get it back I need to know that it's valid. I can imagine at least one case where knowing exactly which chunk was corrupted would save effort; it may be a toy example but perhaps it is illustrative of a broader case. Note that there are algorithms to compute pi to arbitrary precision, and even to compute the Nth digit thereof without coputing the previous digits. If I need to have random-access inquiries into the value of pi, I could precompute using softare I trust and do this self-encryption thing, and when a chunk is bad I can recompute only that chunk and still trust that I only ever use values generated by my trusted implementation. And finally, there is no openpgp Working Group; all we have here is a bunch of folks interested in a topic talking amongst each other on a public mailing list hosted at the IETF. There are no WG chairs and no expectation of Area Director supervision (i.e., I don't feel obligated to read the messages here). That said, I'm happy to see that we're staying calm and civil, and AFAICT everyone is honestly trying to understand everyone else's position and come to a consensus. Let's try to keep focusing on the technical details and what use cases we need to cover. Thanks, Ben From nobody Sat Mar 30 09:42:32 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96DDC12020A for ; Sat, 30 Mar 2019 09:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com 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 VFqaRmueFred for ; Sat, 30 Mar 2019 09:42:27 -0700 (PDT) Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E7931201ED for ; Sat, 30 Mar 2019 09:42:26 -0700 (PDT) Date: Sat, 30 Mar 2019 16:42:19 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1553964144; bh=itJ40FMZ9CkRiDcqMdBzQ7sqR0FLy9VzoBhoUnTKs1U=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=fc1Ufod51cnhclFEsEwf/787xqwp4zPMiaOfy6ePys/8uAexJBSG9wKODLlCjjvJ1 StTCOjLJoNc650Z1ClJz/TZ6dE/bh0ttMUDyPVq6Uf5jGT983UcrjZftORQVx2qGJU hoUXJV0txjQWtqijhwxrKtjUCioulF3p9a+7AYng= To: Benjamin Kaduk From: Bart Butler Cc: "openpgp@ietf.org" , "Neal H. Walfield" , Peter Gutmann , Justus Winter , Jon Callas , Jon Callas Reply-To: Bart Butler Message-ID: In-Reply-To: <20190330150438.GS35679@kduck.mit.edu> References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <87d0m9hl62.wl-neal@walfield.org> <2di2bK8m-7HtDeoUEH9oPqs-bL-IKSE0CjkgFShPMLOlUyeDBVkVGApdjnIpS6YRAeKU3ibGCZCtwLden-N6zK5W4fqIghRGDa5dU720nEs=@protonmail.com> <20190330150438.GS35679@kduck.mit.edu> Feedback-ID: XShtE-_o2KLy9dSshc6ANALRnvTQ9U24aqXW2ympbGschdpHbU6GYCTUCtfmGhY9HmOyP1Uweyandwh1AVDFrQ==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="---------------------b509239ead97f7605f62cb62d8cf45e7"; charset=UTF-8 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2019 16:42:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------b509239ead97f7605f62cb62d8cf45e7 Content-Type: multipart/mixed;boundary=---------------------0af09c2e133c8403be31c5a154db4627 -----------------------0af09c2e133c8403be31c5a154db4627 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain;charset=utf-8 Hi Ben, > One concern that I have (and is only tangentially related to this quoted > part) is that I want to make it easy for implementations to "do the righ= t > thing" when ciphertext is modified, i.e., return an error, and specifica= lly > to return an error without releasing any plaintext that originates from = the > modified ciphertext. The current openpgp ecosystem does not seem to be > very compliant to that desired behavior, and part of that may be due to = a > lack of philosophical support/help from the spec. > = If you mean 'modified ciphertext' to equal 'modified chunk', and are OK wi= th releasing previously unauthenticated chunks, then I completely agree. T= he alternative is is just no streaming. > I'm still not sure I understand the point of very large chunks, since on= ce > they get really big an implementation is choosing between streaming > plaintext from potentially modified ciphertext or return an error withou= t > even attempting to process the chunk. I'm not convinced that the second > will win out in implementations if we alow very large chunks. > = Agreed. Part of the rationale with a smaller chunk limit is not forcing im= plementations to make this choice. The guidance becomes very simple--never= release unauthenticated chunks, full stop. -----------------------0af09c2e133c8403be31c5a154db4627-- -----------------------b509239ead97f7605f62cb62d8cf45e7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail Comment: https://protonmail.com wl4EARYKAAYFAlyfnGkACgkQmQVEZe8zHkQT1AEA4tzmdlWpKwEKxwq2KTkJ 48fC4eqyufpAU0wehvgOi+AA/18+YETDEn8W5ndCpX7fAAUmJB1Rzux1nyxU 1GAAJ/4D =jaXa -----END PGP SIGNATURE----- -----------------------b509239ead97f7605f62cb62d8cf45e7-- From nobody Sat Mar 30 09:49:51 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6F61201ED for ; Sat, 30 Mar 2019 09:49:49 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 vyJWBCwpPRub for ; Sat, 30 Mar 2019 09:49:47 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 728ED120158 for ; Sat, 30 Mar 2019 09:49:47 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x2UGnbwK026203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 30 Mar 2019 12:49:38 -0400 Date: Sat, 30 Mar 2019 11:49:36 -0500 From: Benjamin Kaduk To: "Neal H. Walfield" Cc: Andre Heinecke , openpgp@ietf.org Message-ID: <20190330164936.GZ35679@kduck.mit.edu> References: <2301148.obROdnegVN@esus> <2020697.uNjeE9oTgC@esus> <87o95wh9xy.wl-neal@walfield.org> <1825148.YadyztgY27@esus> <87lg10h85i.wl-neal@walfield.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87lg10h85i.wl-neal@walfield.org> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [openpgp] Deprecating compression support X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2019 16:49:50 -0000 On Wed, Mar 27, 2019 at 12:24:41PM +0100, Neal H. Walfield wrote: > Hi Andre, > > On Wed, 27 Mar 2019 11:59:32 +0100, > Andre Heinecke wrote: > > On Wednesday 27 March 2019 11:46:01 CET Neal H. Walfield wrote: > > > Are you using some container format? PGP/Mime with multiple > > > attachments? Something else? > > > > As you know we are using tar archives. > > Actually, I didn't know, which is why I asked. > > I've used Kleopatra once or twice to see how it worked, and I've never > used KMail or GpgOl. > > > But if you dislike my example with a folder, which I chose to underline that > > compression is needed. > > I'm sorry that I gave you the impression that I disliked your example. > > > Please ignore it and respond to the other points made > > in this thread like compression for mails or just replace "folder" in my > > example with "file" and there you go. > > > > I find this kind of discussion about my example unhelpful and distracting on > > this list. If you want to further discuss this please do it off list. > > Your tone makes it sounds like I've personally attacked you. I'm not > sure where I did that. If so, I apologize and I will try and keep at > least my side of the discussion more focused on the technical > discussion. At risk of being accused of piling on, I'll note that the tone also came across as something of an escalation, to me. (I don't know whether that was the intent or not.) As for "unhelpful and distracting", technical topics about how openpgp implementations work seem to be helpful things to have in this forum, in general. Yes, it might be distracting from another topic that Andre might want to focus on, in this case, but that is not really grounds to shut down discussion of it. -Ben From nobody Sat Mar 30 09:58:04 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4359512001B for ; Sat, 30 Mar 2019 09:58:02 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 RGoMtSOc6f5k for ; Sat, 30 Mar 2019 09:58:01 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB2F4120158 for ; Sat, 30 Mar 2019 09:58:00 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x2UGvlwk028008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 30 Mar 2019 12:57:49 -0400 Date: Sat, 30 Mar 2019 11:57:47 -0500 From: Benjamin Kaduk To: Bart Butler Cc: "openpgp@ietf.org" , "Neal H. Walfield" , Peter Gutmann , Justus Winter , Jon Callas , Jon Callas Message-ID: <20190330165747.GB35679@kduck.mit.edu> References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <87d0m9hl62.wl-neal@walfield.org> <2di2bK8m-7HtDeoUEH9oPqs-bL-IKSE0CjkgFShPMLOlUyeDBVkVGApdjnIpS6YRAeKU3ibGCZCtwLden-N6zK5W4fqIghRGDa5dU720nEs=@protonmail.com> <20190330150438.GS35679@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2019 16:58:03 -0000 On Sat, Mar 30, 2019 at 04:42:19PM +0000, Bart Butler wrote: > Hi Ben, > > > One concern that I have (and is only tangentially related to this quoted > > part) is that I want to make it easy for implementations to "do the right > > thing" when ciphertext is modified, i.e., return an error, and specifically > > to return an error without releasing any plaintext that originates from the > > modified ciphertext. The current openpgp ecosystem does not seem to be > > very compliant to that desired behavior, and part of that may be due to a > > lack of philosophical support/help from the spec. > > > > > If you mean 'modified ciphertext' to equal 'modified chunk', and are OK with releasing previously unauthenticated chunks, then I completely agree. The alternative is is just no streaming. Right. (I think I heard some people argue that they were not okay with releasing previously unauthenticated chunks, to be clear. That seems like something of a philosophical question, though perhaps there is some better agreement to have. -Ben > > I'm still not sure I understand the point of very large chunks, since once > > they get really big an implementation is choosing between streaming > > plaintext from potentially modified ciphertext or return an error without > > even attempting to process the chunk. I'm not convinced that the second > > will win out in implementations if we alow very large chunks. > > > > > Agreed. Part of the rationale with a smaller chunk limit is not forcing implementations to make this choice. The guidance becomes very simple--never release unauthenticated chunks, full stop. From nobody Sat Mar 30 10:09:49 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 068CE12001B for ; Sat, 30 Mar 2019 10:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com 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 xvJW9ReY50qH for ; Sat, 30 Mar 2019 10:09:43 -0700 (PDT) Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43669120013 for ; Sat, 30 Mar 2019 10:09:43 -0700 (PDT) Date: Sat, 30 Mar 2019 17:09:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1553965780; bh=+0Z9rgGAgGMUQbLTMHzFgTHWShIFNx+Fs2HJve0hcak=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=PBjGqKVBzaPVU6r0Dtsl9BEHp9HCUXdkmgSmuYG1BXKd5+lFXvO1pogtR9i6pfRww tRlPjuK4jwlHB7tOGQhAUDf8X+ljqvCFvqo3rVBM6xMQnkeouk4EnAo19MChNwFHet c6DFYVt/Yp0c4rqi6IlHRSf1wYB2qA8M0WK6C38A= To: Wiktor Kwapisiewicz From: Bart Butler Cc: Werner Koch , "openpgp@ietf.org" Reply-To: Bart Butler Message-ID: In-Reply-To: <02531d3b-c743-6c34-f93b-0bd7a087aa5c@metacode.biz> References: <02531d3b-c743-6c34-f93b-0bd7a087aa5c@metacode.biz> Feedback-ID: XShtE-_o2KLy9dSshc6ANALRnvTQ9U24aqXW2ympbGschdpHbU6GYCTUCtfmGhY9HmOyP1Uweyandwh1AVDFrQ==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="---------------------c7b8ad98cc86a0eace82a929725bbbfe"; charset=UTF-8 Archived-At: Subject: Re: [openpgp] Web Key Directory and CORS X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2019 17:09:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------c7b8ad98cc86a0eace82a929725bbbfe Content-Type: multipart/mixed;boundary=---------------------e260e09d88c3503a25351df527cd1f57 -----------------------e260e09d88c3503a25351df527cd1f57 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain;charset=utf-8 I agree, it would be beneficial to have some CORS guidance in the spec in = order to help implementors support browser-based lookups, and the proposed= language sounds fine to me. What do you think Werner? -Bart =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original M= essage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Monday, March 25, 2019 2:08 PM, Wiktor Kwapisiewicz wrote: > Hello, > = > I would like to ask if it would be possible to add a mention of CORS > header [0] in 3.1. Key discovery [1] in OpenPGP Web Key Directory docume= nt. > = > I think it could be added somewhere below: > = > > The server SHOULD use "application/octet-stream" as the Content-Type > > for the data but clients SHOULD also accept any other Content-Type. > > The server MUST NOT return an ASCII armored version of the key. > = > And the wording may be something like: "It is RECOMMENDED that the key > is returned with 'Access-Control-Allow-Origin' HTTP header set to value > '*'". > = > The context of this change is the following: without appropriate CORS > header JavaScript code running on one domain cannot access resources > hosted on different domains. There are web applications that would like > to fetch the key and encrypt data purely in the browser and send only > encrypted blobs to the backend thus minimizing attack surface somehow. [= 2] > = > OpenPGP.js today can do WKD lookups, but without CORS header set it > cannot fetch keys from any domain [3] thus making WKD not usable in the > browser [4]. > = > One similar paragraph, recommending CORS header for > "/.well-known/host-meta" can be found in XMPP [5]. > = > Thank you for your time! > = > Kind regards, > Wiktor > = > [0]: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS > = > [1]: > https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-07#section= -3.1 > = > [2]: One such site is https://pipefile.com > = > [3]: This was pointed out by Sanjana Rajan: > https://github.com/openpgpjs/openpgpjs/pull/714#issuecomment-392609354 > = > [4]: Thomas Obernd=C3=B6rfer mentions that "For regular web pages, CORS > header would be beneficial": > https://github.com/mailvelope/mailvelope/issues/580#issuecomment-3946900= 51 > = > [5]: https://xmpp.org/extensions/xep-0156.html#impl > = > ------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= --------------------------------------------------------------------------= ------------- > = > https://metacode.biz/@wiktor > = > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp -----------------------e260e09d88c3503a25351df527cd1f57-- -----------------------c7b8ad98cc86a0eace82a929725bbbfe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail Comment: https://protonmail.com wl4EARYKAAYFAlyfoscACgkQmQVEZe8zHkSywgEAvKNcRzPfODTBjYHj6IOq AFOBONoCZKOoZ/ZZ+Mhus1gA/0MCJAlLsDp4q8vuOVHi6jK3bV2bTZhAmSBb kbayrh8E =dfGL -----END PGP SIGNATURE----- -----------------------c7b8ad98cc86a0eace82a929725bbbfe-- From nobody Sat Mar 30 10:12:10 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AED112001B for ; Sat, 30 Mar 2019 10:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com 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 OT-PU-ik3Jx3 for ; Sat, 30 Mar 2019 10:12:06 -0700 (PDT) Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB746120013 for ; Sat, 30 Mar 2019 10:12:06 -0700 (PDT) Date: Sat, 30 Mar 2019 17:12:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1553965924; bh=1greV5c4NYuUWX8Hq0ZWwD3g7eoRUNlVG+5Ss8wEayw=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=udPJc00fSbUm7T85/4PS2xOLAC1uIesfLqVu39pa+mXKIwn4zG5hBdWqrPVLjhTQZ 9pfcmZ9/oncDcwXVD7XvekAJZ62T0RF3B0Pr3vIx38h+bT5eo4GBmFYxKysn073mBv mFUjlgw0K9/b+Q0KLtwfLTkSejfYWNiuUEG4WDtw= To: "Neal H. Walfield" From: Bart Butler Cc: Daniel Kahn Gillmor , "openpgp@ietf.org" Reply-To: Bart Butler Message-ID: In-Reply-To: <87pnqchcio.wl-neal@walfield.org> References: <0092256D-94EB-4FE5-9560-FEB0B8E3769E@icloud.com> <20190323170723.GC1497@zeromail.org> <87imw9jl2t.fsf@fifthhorseman.net> <20190324162058.GA1238@zeromail.org> <87o95yujj0.fsf@wheatstone.g10code.de> <87imw5haya.fsf@fifthhorseman.net> <87d0mdtj10.fsf@wheatstone.g10code.de> <87pnqchcio.wl-neal@walfield.org> Feedback-ID: XShtE-_o2KLy9dSshc6ANALRnvTQ9U24aqXW2ympbGschdpHbU6GYCTUCtfmGhY9HmOyP1Uweyandwh1AVDFrQ==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="---------------------a018d07863f6fcf56640a8a320cb62de"; charset=UTF-8 Archived-At: Subject: Re: [openpgp] 4880bis status X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2019 17:12:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------a018d07863f6fcf56640a8a320cb62de Content-Type: multipart/mixed;boundary=---------------------1bfbcc6925afff42402d0ab155f3b147 -----------------------1bfbcc6925afff42402d0ab155f3b147 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain;charset=utf-8 I would agree with Werner that it's essentially done, with minor tweaks be= ing the only thing really remaining. That said, I'd say limiting the maximum AEAD chunk size would be classifie= d under 'minor tweak' in my book. -Bart =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original M= essage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Wednesday, March 27, 2019 2:50 AM, Neal H. Walfield = wrote: > Hi, > = > Werner wrote on gnupg-devel@gnupg.org that he views 4880bis as done, > and the recent proposals as "severe last minute changes". > = > Is there general consensus that 4880bis is done? > = > Is further discussion of the changes to 4880bis no longer desired? > = > Are new proposals no longer desired? > = > Thanks! > = > Neal > = > On Tue, 26 Mar 2019 22:36:43 +0100, > Werner Koch wrote: > = > > Those folks who are trying to get severe > > last minute changes into a revision of a standard may be better off to > > start their protocol from scratch. > = > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp -----------------------1bfbcc6925afff42402d0ab155f3b147-- -----------------------a018d07863f6fcf56640a8a320cb62de Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail Comment: https://protonmail.com wl4EARYKAAYFAlyfo1IACgkQmQVEZe8zHkTfkgEA/XNDLB91gKboXT5GUfMm V6Rwpb0gIutIPuYcjsMrVO4BAKC0VPurXRlcQeQ6/1CDa1i5nznGDDYw2nrp zH/IDakK =zr7Z -----END PGP SIGNATURE----- -----------------------a018d07863f6fcf56640a8a320cb62de-- From nobody Sat Mar 30 14:17:01 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1361202A7 for ; Sat, 30 Mar 2019 14:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 OG1X8Q74JcUL for ; Sat, 30 Mar 2019 14:16:57 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 4537412027B for ; Sat, 30 Mar 2019 14:16:57 -0700 (PDT) Received: from p57b22663.dip0.t-ipconnect.de ([87.178.38.99] helo=chu.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1hALLL-0004UA-CS; Sat, 30 Mar 2019 21:16:47 +0000 Date: Sat, 30 Mar 2019 22:16:46 +0100 Message-ID: <87k1gg12rl.wl-neal@walfield.org> From: "Neal H. Walfield" To: Benjamin Kaduk Cc: Bart Butler , "openpgp@ietf.org" , Peter Gutmann , Justus Winter , Jon Callas , Jon Callas In-Reply-To: <20190330150438.GS35679@kduck.mit.edu> References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <87d0m9hl62.wl-neal@walfield.org> <2di2bK8m-7HtDeoUEH9oPqs-bL-IKSE0CjkgFShPMLOlUyeDBVkVGApdjnIpS6YRAeKU3ibGCZCtwLden-N6zK5W4fqIghRGDa5dU720nEs=@protonmail.com> <20190330150438.GS35679@kduck.mit.edu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2019 21:16:59 -0000 Hi Ben, Thanks for your note. At Sat, 30 Mar 2019 10:04:38 -0500, Benjamin Kaduk wrote: > I also have a use case for authentication of large chunks of data at rest: > they allow me to use a cheap bulk storage service that provides > (best-effort) replication and archiving but has poor physical security. So > I encrypt my data to myself and put it in storage, but when I get it back > I need to know that it's valid. I can imagine at least one case where > knowing exactly which chunk was corrupted would save effort; it may be a > toy example but perhaps it is illustrative of a broader case. Note that > there are algorithms to compute pi to arbitrary precision, and even to > compute the Nth digit thereof without coputing the previous digits. If I > need to have random-access inquiries into the value of pi, I could > precompute using softare I trust and do this self-encryption thing, and > when a chunk is bad I can recompute only that chunk and still trust that I > only ever use values generated by my trusted implementation. Just to be clear: when you say "large chunks of data at rest," you're not arguing that large AEAD chunks are better, are you? It seems to me that if you use small chunks, at least in your example, you have less work to do when you discover a corrupted chunk. Thanks, :) Neal From nobody Sat Mar 30 16:09:47 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CACC1200A3 for ; Sat, 30 Mar 2019 16:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com 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 94ehAPzJhqAg for ; Sat, 30 Mar 2019 16:09:43 -0700 (PDT) Received: from mr85p00im-ztdg06021701.me.com (mr85p00im-ztdg06021701.me.com [17.58.23.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C08FB1202D2 for ; Sat, 30 Mar 2019 16:09:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1553987382; bh=2DgOgL+N2p43kJDThxc//ziPwrYMvUOzN4bulexNsdA=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=Rr1ybGr4XtYpEUPtTbhrrCFslkpvjIU0yvYTLPTFmbZ2QY94rFVm6XrFUWCL+71pk 1BwQnHtmdQAyFM2XvHmLOn96xZzU2Vqv3wefAreCH4ImUaCoLB1dWY+/l7vVBmHj0X EKL0aJxxLQdfBOJHzc2JANVnu5WfyX2v3wheu+uWq/0N3kiu3EQi+52VO1B6VrfEe5 DfkwBNWPvPkDnzGRPbp5xSTCrKMY3S1/QWQT+04afqJ/ONMlA7tmVcKy8uKyVM/xs/ c+Xe2jOBtEKRqWpurgmxcU/Z9QiMHzYxyMPtGP+vCEEWiGNALr9vZGGsLsDeU323jW 5Rtb7nlnEg79Q== Received: from [192.168.7.69] (thing1.merrymeet.com [173.164.244.99]) by mr85p00im-ztdg06021701.me.com (Postfix) with ESMTPSA id A3E07A0000B; Sat, 30 Mar 2019 23:09:42 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Jon Callas In-Reply-To: <2di2bK8m-7HtDeoUEH9oPqs-bL-IKSE0CjkgFShPMLOlUyeDBVkVGApdjnIpS6YRAeKU3ibGCZCtwLden-N6zK5W4fqIghRGDa5dU720nEs=@protonmail.com> Date: Sat, 30 Mar 2019 16:09:41 -0700 Cc: Jon Callas , "Neal H. Walfield" , "openpgp@ietf.org" , Justus Winter , Peter Gutmann Content-Transfer-Encoding: quoted-printable Message-Id: <73739F8A-5E9F-4277-B053-FDD2E8D81B17@icloud.com> References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <87d0m9hl62.wl-neal@walfield.org> <2di2bK8m-7HtDeoUEH9oPqs-bL-IKSE0CjkgFShPMLOlUyeDBVkVGApdjnIpS6YRAeKU3ibGCZCtwLden-N6zK5W4fqIghRGDa5dU720nEs=@protonmail.com> To: Bart Butler X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-30_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1903300170 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2019 23:09:46 -0000 > On Mar 29, 2019, at 7:17 PM, Bart Butler = wrote: >=20 > Hi Jon, >=20 > As others have noted, there is a lot of confusion on this thread, some = of which you touched in your AEAD Conundrum message, like when we say = AEAD should not release unauthenticated plaintext, do we mean the entire = message or the chunk? That is precisely the question. But the bigger question is whether you = care about that. Sometimes it matters, sometimes it does not. For example, let=E2=80=99s suppose that I have a very large blob on mass = storage. Media failures happen. If there=E2=80=99s a bad block on a = disk, do you want to lose the whole file because of it? Sometimes you = want to throw your hands up in the air. This is most common in an = interactive protocol, and in general the answer is yes. For example, an = SSL connection to a server, if there=E2=80=99s funny business going on, = you want to blow up the connection and try over again. On the other = hand, if you had an archival thing (e.g. tar file with some historic = documents), you want to recover as much as you can. OpenPGP is in general the latter case rather than the former. I believe = it=E2=80=99s less important to have strict semantics on failures because = it=E2=80=99s usually storage. >=20 > Another piece of confusion is that Efail isn't a single vulnerability, = it was several vulnerabilities related (at best) thematically. I understand Efail. Trust me. >=20 > So to be very specific, for the purpose of the following discussion, = the advantage of smaller AEAD chunks is specifically to prevent = Efail-style ciphertext malleability/gadget attacks, and the prohibition = on releasing unauthenticated plaintext is applied to individual chunks, = which is sufficient to foil this kind of attack in email. I disagree. If you want to prevent something like Efail, you want larger = chunks. Assuming that you believe that early release matters.=20 Let=E2=80=99s rewind here, and not talk about Efail, let=E2=80=99s talk = about the real issue. If you want the entire blob to have all-or-nothing = semantics, then you want the fewest number of chunks as is reasonable. = If you have attacker-controlled inputs, then every joint between the = chunks is a vulnerability. >=20 > The kind of attack we are talking about is fundamentally about = exfiltration of plaintext data to an attacker-controlled endpoint. = Borrowing from your AEAD Conundrum message, if the first chunk passes = and is released, and the second chunk fails, that is OK, at least for = email, because the part that was modified (the second chunk) is never = released, so you get a truncated message and an error, but the truncated = message without the modifications isn't going to exfiltrate itself. I agree with this.=20 >=20 > Now if releasing ANY authenticated chunk of a message that hasn't been = fully authenticated (in an AEAD sense) is a real problem for your = application, I'd argue that you're trying to make AEAD do something it's = not suited for and you should enforce this in your application if it = applies to you, probably by not streaming. >=20 > So to recap, small-chunk AEAD provides specific value in preventing = ciphertext malleability/gadget attacks, particularly in HTML email, = which is a common use case. Also agree 100%. This is why a long time ago, I said that Efail is orthogonal to the = chunking issue. Either way, large or small, you end up in the same place = of not being hacked. >=20 > What value does large-chunk AEAD actually provide? What I'm getting = from the AEAD Conundrum message is that it's a way for the message = encrypter to leverage the "don't release unauthenticated chunks" = prohibition to force the decrypter to decrypt the whole message before = releasing anything. Why do we want to give the message creator this kind = of power? Why should the message creator be given the choice to force = her recipient to either decrypt the entire message before release or be = less safe than she would have been with smaller chunks? Let me summarize the conundrum: If you want strict AEAD no-release = semantics, you want a fewer number of chunks.=20 >=20 > Coming back to Neal's point, it's really hard to see any sort of value = in really large AEAD chunks, because the performance overhead is = negligible at that point and the only security 'benefit' that I can see = is the encrypter trying to use the spec to force the decrypter to not = stream, which does not seem like something at all desirable. Okay, here=E2=80=99s another thing that=E2=80=99s a pet peeve of mine. = We=E2=80=99re arguing security and you brought up performance. I never = mentioned performance, the people who want large chunks haven=E2=80=99t = brought it up. They want large chunks because they perceive it to be = more secure.=20 If you respond to a security request with a performance answer, you = literally don=E2=80=99t know what you=E2=80=99re talking about. So = let=E2=80=99s toss that aside. Bigger chunks *are* more secure. Does that security matter? Well, it = does to the people who want big chunks. >=20 > -Bart >=20 > P.S. ProtonMail doesn't use V5 keys or the new draft yet, but some = users of OpenPGP.js have started using them with 256kB chunks, so we are = not arguing on behalf of ourselves for the 256kB chunk size. The = proposed language seems more or less OK in this regard, as most = implementations will presumably keep 256kB support so these early = adopters will not lose interoperability with their messages. I am going to rewind again, back to the proposal I made. Here it is, so = we can look at it.=20 * MUST support 16KB chunks. * SHOULD support 256K chunks, as these are common (Protonmail). * MAY support larger up to the present very large size. * MAY reject or error out on chunks larger than 16KB, but repeating = ourselves, SHOULD support 256K. Elided out of this, and possibly important is that =E2=80=9Csupport=E2=80=9D= includes chunks smaller than that size. I should have said that, but I = wanted it to be as stark as possible. So let me repeat it and abstract = it with some variables: (1) MUST support up to chunks. (2) SHOULD support up to chunks, as these are = common. (3) MAY support larger up to the present very large size. (4) MAY reject or error out on chunks larger than , = but repeating ourselves, SHOULD support . Clauses (3) and (4) set up a sandbox for the people who want very large = chunks. They can do whatever they want, and the rest of us can ignore = them. Why get rid of that? It doesn=E2=80=99t add any complexity to the = code. It lets the people who want the huge ones do them in their own = environment and not bother other people. My concern is over (1) and (2) and specifically that there=E2=80=99s = both and sizes.=20 I think that=E2=80=99s an issue. If there are two numbers we are apt to = end up with skew before settling on one, so it=E2=80=99s better to agree = on just one. That=E2=80=99s the real wart in my proposal. Neal said he=E2=80=99s fine with 256K. We could do that. 16K has also = been suggested (I think Neal said it=E2=80=99s his preference). My = intuition is that whatever GnuPG is using for partial body lengths is = also a good option as we know that that=E2=80=99s reasonable for both = performance and everything else, and my preference is that it be as = small as possible to support the smallest footprint possible. I spent = about ten minutes looking for the answer and I think it=E2=80=99s 8K, = but I=E2=80=99m not sure. Someone correct me if that=E2=80=99s not it. = Whatever it is, that=E2=80=99s what I=E2=80=99d do, but I=E2=80=99m not = an implementer. Opinions on what a single number should be? 256? 16? 8? Something else? Jon From nobody Sat Mar 30 19:58:53 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83DA12010E for ; Sat, 30 Mar 2019 19:58:51 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 YMwSuTIB3KY7 for ; Sat, 30 Mar 2019 19:58:49 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B222A1200FC for ; Sat, 30 Mar 2019 19:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1554001128; x=1585537128; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=to1ZpGPE2F2AqG2vCTaadxsjXTkY4p7meNDKCAVz7s4=; b=nVpAftJlzmexF+7X3kCl3mXgQQx5ImIKvOmtneXGAJFsWXs4jtE1CkaY I1GiBjoDLiqqZLVtny8nazvk6/ILl+ldMwUNN69CPOEuJ6dSUJq3vDPKk yZ6yZObHnsVWfE7uG9v0YeZACX2dgBWWMiKbAu1f0jYbyPN/JIqd0Ay9R H6GjR2J/2mNkERN1MJ75rpljBq4pSgobKksnT/md/0uIwtk3bSXIlWAnr DF4Xe+izHiitYvnj1g35f1BWA978ayr4TBfXeaEHX1ninWGGbv74zxFcC obmZqPN1EoBCT1EKa7i79Qjmr9T2B7wc9iHURy/xmr5b0KZi++CuZVWsH g==; X-IronPort-AV: E=Sophos;i="5.60,291,1549882800"; d="scan'208";a="53772000" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.4 - Outgoing - Outgoing Received: from uxcn13-ogg-c.uoa.auckland.ac.nz ([10.6.2.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 31 Mar 2019 15:58:44 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-c.UoA.auckland.ac.nz (10.6.2.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 31 Mar 2019 15:58:44 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Sun, 31 Mar 2019 15:58:44 +1300 From: Peter Gutmann To: Jon Callas , "Neal H. Walfield" CC: "openpgp@ietf.org" , Justus Winter , Jon Callas Thread-Topic: [openpgp] AEAD Chunk Size Thread-Index: AQHU5WH/TXThz2b5WUWEfgPFCGcCuqYgtWOAgAAKeQCAATDsKP//jKeAgAEUouf//y2OgIAA4CBQ//81WQAADPwVgABaU8HW Date: Sun, 31 Mar 2019 02:58:44 +0000 Message-ID: <1554001112803.75759@cs.auckland.ac.nz> References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <87zhpd21d3.wl-neal@walfield.org>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 02:58:52 -0000 Jon Callas writes:=0A= =0A= >I think that if Peter wanted to remove AEAD, he=92d just say that.=0A= =0A= I'm not saying remove it, just get some data to support making a decision i= n=0A= some way. In particular, AEAD is a good thing, but there's no evidence tha= t=0A= chunking with AEAD, which complicates things greatly, is useful or necessar= y.=0A= =0A= Here's three actual real-world data points: =0A= =0A= For the last twenty-eight years, PGP has had functionality equivalent to AE= AD=0A= in the form of encrypt+sign. The only mechanism this supported was chunk-= =0A= size =3D data-size, and in twenty-eight years this never seems to have=0A= caused/been seen as a problem. =0A= =0A= If you don't think encrypt+sign is equivalent functionality then we've also= =0A= had pseudo-AEAD in the form of MDC for eighteen years (draft-ietf-openpgp-= =0A= rfc2440bis-02) and chunking wasn't an issue then either.=0A= =0A= Finally, CMS has had this for more than a decade (Authenticated-Enveloped-= =0A= Data) and it's not been a problem there either.=0A= =0A= Why is it suddenly a big deal now, and only with OpenPGP, after twenty-eigh= t=0A= or eighteen years (depending on which one you choose) of equivalent mechani= sms=0A= not being a problem? Is this because it really is, or just because AEAD ca= n=0A= do all sorts of cool things and people want to play with them?=0A= =0A= Peter.=0A= From nobody Sat Mar 30 21:11:38 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E98120135 for ; Sat, 30 Mar 2019 21:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com 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 LVR6eqWZCoIP for ; Sat, 30 Mar 2019 21:11:31 -0700 (PDT) Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFC681200F5 for ; Sat, 30 Mar 2019 21:11:30 -0700 (PDT) Date: Sun, 31 Mar 2019 04:11:25 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1554005487; bh=UQWIOpsRyE0VVpRQ8KMe0DCN/ExWYHPRqaJB1PLyGOE=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=ZxujAmH8rGCwlFPmLQy9neuRvVwNYW3qTdDHU6EVFggcr8RMCKMxD4QMzEJjFY9r8 O5NJhDBeE9nK6+AfSjjxXk2/lF+J9MGmQwYFkNx34mDVf8Qqcv43CbeRx8HJyHYi2O Trm+nGGb7X6kF72HzyoXY2/gfa1+3iqBJTtD3UTI= To: Jon Callas From: Bart Butler Cc: "Neal H. Walfield" , "openpgp@ietf.org" , Justus Winter , Peter Gutmann Reply-To: Bart Butler Message-ID: In-Reply-To: <73739F8A-5E9F-4277-B053-FDD2E8D81B17@icloud.com> References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <87d0m9hl62.wl-neal@walfield.org> <2di2bK8m-7HtDeoUEH9oPqs-bL-IKSE0CjkgFShPMLOlUyeDBVkVGApdjnIpS6YRAeKU3ibGCZCtwLden-N6zK5W4fqIghRGDa5dU720nEs=@protonmail.com> <73739F8A-5E9F-4277-B053-FDD2E8D81B17@icloud.com> Feedback-ID: XShtE-_o2KLy9dSshc6ANALRnvTQ9U24aqXW2ympbGschdpHbU6GYCTUCtfmGhY9HmOyP1Uweyandwh1AVDFrQ==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="---------------------ccbb5d08964dba2b48d24756f2cc56f7"; charset=UTF-8 Archived-At: Subject: Re: [openpgp] AEAD Chunk Size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 04:11:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------ccbb5d08964dba2b48d24756f2cc56f7 Content-Type: multipart/mixed;boundary=---------------------7eb5675f1245e295c6cd1e2a207be1ba -----------------------7eb5675f1245e295c6cd1e2a207be1ba Content-Transfer-Encoding: quoted-printable Content-Type: text/plain;charset=utf-8 =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original M= essage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Saturday, March 30, 2019 4:09 PM, Jon Callas wro= te: > = > = > > On Mar 29, 2019, at 7:17 PM, Bart Butler bartbutler=3D40protonmail.com= @dmarc.ietf.org wrote: > > Hi Jon, > > As others have noted, there is a lot of confusion on this thread, some= of which you touched in your AEAD Conundrum message, like when we say AEA= D should not release unauthenticated plaintext, do we mean the entire mess= age or the chunk? > = > That is precisely the question. But the bigger question is whether you c= are about that. Sometimes it matters, sometimes it does not. > = > For example, let=E2=80=99s suppose that I have a very large blob on mass= storage. Media failures happen. If there=E2=80=99s a bad block on a disk,= do you want to lose the whole file because of it? Sometimes you want to t= hrow your hands up in the air. This is most common in an interactive proto= col, and in general the answer is yes. For example, an SSL connection to a= server, if there=E2=80=99s funny business going on, you want to blow up t= he connection and try over again. On the other hand, if you had an archiva= l thing (e.g. tar file with some historic documents), you want to recover = as much as you can. > = > OpenPGP is in general the latter case rather than the former. I believe = it=E2=80=99s less important to have strict semantics on failures because i= t=E2=80=99s usually storage. > = I agree. I would say my point is that with sufficiently small chunks, the = user/decrypter can choose what kind of failure behavior is appropriate. La= rge chunks robs the decrypter of that. > > Another piece of confusion is that Efail isn't a single vulnerability,= it was several vulnerabilities related (at best) thematically. > = > I understand Efail. Trust me. I do. I was bit excessively pedantic defining everything because I felt th= at this thread has suffered from ambiguity in several terms. > = > > So to be very specific, for the purpose of the following discussion, t= he advantage of smaller AEAD chunks is specifically to prevent Efail-style= ciphertext malleability/gadget attacks, and the prohibition on releasing = unauthenticated plaintext is applied to individual chunks, which is suffic= ient to foil this kind of attack in email. > = > I disagree. If you want to prevent something like Efail, you want larger= chunks. Assuming that you believe that early release matters. > = > Let=E2=80=99s rewind here, and not talk about Efail, let=E2=80=99s talk = about the real issue. If you want the entire blob to have all-or-nothing s= emantics, then you want the fewest number of chunks as is reasonable. If y= ou have attacker-controlled inputs, then every joint between the chunks is= a vulnerability. OK, I think this is the part that I don't understand. Why does it matter w= hat chunking scheme is used here? If my app requires all-or-nothing semant= ics, I would program my app to enforce that all chunks must pass and not r= elease plaintext unless that happened, with no truncation, etc. So why wou= ld every joint be a vulnerability? > > What value does large-chunk AEAD actually provide? What I'm getting fr= om the AEAD Conundrum message is that it's a way for the message encrypter= to leverage the "don't release unauthenticated chunks" prohibition to for= ce the decrypter to decrypt the whole message before releasing anything. W= hy do we want to give the message creator this kind of power? Why should t= he message creator be given the choice to force her recipient to either de= crypt the entire message before release or be less safe than she would hav= e been with smaller chunks? > = > Let me summarize the conundrum: If you want strict AEAD no-release seman= tics, you want a fewer number of chunks. I guess this is my fundamental question. You can force no-release semantic= s at the application level for any chunk size scheme, right? > = > > Coming back to Neal's point, it's really hard to see any sort of value= in really large AEAD chunks, because the performance overhead is negligib= le at that point and the only security 'benefit' that I can see is the enc= rypter trying to use the spec to force the decrypter to not stream, which = does not seem like something at all desirable. > = > Okay, here=E2=80=99s another thing that=E2=80=99s a pet peeve of mine. W= e=E2=80=99re arguing security and you brought up performance. I never ment= ioned performance, the people who want large chunks haven=E2=80=99t brough= t it up. They want large chunks because they perceive it to be more secure= . > = > If you respond to a security request with a performance answer, you lite= rally don=E2=80=99t know what you=E2=80=99re talking about. So let=E2=80=99= s toss that aside. I apologize, I was not trying to create a strawman here, but I am complete= ly at a loss for what the benefit of large chunks is. > Elided out of this, and possibly important is that =E2=80=9Csupport=E2= =80=9D includes chunks smaller than that size. I should have said that, = but I wanted it to be as stark as possible. So let me repeat it and abstra= ct it with some variables: > = > (1) MUST support up to chunks. > = > = > (2) SHOULD support up to chunks, as these are common= . > (3) MAY support larger up to the present very large size. > (4) MAY reject or error out on chunks larger than , bu= t repeating ourselves, SHOULD support . > = > Clauses (3) and (4) set up a sandbox for the people who want very large = chunks. They can do whatever they want, and the rest of us can ignore them= . Why get rid of that? It doesn=E2=80=99t add any complexity to the code. = It lets the people who want the huge ones do them in their own environment= and not bother other people. > = > My concern is over (1) and (2) and specifically that there=E2=80=99s bot= h and sizes. > = > I think that=E2=80=99s an issue. If there are two numbers we are apt to = end up with skew before settling on one, so it=E2=80=99s better to agree o= n just one. That=E2=80=99s the real wart in my proposal. > = I'm OK with eliminating (2) and just using the MAY part to take care of an= y legacy 256K messages OpenPGP.js users might have. As I said, we don't ha= ve any of these messages in production yet and I'd err on the side of a cl= eaner spec. I just really want to understand the benefit of large chunks f= or security and right now I clearly do not. -----------------------7eb5675f1245e295c6cd1e2a207be1ba-- -----------------------ccbb5d08964dba2b48d24756f2cc56f7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail Comment: https://protonmail.com wl4EARYKAAYFAlygPewACgkQmQVEZe8zHkRmmQD/S+4dTvbBw00lKFfCUq8h 5LINz+qSkDpau30csMZvPWUA/1l/GyTv6HJptn1ykpPdpywzwvGAOK/DIIK4 enpO3KEP =bMtG -----END PGP SIGNATURE----- -----------------------ccbb5d08964dba2b48d24756f2cc56f7-- From nobody Sun Mar 31 05:10:31 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D9A120116 for ; Sun, 31 Mar 2019 05:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=incenp.org 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 ouh6C9adeY3G for ; Sun, 31 Mar 2019 05:10:27 -0700 (PDT) Received: from mail.incenp.org (mail.incenp.org [51.254.143.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E67B1200C7 for ; Sun, 31 Mar 2019 05:10:27 -0700 (PDT) Received: from localhost (dgouttegattat.plus.com [81.174.245.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.incenp.org (Postfix) with ESMTPSA id ACB77200C1 for ; Sun, 31 Mar 2019 14:10:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=incenp.org; s=201812; t=1554034224; bh=tbMHiZ/52Rijw8w2iQQjpFnT1TynF5qo7uNGrWyk9M0=; h=Date:From:To:Subject; b=CqBCpwVktFs39OQ6XZ8IK+t9kXFKskt7TvWAejLqS7Gtjk8iPOGKp6D8vLonBnd9G BsSOnihiwGLbA5nEFKk7VmNqknNwf/15YY/sy5k/PT4dE3xG+jgJwt3BU1AAWo41A2 F7uT0V1fEt6X9aEQbdV55oyyP8tfW609eQAbW9eU= Date: Sun, 31 Mar 2019 13:10:24 +0100 From: Damien Goutte-Gattat To: openpgp@ietf.org Message-ID: <20190331121024.cgta3emx6vefex6x@aurora.local.incenp.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sercrgw6vd6k6mjt" Content-Disposition: inline OpenPGP: id=4FA2082362FE73AD03B88830A8DC7067E25FBABB; url=https://incenp.org/srv/dgouttegattat.asc; preference=signencrypt User-Agent: NeoMutt/20180716 Archived-At: Subject: [openpgp] New S2K specifiers? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 12:10:30 -0000 --sercrgw6vd6k6mjt Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, Around the time the OpenPGP WG was re-chartered in 2015, one of the changes considered for the RFC4880bis was to update the list of "string-to-key" (S2K) specifiers by adding =E2=80=9Csomething more modern=E2=80=9D [1] such as PBKDF2 or the winner of the (at the time unfinished) PHC competition. Nils Durner proposed a patch reserving the S2K type 4 for Argon2i and describing its use [2]. This patch has not made it to the current draft but I don=E2=80=99t recall seeing the proposal explicitly rejected. On the contrary, at the times it seems to have generated a genuine interest. I personally have no strong opinion as to whether new S2K specifiers should be added to RFC4880bis. But since there was a proposal to add Argon2i, I would like to be sure that if that algorithm does not make it to the final draft, it is because there was no consensus to include it (or because there was a consensus *against* its inclusion), and not simply because the proposal was overlooked. So: * Is there any interest for a =E2=80=9Cmore modern=E2=80=9D S2K, or is the Iterated+Salted S2K still considered fine enough for RFC4880bis? * If we want a more modern S2K, then is Argon2i the right choice? * If we want Argon2i, is there any issue with Nils Durner=E2=80=99s proposal? As I recall, the only issue that was raised at the time was the fact that Argon2i was not described in a RFC. There is now a draft for it [3], so I don=E2=80=99t think this is an issue anymore. Cheers, - Damien [1] https://mailarchive.ietf.org/arch/msg/openpgp/ll36RGS81vXSXkVey0cR0zZ7W= kI [2] https://mailarchive.ietf.org/arch/msg/openpgp/IORjkQR17EURj9HQaKCqoQ2TK= kI [3] https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/ --sercrgw6vd6k6mjt Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHQEABYIAB0WIQSAzBuNBMJi3f7hmAxvfw+R0Tj8ewUCXKCuLAAKCRBvfw+R0Tj8 e0o3AP9CkGv+AICltqip6ih9gwbswu3JlWg0vRal5xUk+w1liwD3Txn9LlRabafv K4nkQU61/xN+mgkWRQO43bnf3baeAA== =L+aA -----END PGP SIGNATURE----- --sercrgw6vd6k6mjt-- From nobody Sun Mar 31 05:16:35 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CFF12012B for ; Sun, 31 Mar 2019 05:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com 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 6STPiZZfu2gu for ; Sun, 31 Mar 2019 05:16:31 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 4AB221200C7 for ; Sun, 31 Mar 2019 05:16:31 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id b7so4299368lfg.9 for ; Sun, 31 Mar 2019 05:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NzIJ5OfhlhPua/3b9ijNvulD22U/2EpExSmV+S6ku3A=; b=LfHkgDwI1yUZ9OMVvct3RcUiyKvB//oQ7oUNG4704inQ+L9pypsckSF516V61EagaS IRUEfrxUbt8jL+aOO2AQEOGkCPCezuwLonZd3MVi6BlZmERCo4FUjgcSfnartfx/LIM3 a3BQ5K62oOJQCowyEsCtJ1kNFWRjlQ6cjG3Bl4AbBGN+GN2fx9suPX5SUSZ6vwlY1Wji MtZeQNRLOZAGEcrt4I57Pj65spUYs0ZdNZz4tPdLWes+MqpXOxlI/fU0xMogQcNNJyCL yxhQr7ZjVLN/2BbGg2tQUpgIBUJJ7xxfUP827enCq8mHxMUKiHzvmnCmdrHWghzmNkru zWIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NzIJ5OfhlhPua/3b9ijNvulD22U/2EpExSmV+S6ku3A=; b=VfqgCR/ZZrVJa661XwEjVyeqd9rfOw/WBxmAhDtHVywir0IITB68BI9Gw6o8Erf6WT i3AcKS4XgtrouoPgDxyXMtl/Y0noqrdh4pY23dfSkFNV2AMppJtaIWuNWFMydaBZCMtn F13mku41FWbjcNjZZOE8/dz1hb+WRIxf8430QXZsb8c7hxNcrKICSAJVf/AZ7gcXsuJd sKd7a9di9qJIv09LlfwIdFc8BROMF5ildVwC2oa8nM2pgZGxKTSe8jLlxDlfA6yBe0JB zEHt3ysgki4+aiiJXsLBI8CscBT6+cB3MUk1JnvOSUtvNICYXrbHGh6ayRMoTV07GAzC z1/Q== X-Gm-Message-State: APjAAAVGpvzIMNFLx80ik1Rcy2yM5nMPhmp3gPslvV+RcKMYI79J6a2Y 8PgvAoEe7NAmzSwbcsoOgsP2ZhsqX7+HP1p9SJI= X-Google-Smtp-Source: APXvYqxkOq9JM+ulhl4Pgp1nomVuCKYLUCL7kdOcSkaHfV1Rvt/9kKKqg5pY5G8GbvGXhsLx/4pFRlyYQnc99nuDriQ= X-Received: by 2002:a19:c204:: with SMTP id l4mr29433296lfc.143.1554034589205; Sun, 31 Mar 2019 05:16:29 -0700 (PDT) MIME-Version: 1.0 References: <20190331121024.cgta3emx6vefex6x@aurora.local.incenp.org> In-Reply-To: <20190331121024.cgta3emx6vefex6x@aurora.local.incenp.org> From: Nils Durner Date: Sun, 31 Mar 2019 14:16:18 +0200 Message-ID: To: Damien Goutte-Gattat Cc: openpgp@ietf.org Content-Type: multipart/alternative; boundary="000000000000a88ae5058562df6f" Archived-At: Subject: Re: [openpgp] New S2K specifiers? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 12:16:33 -0000 --000000000000a88ae5058562df6f Content-Type: text/plain; charset="UTF-8" Hi Damien, thanks for bringing this up! I would also like to see it included in the standard, but have no immediate application that would use it. If there is general interest, however, I would be happy to work on getting it included. The last comments I have gotten have not been included in my patch. So... is there general interest? What's the best way to proceed? Best regards, Nils --000000000000a88ae5058562df6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Damien,

thanks for bringing this up!=

I would also like to see it included in the stand= ard, but have no immediate application that would use it. If there is gener= al interest, however, I would be happy to work on getting it included. The = last comments I have gotten have not been included in my patch.
<= br>
So... is there general interest? What's the best way to p= roceed?

Best regards,

Nil= s
--000000000000a88ae5058562df6f-- From nobody Sun Mar 31 21:02:33 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D316C120005 for ; Sun, 31 Mar 2019 21:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=+iZ3cUMQ; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=kjpaMTww 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 qjz-nYky9G9b for ; Sun, 31 Mar 2019 21:02:29 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B555120059 for ; Sun, 31 Mar 2019 21:02:28 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1554091347; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=TE6rVOB5quRoucIMerrgcv9s1u65tfaujCpHGPtngEQ=; b=+iZ3cUMQKa6f3kmbkgG+oGnvf1BZAt1ydIOqvGfwT1K9Ld+WSU43C61r yr+35gyw/VrmktoIKetif4Md8e/6Ag== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1554091346; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=TE6rVOB5quRoucIMerrgcv9s1u65tfaujCpHGPtngEQ=; b=kjpaMTwwATFbZIDkmA39LJluMqj2scDvPqWwDRp6FupCVYd0D9Di/vH1 Y8yXvophzWSzQRC0K+/nrtRjHOWlkBML/OMuXpnaJ+vZuW/uDQGLH7eTmb XburU9w7x8McrBxHlr2czKiyElxuNSbDt67AwqUak2oLJVW1Ihuo8gvVz7 DvaLEmImHIAjmJzplk9B9sammW7yOCteHuINAOZ2kBVyfR4eKxbxl3dL3c IFaZY23fYLU0Pv18kjUxy+WZAr3qqnCBbhjfa/1u2ptpAYhe/6fPb6A+LD /10uhj6fxj+41oVR05V80KOweNhEN2OnxhXoZVXD8h3pNN5SHH+/xw== Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 42A67F9A4; Mon, 1 Apr 2019 00:02:26 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 3D91E20F99; Sun, 31 Mar 2019 19:22:48 -0400 (EDT) From: Daniel Kahn Gillmor To: Wiktor Kwapisiewicz , Werner Koch Cc: openpgp@ietf.org In-Reply-To: <02531d3b-c743-6c34-f93b-0bd7a087aa5c@metacode.biz> References: <02531d3b-c743-6c34-f93b-0bd7a087aa5c@metacode.biz> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Sun, 31 Mar 2019 19:22:47 -0400 Message-ID: <87y34uaat4.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Web Key Directory and CORS X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 04:02:31 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon 2019-03-25 22:08:30 +0100, Wiktor Kwapisiewicz wrote: > And the wording may be something like: "It is RECOMMENDED that the key=20 > is returned with 'Access-Control-Allow-Origin' HTTP header set to value=20 > '*'". I think this is potentially dangerous if it is done on the main domain (e.g. at "example.net", instead of the "advanced" form at "openpgpkey.example.net"), because the main domain for any given site might have resources where this CORS header would be inappropriate. Assuming that the "advanced" domain "openpgp.example.net" is used, and the document tree published there is limited to WKD, then i agree that such a CORS statement seems safe, though. I don't know CORS well enough to know how to properly constrain such a header, but if we do add guidance, i'd want to make sure it is narrowly scoped so that an administrator deploying WKD doesn't accidentally open up the rest of the site's data to external cross-origin requests. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXKFLxwAKCRB2GBllKa5f +IX7APwOWfcosOoC6A5kHAqQ4SUAVRAwjuN4IKLWbEwkYqYSqwD+M+gYGJv9yw0f qVx9JZBO3e21G+jLkCqYWPdLywo7FwY= =sYMa -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Mar 31 21:02:48 2019 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF2D7120005 for ; Sun, 31 Mar 2019 21:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.458 X-Spam-Level: X-Spam-Status: No, score=-0.458 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=gdLoa06f; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=FQiwDJjL 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 xjB0XflGRf_C for ; Sun, 31 Mar 2019 21:02:30 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E045120072 for ; Sun, 31 Mar 2019 21:02:29 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1554091348; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : content-transfer-encoding : from; bh=kRpwJ2GuCK2JDmGQCg9C/UX61iG+ltiBFCerfw2/Xug=; b=gdLoa06fHLzFxwbP+y3ACuuP/2nlu5GbnxrAQQx3jelKyzb7HERUUS0Q PMU9kyf39VordFUrl4xieTvQr5n7CA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1554091348; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : content-transfer-encoding : from; bh=kRpwJ2GuCK2JDmGQCg9C/UX61iG+ltiBFCerfw2/Xug=; b=FQiwDJjLJcAPwQQ+kwnP4ENMLM6Pt3kvlhEpNBfLjV7iWf62z6kYODYd YpNmkmaN2xcvl5GMlgWXffvk2dt6f8+V/O3w3UVaFhKEFotkPjCKHTSXzH KBGD+8sS37en1oXZ13Mog4KAvkMuym2xA0Y6mD0/VDueTwy/ui2yn9YdHf Ekc270185C8XdO/oTddf8+dttsGDWO2dEIc52LENq4EvLFRZwrnI+Z5+zw PpgAX6R1iosmPf5ZNxNBnNj1H0j5zVfO9Bf3/GjsO0MnE04AygOgipXmpl mB+QgSFxsjpGDcxFRJm3wFiOgYlD0n0q3hU0QzlFUQ8Eomju8N2+yg== Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 17244F9A7 for ; Mon, 1 Apr 2019 00:02:28 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id A67E920BEA; Sun, 31 Mar 2019 17:37:07 -0400 (EDT) From: Daniel Kahn Gillmor To: openpgp@ietf.org In-Reply-To: <20190331121024.cgta3emx6vefex6x@aurora.local.incenp.org> References: <20190331121024.cgta3emx6vefex6x@aurora.local.incenp.org> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Sun, 31 Mar 2019 17:37:07 -0400 Message-ID: <87k1gebu9o.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [openpgp] New S2K specifiers? X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 04:02:32 -0000 On Sun 2019-03-31 13:10:24 +0100, Damien Goutte-Gattat wrote: > * Is there any interest for a “more modern” S2K, or is the > Iterated+Salted S2K still considered fine enough for RFC4880bis? I think having argon2i included in rfc4880bis would be concretely useful; iterated+salted hasn't been the best practice for S2K for well over a decade. The main argument i can imagine against it is if no OpenPGP implementation has any plans or desire to implement it, or if there are specific objections related to IPR. I would like to hear from people who think rfc4880bis should not include a winner of the PHC, if the goal is a cryptographic refresh. --dkg