From nobody Sun Jul 1 06:39:26 2018 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 762D612785F for ; Sun, 1 Jul 2018 06:39:25 -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 KHVOe3n72FGQ for ; Sun, 1 Jul 2018 06:39:23 -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 EE3861277CC for ; Sun, 1 Jul 2018 06:39:22 -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 41JWhC258nz4yGS for ; Sun, 1 Jul 2018 15:39:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ruhr-uni-bochum.de; s=mail-2017; t=1530452363; bh=jKHjj9D4ElCdPLoeyJDUaLM4EUt/1SJf4PpvWFGJ7ac=; h=Subject:To:References:From:Date:In-Reply-To:From; b=mqY/ZQGwieehGRIXSWTyd16GjxPctuTxbHRTs+2m2C1Z/uYEgOj7OnuDTYq5SvIyQ ra8Vamj1yqOY8Jzqoart+7Jj9uj5cFOaIOKZqP2L0lanzqEA831WTaPjw4d/Yz4Lk8 YObp2XOSnC1vsreIw6yWMdd4DLukvj2Nzd3Qp3JY= 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 41JWhC1KsSz4yH6 for ; Sun, 1 Jul 2018 15:39:23 +0200 (CEST) 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 41JWhC14mwz4yGS for ; Sun, 1 Jul 2018 15:39:22 +0200 (CEST) Received: from [192.168.142.139] (p5B04976F.dip0.t-ipconnect.de [91.4.151.111]) by mail1.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 41JWgq3sSbzynK for ; Sun, 1 Jul 2018 15:39:03 +0200 (CEST) To: openpgp@ietf.org References: <1530428015814.83795@cs.auckland.ac.nz> From: Marcus Brinkmann Openpgp: preference=signencrypt Message-ID: <7080a271-6244-13d3-04da-d00a32766de1@ruhr-uni-bochum.de> Date: Sun, 1 Jul 2018 15:39:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <1530428015814.83795@cs.auckland.ac.nz> 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 mode unverified chunks X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 13:39:26 -0000 On 07/01/2018 08:53 AM, Peter Gutmann wrote: > Marcus Brinkmann writes: > >> If a chunk can not be authenticated, implementations MUST discard the >> plaintext without further processing. Unauthenticated plaintext MUST not be >> output to other applications or the user. > > Unfortunately it's nowhere near as simple as that, in general, this is an > unsolveable problem. See: > > https://tools.ietf.org/html/rfc6476#section-6 > > for a discussion. Maybe the above wording was not clear. The plaintext in question refers to that of a single chunk. Here is another suggestion for a specific text: If a chunk can not be authenticated, implementations MUST discard the plaintext of that chunk without further processing, and stop processing the message with an error. Unauthenticated plaintext MUST NOT be output to other applications or the user. Truncated, authenticated plaintext MAY be output, if the truncation is reported as an error to the application or the user after the fact. In case of truncation, it is true that the (authenticated) beginning of the whole message might have been output to applications or users. That is strictly (and vastly) better than outputting tampered plaintext for any particular chunk. Truncated plaintext can still be detected and the error can be indicated after the fact. Aborting an ongoing operation is a failure case that application developers and users are familiar with. It happens all the time, for many reasons (for example, lack of disk space or out of memory conditions, or any number of simple bugs when processing the data). It is unsurprising, and it can be dealt with at the application and user side. Tampered plaintext can be dangerous in many surprising and compromising ways, as the EFAIL researchers have shown. It is not a failure case that users or application developers are familiar with. They should not have to deal with it. If an impossible problem is easily separable in a solvable problem that achieves 99% of the goals, and an impossible problem for the remaining 1%, that's a resounding success. Thanks, Marcus From nobody Sun Jul 1 06:55:38 2018 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 9B565130EAA for ; Sun, 1 Jul 2018 06:55:35 -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 aIy1S9c1snOP for ; Sun, 1 Jul 2018 06:55:33 -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 4CD9512785F for ; Sun, 1 Jul 2018 06:55:32 -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=1530453333; x=1561989333; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=kkhWUmH0Q4KhVsrb37WBDbz4izg+lHl/Ob0NyQEdefI=; b=5PkDn1+EzTXNJCyOSg3YDW/MV2JL6bzqeuqpkPozhmZlfNuFQn4TkRjg ivMkbn2icb2q2iW1p90qEq9Uc9i6xU/hDYV0H4Tt1FX3+vKGyQf2mux7N onQpKIQMV8PcKNzwA7BWcsvwwhyHDWmtiSrbiPHoJAoZuxUsHgGYpyY9p ZkAIoh5sADsBMzM+ZT9P9Hf/W1wMmQApGmt50BjGGBRadWfhNTeSbb2Li HiZE+KnEP3j0vAvlxhJt8VDkdhCayTI/ExYKzzseclG1qUqfpQKITpQrr 9NkuWr+8ZzP7uOsPSEqoO5rjyVYnD0MjK1HoFix+t/mhqQAmvTOsGNNcx g==; X-IronPort-AV: E=Sophos;i="5.51,295,1526299200"; d="scan'208";a="18963706" 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; 02 Jul 2018 01:55:30 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 2 Jul 2018 01:55:30 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::ccab:7bf5:3d4a:aed8]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::ccab:7bf5:3d4a:aed8%14]) with mapi id 15.00.1263.000; Mon, 2 Jul 2018 01:55:30 +1200 From: Peter Gutmann To: Marcus Brinkmann , "openpgp@ietf.org" Thread-Topic: [openpgp] AEAD mode unverified chunks Thread-Index: AQHUEIzhW94Nj+WvxkKsWz4Icn2RHaR571i4//+oI4CAAM2DEg== Date: Sun, 1 Jul 2018 13:55:30 +0000 Message-ID: <1530453318943.37822@cs.auckland.ac.nz> References: <1530428015814.83795@cs.auckland.ac.nz>, <7080a271-6244-13d3-04da-d00a32766de1@ruhr-uni-bochum.de> In-Reply-To: <7080a271-6244-13d3-04da-d00a32766de1@ruhr-uni-bochum.de> 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 mode unverified chunks X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 13:55:36 -0000 Marcus Brinkmann w= rites:=0A= =0A= > If a chunk can not be authenticated, implementations MUST discard the=0A= > plaintext of that chunk without further processing=0A= =0A= But that then requires the artificial chunk-size restriction you mentioned = in=0A= an earlier message, which also means you'll start expanding messages if you= =0A= have to break them up into smallish chunks with IVs and MACs and whatnot in= =0A= each chunk...=0A= =0A= Hmmm, and a comment on the text:=0A= =0A= "A new random initialization vector MUST be used for each message".=0A= =0A= That should be "for each chunk", along with a strong warning about the fact= =0A= that you'll get a catastrophic failure of security if you don't do this and= =0A= use a highly brittle AEAD mode like GCM. That is, this isn't just some nic= e=0A= thing to do like the usual comment about using fresh IVs, you'll get a=0A= catastrophic security failure if you don't, far more so than with any other= =0A= encryption mode that uses IVs.=0A= =0A= Peter.=0A= From nobody Sun Jul 1 08:14:12 2018 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 8C024130DCA for ; Sun, 1 Jul 2018 08:14:09 -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 8sArVE7b2Xlh for ; Sun, 1 Jul 2018 08:14:07 -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 7CFB012F1A6 for ; Sun, 1 Jul 2018 08:14:07 -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 41JYnW6vcQz4y6q for ; Sun, 1 Jul 2018 17:14:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ruhr-uni-bochum.de; s=mail-2017; t=1530458048; bh=S7xFqOWfep5CrDBK9Dcsk1jRB6ghDTg1F9axEN5e4SU=; h=Subject:To:References:From:Date:In-Reply-To:From; b=YbYe6D8gC2f6cdQY3zh9p6z/KtMwLOPZaJqO+2BWp5RmZOuuZKvASlpmEwkOO6nKu qnhVjjwRc8HxvkaLXaSkPg1rxgXuc3Q3hNe53if6hF3Yt8bGIcX0qZMo7TLvUFB0oo fHGLPE6Hrh3NfkB27nX0D9NwuW/yU46Cg4fY+Gig= 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 41JYnW6GG3z4y7l for ; Sun, 1 Jul 2018 17:14:07 +0200 (CEST) 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 41JYnW5W2yz4y6q for ; Sun, 1 Jul 2018 17:14:07 +0200 (CEST) Received: from [192.168.142.139] (p5B04976F.dip0.t-ipconnect.de [91.4.151.111]) by mail1.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 41JYnS0TDfzyXc for ; Sun, 1 Jul 2018 17:14:04 +0200 (CEST) To: openpgp@ietf.org References: <1530428015814.83795@cs.auckland.ac.nz> <7080a271-6244-13d3-04da-d00a32766de1@ruhr-uni-bochum.de> <1530453318943.37822@cs.auckland.ac.nz> From: Marcus Brinkmann Openpgp: preference=signencrypt Message-ID: <8f10ae91-9656-4f6d-b41d-9a579b7eb283@ruhr-uni-bochum.de> Date: Sun, 1 Jul 2018 17:14:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <1530453318943.37822@cs.auckland.ac.nz> 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 mode unverified chunks X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 15:14:10 -0000 On 07/01/2018 03:55 PM, Peter Gutmann wrote: > Hmmm, and a comment on the text: > > "A new random initialization vector MUST be used for each message". > > That should be "for each chunk", along with a strong warning about the fact > that you'll get a catastrophic failure of security if you don't do this and > use a highly brittle AEAD mode like GCM. That is, this isn't just some nice > thing to do like the usual comment about using fresh IVs, you'll get a > catastrophic security failure if you don't, far more so than with any other > encryption mode that uses IVs. My reading is that the nonces for individual chunks are derived from the message IV by XORing an index number. See the subsections on EAX and OCB that follow. Thank you for taking a look at the AEAD part of the specs. From nobody Sun Jul 1 10:12:48 2018 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 E4FC1130DED for ; Sun, 1 Jul 2018 10:12:45 -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=unavailable 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 kGwrXTLA7v0J for ; Sun, 1 Jul 2018 10:12:44 -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 8A2EC126CC7 for ; Sun, 1 Jul 2018 10:12:44 -0700 (PDT) Received: from genre.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:7872:b1da:4747:5087]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by injection.crustytoothpaste.net (Postfix) with ESMTPSA id DCA186073C; Sun, 1 Jul 2018 17:12:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net; s=default; t=1530465133; bh=YNl8h+QEXO/IZ8OCVH+Q+25mxtKEjxahqfoYsz4M9II=; 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=Mj0hSkkQKtVTy7AvsCviJE4hRM6bKICVJQX0LWmi5dXfx6YQZlNrj3jExRtp9XjGK bh7V+6DITXOi6qKzbpY9pUfWkqmNQulqjFHa6aJqiwPA5+ESbb5lG22c1Qc0IUSGN8 YAoZm+hMM0m5BNUe7UfGw38TMtBRRdJuFuB0VrrV4mXVsNhA7lS/u9Kxr5JQRDn9Bi xQD4pfLG2ykH8XOnGZsMPko5Duq+rq29xjRIHAR/kP2KGDVOxIhW//cPF8ucWpTlmp CevE6u+wAu9UXG+ExlcRltNCyt9YBdGBb4cAZ0xUN5emiS06lX38rxY3x44WYIs4Gj 7AAQgnXWZUsYypOqmESRP1IuZ/KgPHUSISxWMzdYFYRY2QELIJn7XmC35fTLRpTkdc BBMyqlxQrJ99H+xSNHxK8fRwOFLH0ec03YhOvIZhKe+KpsVmcFtqw9pa5iC1UHkLai F2uTvcgbgspSOCYUN1g8kbL8J1CfZgxzyzj6IFoemexAKfJDHkc Date: Sun, 1 Jul 2018 17:12:08 +0000 From: "brian m. carlson" To: Marcus Brinkmann Cc: IETF OpenPGP Message-ID: <20180701171208.GB7965@genre.crustytoothpaste.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hHWLQfXTYDoKhP50" Content-Disposition: inline In-Reply-To: X-Machine: Running on genre using GNU/Linux on x86_64 (Linux kernel 4.16.0-2-amd64) User-Agent: Mutt/1.10.0 (2018-05-17) X-Scanned-By: MIMEDefang 2.79 on 127.0.1.1 Archived-At: Subject: Re: [openpgp] AEAD mode chunk size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 17:12:46 -0000 --hHWLQfXTYDoKhP50 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 30, 2018 at 06:00:40PM +0200, Marcus Brinkmann wrote: > Hi, >=20 > RFC4880bis contains this segment: >=20 > The chunk size octet specifies the size of chunks using the following > formula (in C), where c is the chunk size octet: >=20 > chunk_size =3D ((uint64_t)1 << (c + 6)) >=20 > An implementation MUST support chunk size octets with values from 0 > to 56. Chunk size octets with other values are reserved for future > extensions. >=20 > This allows chunk size up to 2^(6+56) =3D 4 EiB. It is impossible to > implement AEAD correctly with chunk sizes larger than can be buffered in > RAM. A large chunk size would require output of unverified plaintext, > enabling attacks like EFAIL but also others. I agree with this. The original specification I submitted limited the value to something smaller for this reason. > To implement AEAD correctly, chunk size must be limited to reasonable > sizes. TLS uses a chunk size up to 2^14 (16 KiB), but any reasonable > limit will do, for example 64 KiB. I suggest to change the text to this: >=20 > The chunk size octet specifies the size of chunks using the following > formula (in C), where c is the chunk size octet: >=20 > chunk_size =3D ((uint64_t)1 << c) >=20 > An implementation MUST support chunk size octets with values from 0 > to 16. Chunk size octets with other values are reserved for future > extensions. The reason I specified a lower bound of 64 bytes per chunk is that it doesn't make sense to have chunks that are, for example, 1 byte long. That's a great way to be wasteful and potentially DoS a recipient, since each AEAD chunk involves some block cipher overhead. Of course, trailing chunks may be smaller, and that's okay; the document anticipates that. --=20 brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 --hHWLQfXTYDoKhP50 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.2.8 (GNU/Linux) iQIzBAABCgAdFiEEX8OngXdrJt+H9ww3v1NdgR9S9osFAls5C2cACgkQv1NdgR9S 9osXthAA0GL7WIVw3+aidAN+JXCVnp1+rbgRibuKoeduH7fCXj+ira3sFX8RXjUI AY4Lo6XWBEj4vOl9Y/Cn4ZatClo59b+rCQ1WhVxbhDgalhCy85NKkIDMUyg0ptNM L1G+JD0excuH7cYOAddu8fmt4Oyvg4l2mJwcm7sWSWD9A24VQMot7qvCq+eB4IsR 5iJUfTog2+CTH8Ri7Pl5jZb2EvkurrPa/JnWuDkEk3Vc1W6nef7johVwEHmUDDmi R4TlLe0DJ9jqeOVsy8dFdktE3hwv++KxeH/SXwFVsYqVeHlovyhVWtoljjO/SGNB BMlQ8fn9S2q0XnMrQIVsJhczBC/06nXLm7K6SIMu7X6jPI5INwM5R1wlsND20Sh1 FHK08wzkdvgS3pYnRQJwsoJZYyTdbZQXuQrvTzTu0nvjxvXh7Ut7Inc3PMBMK9QF LwgO3ZuAozNLxCGEo9HM8qJWqP3hr1ZsD6VVesdyJReZfGkeWLEhdpMd4/L7UHYL P6QEmhFRYvSjKbToahNWsmh4099+OFuotSEmLlOW2ioSB9m4FmutxD/MGJXYu/kW Ce2qLnwCwA3X7Xbu9HJgzPlayTdAh8Ni1DoOnnxO1uis8AjRyr2xJl480DWqVbP4 mSVx7gwSr6zmBOtfQfUPnAju22k4vj5Pg93Y0H+VFTepHk9z+BE= =xzM9 -----END PGP SIGNATURE----- --hHWLQfXTYDoKhP50-- From nobody Sun Jul 1 10:17:50 2018 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 A1471130DF5 for ; Sun, 1 Jul 2018 10:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 cYHg6ltrK9Dm for ; Sun, 1 Jul 2018 10:17:47 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 0E96F126CC7 for ; Sun, 1 Jul 2018 10:17:46 -0700 (PDT) X-AuditID: 12074424-a77ff70000002515-d6-5b390cb961bf Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 42.62.09493.ABC093B5; Sun, 1 Jul 2018 13:17:46 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w61HHi5n020162; Sun, 1 Jul 2018 13:17:45 -0400 Received: from kduck.kaduk.org (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.13.8/8.12.4) with ESMTP id w61HHeWH003702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 1 Jul 2018 13:17:43 -0400 Date: Sun, 1 Jul 2018 12:17:40 -0500 From: Benjamin Kaduk To: Peter Gutmann Cc: Marcus Brinkmann , "openpgp@ietf.org" Message-ID: <20180701171740.GA22125@kduck.kaduk.org> References: <1530428015814.83795@cs.auckland.ac.nz> <7080a271-6244-13d3-04da-d00a32766de1@ruhr-uni-bochum.de> <1530453318943.37822@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1530453318943.37822@cs.auckland.ac.nz> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnleLIzCtJLcpLzFFi42IR4hRV1t3FYxltcPUGp0X/vBiLhn8P2S1e vnvO6sDscbHxAJPHiWVXWD2WLPnJFMAcxWWTkpqTWZZapG+XwJWx4u9WxoKrXBVHF91mamA8 x9HFyMkhIWAiMe3Ya/YuRi4OIYHFTBK/X61mhXA2MErcPnGKCcK5wiSxZN1zRpAWFgEVia2n L7GB2GxAdkP3ZWYQW0RAV2Ji72Iwm1mgWqKz+SsTiC0sYCTR9/gdO4jNC7RuxZYzzBBDrzJK TLzQCJUQlDg58wkLRLOWxI1/L4GaOYBsaYnl/8BO5QTqvTjvMVi5qICyxN6+Q+wTGAVmIeme haR7FkL3AkbmVYyyKblVurmJmTnFqcm6xcmJeXmpRbrmermZJXqpKaWbGEGhy+6isoOxu8f7 EKMAB6MSD++B3ebRQqyJZcWVuYcYJTmYlER5D4uZRQvxJeWnVGYkFmfEF5XmpBYfYpTgYFYS 4RX9CFTOm5JYWZValA+TkuZgURLnzV3EGC0kkJ5YkpqdmlqQWgSTleHgUJLg7eG2jBYSLEpN T61Iy8wpQUgzcXCCDOcBGl7CBVTDW1yQmFucmQ6RP8VozPHn/dRJzBz7uqdNYhZiycvPS5US 560EGScAUppRmgc3DZR+JLL317xiFAd6TpjXG6SKB5i64Oa9AlrFBLSq+rgpyKqSRISUVANj vzJz/pG43Dv1tgcvRRzXEHcvjrJvlD5SlV773UpR70DT2j676sv3X8x00bYWCTAPuBygpJx9 63WmUbhLa+OZS6wf1l0NOV2WoeFl4tmpM6Npw06m8Cn2wa8TjSfZL87hSPDxn5Ve1ifIeUNl wr4j9xasvpm+aKHQkvJ7rrs+i23zLj4mNFGJpTgj0VCLuag4EQC8J9cqGgMAAA== Archived-At: Subject: Re: [openpgp] AEAD mode unverified chunks X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 17:17:49 -0000 On Sun, Jul 01, 2018 at 01:55:30PM +0000, Peter Gutmann wrote: > Marcus Brinkmann writes: > > > If a chunk can not be authenticated, implementations MUST discard the > > plaintext of that chunk without further processing > > But that then requires the artificial chunk-size restriction you mentioned in > an earlier message, which also means you'll start expanding messages if you > have to break them up into smallish chunks with IVs and MACs and whatnot in > each chunk... Aren't we talking about a greenfield new proposal that can in fact mandate such chunk-size restrictions? -Ben > Hmmm, and a comment on the text: > > "A new random initialization vector MUST be used for each message". > > That should be "for each chunk", along with a strong warning about the fact > that you'll get a catastrophic failure of security if you don't do this and > use a highly brittle AEAD mode like GCM. That is, this isn't just some nice > thing to do like the usual comment about using fresh IVs, you'll get a > catastrophic security failure if you don't, far more so than with any other > encryption mode that uses IVs. > > Peter. > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp From nobody Sun Jul 1 10:26:35 2018 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 EFFF3130DF0 for ; Sun, 1 Jul 2018 10:26:33 -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 4Hnb9R3LQ-ln for ; Sun, 1 Jul 2018 10:26:30 -0700 (PDT) Received: from out2.mail.ruhr-uni-bochum.de (out2.mail.ruhr-uni-bochum.de [134.147.42.229]) (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 8589C12F1A2 for ; Sun, 1 Jul 2018 10:26:30 -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 41JckD2sjdz4xJp for ; Sun, 1 Jul 2018 19:26:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ruhr-uni-bochum.de; s=mail-2017; t=1530465988; bh=NQN7ohrh55alJ+ZU/hV5qizgN2bbOP0TnJ2LqZJ2xgY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=tn+2vgE1Pddv7IeA1AD8/LyRzF/c6mIqoGNzsxDEZ3mYey78pgp8Rioy/Sh9+NDhC GYhaJezwiEkusJQ9LRX+Qgq5DW67Ltf7wXKGkTipDoexQiT6xHHIoj7jFwPnWW8z3N zDfI2DhwFXmiJyMm5riPfHI6HA83xqRPjV3TOEwc= 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 41JckD1mmRz4xLh for ; Sun, 1 Jul 2018 19:26:28 +0200 (CEST) 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 out2.mail.ruhr-uni-bochum.de (Postfix mi-int) with ESMTP id 41JckD19T8z4xJp for ; Sun, 1 Jul 2018 19:26:28 +0200 (CEST) Received: from [192.168.142.139] (p5B04976F.dip0.t-ipconnect.de [91.4.151.111]) by mail1.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 41JckC60KzzynK for ; Sun, 1 Jul 2018 19:26:27 +0200 (CEST) To: openpgp@ietf.org References: <20180701171208.GB7965@genre.crustytoothpaste.net> From: Marcus Brinkmann Openpgp: preference=signencrypt Message-ID: <1de9ba23-e4ee-1341-bc3a-8227f23d4bcd@ruhr-uni-bochum.de> Date: Sun, 1 Jul 2018 19:26:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180701171208.GB7965@genre.crustytoothpaste.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="YUjmHFB3SKZHZLZzawhqWDA9e5JS39wbe" 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 mode chunk size X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 17:26:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --YUjmHFB3SKZHZLZzawhqWDA9e5JS39wbe Content-Type: multipart/mixed; boundary="iKjICdG7vbA3B62dXSnzykW4EQTeKi1lD"; protected-headers="v1" From: Marcus Brinkmann To: openpgp@ietf.org Message-ID: <1de9ba23-e4ee-1341-bc3a-8227f23d4bcd@ruhr-uni-bochum.de> Subject: Re: [openpgp] AEAD mode chunk size References: <20180701171208.GB7965@genre.crustytoothpaste.net> In-Reply-To: <20180701171208.GB7965@genre.crustytoothpaste.net> --iKjICdG7vbA3B62dXSnzykW4EQTeKi1lD Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 07/01/2018 07:12 PM, brian m. carlson wrote: > I agree with this. The original specification I submitted limited the > value to something smaller for this reason. =2E.. > The reason I specified a lower bound of 64 bytes per chunk is that it > doesn't make sense to have chunks that are, for example, 1 byte long. > That's a great way to be wasteful and potentially DoS a recipient, sinc= e > each AEAD chunk involves some block cipher overhead. >=20 > Of course, trailing chunks may be smaller, and that's okay; the documen= t > anticipates that. I'd be fine with having a lower limit as well, and if the best way to express that is "2^(6+c) with 0 <=3D c <=3D 10" instead of "2^c with 6 <=3D= c <=3D 16" then that's fine with me, too. I dug your original change, it can be found here: https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/4/diffs Here is your original wording for reference: 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. Thanks! Marcus --iKjICdG7vbA3B62dXSnzykW4EQTeKi1lD-- --YUjmHFB3SKZHZLZzawhqWDA9e5JS39wbe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEPLDoRBatUvfhhlQYiLCNWle2IUAFAls5DsMACgkQiLCNWle2 IUAK5BAAseeR03NL5VgyYOdVJ+0kZ9Wxa27tAuSPzl6jZbAHidrI2hWWxeHUzb28 NUw17TjtbgqFMaioNQSOVrudZj/nhJgoBK3E4PyEENSHRapLu6jqjOImquPerEXX JgXce9W0mI9KqcyWkaSFw8u255vU1mCl0q8W9I79D0xyFzCjwWw70vHbaGsbWjXu jhYhb2nyxFkfMvZQso5Dde5oNw4leoQcQF6MraZVEdZNL7voi1GVjxQbYM6gA8NV L3ViqTLHBpCsRA6E3VJFzOrTYZA6yxnb+3USX/dTpwgUSHz2uSZm4vL31Mrboeyh pRaw0cSTn2BAXJkyOUu7wte2FG2P/ODMTJw9U+iQTOZjgan5yCSdDCBEf+xWICZ5 OJFMm6oCbfRTOluy88Ypv3iobDTsviq9cKNu80pkkMFWRmWiuUNjU8lIHydt/4lN rwnooJkVY/Q8OVeDvlf1IjYFZ6H/7Ni5hl6E4nvzVNIiuLcSWtACgbdzIFHOm2sB ZITydkwM4FI61HNtCDuTst3muiQ5c3K+0qwxbu9o6+6yvxKtR+zzL9gHKiUo0NYF Ffbo1RNHN8zhwKdAO+2WokuPThIGlen/toJ+xTPPLzLVri1sbRWUGAdMSmQ/P0Pk wPhOHfVJ0q8UuP/V0jcMd2gpxfKyQnGXH+ZuGGAYn/CYuG4rw/A= =zNbc -----END PGP SIGNATURE----- --YUjmHFB3SKZHZLZzawhqWDA9e5JS39wbe-- From nobody Sun Jul 1 17:10:35 2018 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 0ACDF130E99 for ; Sun, 1 Jul 2018 17:10:28 -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 (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 vgnBOTBRbKUZ for ; Sun, 1 Jul 2018 17:10:26 -0700 (PDT) Received: from st13p27im-asmtp004.me.com (st13p27im-asmtp004.me.com [17.162.190.113]) (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 E9A66130EB1 for ; Sun, 1 Jul 2018 17:10:25 -0700 (PDT) Received: from process-dkim-sign-daemon.st13p27im-asmtp004.me.com by st13p27im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0PB700P00PNXAI00@st13p27im-asmtp004.me.com> for openpgp@ietf.org; Mon, 02 Jul 2018 00:10:25 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1530490225; bh=8bLRFN5c6E85KkQ9qsHn10xNs43PURWQ+Ig8TYveHQM=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=SE7lzAWSxl69mCoopH+IjYcbu/RKNbugqpgUCOnG/9D14YgZdovZpjq2kcwLPPU9U JKL/eYIMyImmaJ0m4tvq3zfjPZAb/X6bpEcmkmOZb3a+er1XC08+esT51DiP2smtDL 3pqCP5+7h8n/XuxO02ncKlh47qa3C2x5cGEVBXv2850X8wyUzvHGdcBB50+Qz5n9bj PfgMLtMYeWSruuTI53IFSFPybSPm63YATXLxAUT/wdwDzcm8gQ2Ppw7MHfaBbGy9oU 4uz7Wvai4mLuttzT2MNbcC3+g3MRl9iWkw4qJ+qvVboryzN4FzxJHoaGLaEMH4vM0+ eqywSHabTY+VQ== Received: from icloud.com ([127.0.0.1]) by st13p27im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0PB700SWFPTBGW30@st13p27im-asmtp004.me.com>; Mon, 02 Jul 2018 00:10:24 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-07-01_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1807020001 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Jon Callas In-reply-to: <1cacc056-1ec7-f388-ee08-46468bd87bda@metacode.biz> Date: Sun, 01 Jul 2018 17:10:22 -0700 Cc: Jon Callas , openpgp@ietf.org Content-transfer-encoding: quoted-printable Message-id: <7CA41263-1E09-4866-A89E-EB6F01797257@icloud.com> References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> <118e5b9d-de9e-aa14-d8b4-19ef259f3d0a@ruhr-uni-bochum.de> <3996841a-b6ae-8769-2de8-b35351c54719@leo.gaspard.ninja> <8E4410C7-9370-492C-838F-857983CA67FC@icloud.com> <8a608b9f-f96b-466d-a0b8-7d1aa39ab011@leo.gaspard.ninja> <1cacc056-1ec7-f388-ee08-46468bd87bda@metacode.biz> To: Wiktor Kwapisiewicz X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [openpgp] Overhauling User IDs / Standardizing User Attributes (was: Re: Scoped trust (signatures)) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 00:10:33 -0000 > On Jun 29, 2018, at 12:45 AM, Wiktor Kwapisiewicz = wrote: >=20 > Hi Jon, >=20 > This is slightly off-topic but... >=20 >> Heck, while you=E2=80=99re at it, talk to the Keybase people because = they explicitly now have Twitter, Facebook, Github and DNS identifies, = along with Reddit, Hacker News, Bitcoin addresses, Zcash addresses, and = more I=E2=80=99m likely missing. >=20 > =46rom what I've seen Keybase is not interested in purely OpenPGP = solution - they want to keep the data on their site [0]. So it=E2=80=99s not worthwhile solving this problem? Or are you saying = that because they are doing it no one else should do it in a standard = way? I think it=E2=80=99s really cool that Keybase lets you authenticate = these other networking points. And it sounds like this is at least part = of the problem. >=20 > And there already is I-D for "keybase but distributed" using OpenPGP - = Linked Identities by Vincent [1]. Moreover this draft is already = implemented in OpenKeychain and has verifications for Twitter, GitHub, = etc. and works really well. I think the concept is proven to be working. = (The only issue that I have with it it's that it's using experimental = UAT IDs, but because Linked IDs is just a draft it cannot get proper = assignment). >=20 > I've been experimenting on a slightly different implementation of = Vincent's concept (using User IDs and notations instead of Attributes, = and defined verification language) [2]. >=20 > Also, a quote from Werner over the use of user attributes from 2017 = [3]: >=20 >> (...) Anyway, I think that the User >> Attributes should not be extended over their use for an image. URIs = can >> simply be represented by plain User IDs and software can easily = detected >> such URIs if desired. >> The need to implement UAT only adds more complexity for a = questionable >> purpose. Note that these image UAT were introduced due to marketing >> needs of PGP or NAT and (iirc) only specified after they had been >> introduced in their software. >=20 > I didn't agree with him back then, but after longer thought I changed = my opinion - user attributes do not have any fallback mechanism - either = most software supports that custom special attribute or it's practically = impossible to work with them (yes, they are supported, but displayed as = an opaque string [4]). And I say this as a person that added this packet = "by hand" and use it on my key. I don=E2=80=99t agree with him now. This is *precisely* the sort of = thing that User Attributes were created to solve. >=20 > (As a side note, photos could be expressed as links to images with a = hash, that would reduce the key size significantly). Sounds like a privacy-surly mechanism to me.=20 There are many problems around the Internet today where external links = cause fetches that then cause DNS lookups, SSL fetches, leakages of SNI = information and others. Keeping the relevant data in a blob is = privacy-friendly.=20 >=20 > On the other hand I like the "hand wavy" approach to User IDs, I think = it's underutilized :-) Sure, but it means that you are using a generic text field in ways that = are hard to parse. Why not define it? Jon= From nobody Sun Jul 1 17:20:24 2018 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 4A860130E31 for ; Sun, 1 Jul 2018 17:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 KYvhhLXiR0-Q for ; Sun, 1 Jul 2018 17:20:20 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) (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 86C90130E2B for ; Sun, 1 Jul 2018 17:20:20 -0700 (PDT) Received: from [47.143.125.3] (helo=Williams-MacBook-Pro.local) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1fZma4-0002Zz-LT for openpgp@ietf.org; Sun, 01 Jul 2018 20:20:36 -0400 Date: Sun, 1 Jul 2018 17:20:18 -0700 From: Bill Frantz To: openpgp@ietf.org X-Priority: 3 In-Reply-To: <7CA41263-1E09-4866-A89E-EB6F01797257@icloud.com> 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: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec7977d65d788bef6b0fa658147f4bff8ac2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 47.143.125.3 Archived-At: Subject: Re: [openpgp] Overhauling User IDs / Standardizing User Attributes (was: Re: Scoped trust (signatures)) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 00:20:22 -0000 On 7/1/18 at 5:10 PM, joncallas@icloud.com (Jon Callas) wrote: >>On the other hand I like the "hand wavy" approach to User IDs, I think it= 's underutilized :-) > >Sure, but it means that you are using a generic text field in=20 >ways that are hard to parse. Why not define it? And needing to parse hard to parse fields is a well known=20 security problem because the resulting bugs are often exploitable. Cheers - Bill -------------------------------------------------------------- Bill Frantz | There are now so many exceptions to the 408-356-8506 | Fourth Amendment that it operates only by www.pwpconsult.com | accident. - William Hugh Murray From nobody Sun Jul 1 20:03:31 2018 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 6EBC9130E3D for ; Sun, 1 Jul 2018 20:03:29 -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 a3jSrWnWtcKd for ; Sun, 1 Jul 2018 20:03:27 -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 1F77A130DEF for ; Sun, 1 Jul 2018 20:03:26 -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=1530500607; x=1562036607; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=mcpsbD8P3JkdANK9POWkLHZnXGCMhxzU8xJbSpt+ihU=; b=jLH+/cSM0MXrqMruTPAlCRYWUu/24ogltkLpDt1sLec0GMay2BltpyPS 7R0g1KHVdFjZaBQLIJpHaDHMEqKHPwL4P2AqYoTiX6+7aRopE467MQU1j 5f8N3Evq7g2S2HG/M0aU79jveBD1yvmdZgU405rUcJ9aS38s4Pp5up1zl 7n0IK/xGPRPZwgfvjtutn5R7fD1vx5uXxux8i2ovm+4DbiNDU1L7MhrGr AGt6bp79EDJtnenovPFvZMvPz+l64EW6ZBvOjPLanIZ/jiBhFNt2wp6nm qu+M9+M41aLKf19ttFgNu6y4iwuUeJDW6+ENZg/QMmnEAaLJ7KkipSjP3 Q==; X-IronPort-AV: E=Sophos;i="5.51,297,1526299200"; d="scan'208";a="19098502" 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; 02 Jul 2018 15:03:24 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-tdc-e.UoA.auckland.ac.nz (10.6.3.9) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 2 Jul 2018 15:03:23 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::ccab:7bf5:3d4a:aed8]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::ccab:7bf5:3d4a:aed8%14]) with mapi id 15.00.1263.000; Mon, 2 Jul 2018 15:03:23 +1200 From: Peter Gutmann To: Marcus Brinkmann , "openpgp@ietf.org" Thread-Topic: [openpgp] AEAD mode unverified chunks Thread-Index: AQHUEIzhW94Nj+WvxkKsWz4Icn2RHaR571i4//+oI4CAAM2DEv//TQiAgAGPObo= Date: Mon, 2 Jul 2018 03:03:22 +0000 Message-ID: <1530500589685.30228@cs.auckland.ac.nz> References: <1530428015814.83795@cs.auckland.ac.nz> <7080a271-6244-13d3-04da-d00a32766de1@ruhr-uni-bochum.de> <1530453318943.37822@cs.auckland.ac.nz>, <8f10ae91-9656-4f6d-b41d-9a579b7eb283@ruhr-uni-bochum.de> In-Reply-To: <8f10ae91-9656-4f6d-b41d-9a579b7eb283@ruhr-uni-bochum.de> 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 mode unverified chunks X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 03:03:30 -0000 Marcus Brinkmann w= rites:=0A= =0A= >My reading is that the nonces for individual chunks are derived from the= =0A= >message IV by XORing an index number. See the subsections on EAX and OCB t= hat=0A= >follow.=0A= =0A= Sure, however if in the future someone adds another AEAD mode, and in=0A= particular the very fashionable (in fact I'm surprised it isn't already in= =0A= there) but also very brittle GCM, then safe IV handling is criticial to=0A= security. It's just a personal preference, but I'd add a somewhat stronger= =0A= warning to the text in 5.16 for per-chunk unique/random IVs and the=0A= consequences of not using them when some AEAD modes are used.=0A= =0A= Peter.=0A= From nobody Sun Jul 1 22:42:47 2018 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 4E5AF130E23 for ; Sun, 1 Jul 2018 22:42:40 -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, 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=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 ZYNfdrlTobTO for ; Sun, 1 Jul 2018 22:42:36 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 1168E130F76 for ; Sun, 1 Jul 2018 22:42:35 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id t7-v6so11548295ljj.6 for ; Sun, 01 Jul 2018 22:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metacode.biz; s=2017; h=subject:to:cc:references:from:openpgp:autocrypt:organization :message-id:date:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=bTF8l/AAVzRqhbWC0712VE9LsFKCa2W8Ve/o89jak6c=; b=RJ+XiIn3M/HRvjqmTwEOUwufHoUsryEOOYLwsZOnncredqXSSGkKkORfm4gg9xvaxH s9KxGf/VvMkzbRNRbxUtO7tv7/+NF7Q+Saz6J1EKvvfJlD6UW4sqGnp7f14h14hK0Jwn EDIotkDpS+HHDQzHeR6epVm3jIqHDCwSCv1lofNOAbwVrZwbWb/0/HEx/aNM/PCezDoA D2HXezBRPxiWL5wzqPXilHHqY+ZeXVP5LLN6r2hoRlLYHCTzogCqDRs+3czWF0eHu6lt IjlP78q8d3b7XOpIl7um0K3iD92k8wUEKuKcr46jQzqyQwSyDsIlPSdoOyqHRjYwWqll I2aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :organization:message-id:date:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=bTF8l/AAVzRqhbWC0712VE9LsFKCa2W8Ve/o89jak6c=; b=fEYwXp/8RRaXdV6qh5ip+DeP8QXJ4GcFXk/LgY7J3SAlR+mPkYSrplxGoI3An6Dt/w dTSiLnOaPzh5k6pCKM4NIQcrLeYr7WavSuSqU9y8TnCCpsOthVAUiW79s26Mj8O0YRHL zPMZiCRTnVREXBo/xdOJoDaoZpfmDBGlXDDWpZ2r71xGpDDhKmOoTMqB3Xqwxx+I33qL Ud7l78E5YT5hKp/zSjEbvPTyA4qQc/OiSRBlvFchom/vDA9s5XMUHNf3TiXkqVRxVYYX pBOYyEq7j+MZpKCaw8+9uLRab7hSfFYx6ymrzgInap2APOkJ8L1RhKrn+RVvufw2Mxsi m0yA== X-Gm-Message-State: APt69E38UyHFK7rXIbt0lMto+pP9PotWSMZ4RQ1VIytElLOkup0xOYAu beEoDVJCWzV6esGcrj/IpLc4KDBISfw= X-Google-Smtp-Source: AAOMgpepUCr4t0+OpWD4T/UvJs2mOTW2ZmXe4VkK27Up1+Kx569YH/8GTe7CSn/fKb5HjEk9KAxN4w== X-Received: by 2002:a2e:9f4d:: with SMTP id v13-v6mr2153042ljk.42.1530510153437; Sun, 01 Jul 2018 22:42:33 -0700 (PDT) Received: from ?IPv6:2a02:a317:4e3d:4680:4554:20f:5f09:8d7a? ([2a02:a317:4e3d:4680:4554:20f:5f09:8d7a]) by smtp.googlemail.com with ESMTPSA id i140-v6sm2203324lfg.54.2018.07.01.22.42.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Jul 2018 22:42:32 -0700 (PDT) To: Jon Callas Cc: openpgp@ietf.org References: <39e598e1-2bc0-32c9-3489-4bb6ca2a631b@leo.gaspard.ninja> <871sdw24yd.wl-neal@walfield.org> <118e5b9d-de9e-aa14-d8b4-19ef259f3d0a@ruhr-uni-bochum.de> <3996841a-b6ae-8769-2de8-b35351c54719@leo.gaspard.ninja> <8E4410C7-9370-492C-838F-857983CA67FC@icloud.com> <8a608b9f-f96b-466d-a0b8-7d1aa39ab011@leo.gaspard.ninja> <1cacc056-1ec7-f388-ee08-46468bd87bda@metacode.biz> <7CA41263-1E09-4866-A89E-EB6F01797257@icloud.com> From: Wiktor Kwapisiewicz Openpgp: id=653909A2F0E37C106F5FAF546C8857E0D8E8F074; url=https://metacode.biz/@wiktor/openpgp/key Autocrypt: addr=wiktor@metacode.biz; keydata= xsFNBFhoYHoBEADzmg9UuwDrtvyejU01gDY1J1iJiCi4XGJ4lCfYeLC2jSagIxU/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/BzGrpHI4QR3NNzVa423WCIWkHfwARAQABzSlXaWt0b3IgS3dh cGlzaWV3aWN6IDx3aWt0b3JAbWV0YWNvZGUuYml6PsLB7gQTAQoAmAIbAQgLCQgHDQwLCgUV CgkICwIeAQIXgHMUgAAAAAAqAEB0aW1lc3RhbXArYml0Y29pbi10cmFuc2FjdGlvbkBtZXRh Y29kZS5iaXphZmNiMDkyYzVjYTY0MDk1MjZkMThhZTljZjIyZDNiNTVkMzdlNzIzZWIxYjc0 ZTNmODRmN2U2YjA1MmExNjJhBQJaLoPdBQkDwPuGAAoJEGyIV+DY6PB0CNkQAKGTFHzG4YO6 yne5jfMlGcF8JUYq0EGHE9DRK6oAyGo+1TGFbf1bS4wULvA6LFBOLd+aI7uuN062kDdtHVUf 0S0AZ9ByjIBdQJsqx47W6uXsRX/pB0a70QqS6NbS3AL/fdwZOj/TBk8bdsfg7Z+hH+ykMcOs EYLmdMLmrqYgl9EyP4FmsnU9H8x4yKp0/Kv4BQYfjn68CFvyM2NQU3MR/H3sqvM/uY5AJwTp A8X1ZbN8pjZO5YRTiQtMrXekNzhP3p0ep1+cu2UxQO6jXV6Sjdm8D8RJzGaxCuhN/VhLNSvh cb2T5sejBAhU8JmKNle4+z5wZWB4bl5Dfkg1NpSEEdv7so+KXCnszo89UJJijlfgBFtm5WjK u7gCR8CVOeGQwQolEzi18zihCwRy1rg/xKokk7q6ZBEvxM1sBYNd81mi1PgrNwgH4jPULfQk UJtU7HLRVNLbnrIyEQbLOJegBLaWHgR4T69blBGg1oqiq/1PHnZuJauZhhNEAViX42VKJP1z w6PIfvbjg27wf4OjEDtVVXCrxqqljHRilagFQHGlU+iF6Ii2C3pNod11+lqJC0riFylxK/wu zHpoZdFg10gqMWIE2Exm7nJ6ToKv5kZqKC97mWrmh6FFEr6HmjDDuo+N4RER3VGj0dSey5nc eFQ2vry17IGN1ljV9TiARDgizsFNBFhoYf0BEACidQ4OVAKliYOnNzG5ltod8GS0eJj3CSnY 0gszCjS6Hm0OkvCN5RfEagALuLuJe06nFDB/mEvsV3CKO1rxPUrQnijxjl/L5LopdEVhwQoL UBhvMvdX62krk6CtsFUlQvHPS923+YoQ1/HWR8jbWLJq/PNJp3fE9FKbWX6BchOeZ/KCZ/Ip 6vv7YOVVyBVL8O/slSkEEaUS40ac/F70/wfUPXRgiOLYVikRNlphvmTu54F0KWFUbPYAhyr/ xSz8Joy34+e9h5ipEb+Cv9CrjQaHp8aLDAR1VJ3A+SjSt20mU1CuhKwpR+z0t/hjlOLHv0zR qWl3QNYmNBJ9I2oW4mH9FEDM3DRsWEaqdaL1uVeQ8rE4QZ6tbk76YS8eyRWjScLQm61USHxq 7KpUI73k6ST0Ylyj8D1a03dKUTuytgU0NhbFyArI2UHNvhm73X6qo7ofHlfgA6mVAaI4jW7r /CY0GLs29PyetdII/+6F50HAEXBswTesgx/2P6k+vHhReyZF7NgSkqEWaGgKdRlSyTpu/U+Q TRmLB/yWfL89+BMJZosX0oMWZxG7XPu18GXSeHNoSPw9xLNGWGMbKErIbyVqQyd6fu2gpYzO n9J57ImHvgoENvcyRl7sSOiZto/5EJiHubUBTeeuZf2V7QxfrP15h1SVkzDjIOP3qXF+oCI8 jQARAQABwsFlBBgBCgAPBQJYaGH9AhsMBQkB4TOAAAoJEGyIV+DY6PB0I94P/iFsWZcgYNaN JxXK99755nzKKDSqjCOkTgoV9h9cNaIZV944pupdugRW5ek6BV2/Cj93iCGMzrfzzvETPT4t 8oaC/0yJ0pzPUrFe9Uht2ghtmXQK6Mw0fM4daPKJtCQyMlfYljqKhxgIJ24cB+O04yOrvfCS FRQw/T4ngmqCvI1wRzxU98yljKKxcvQWZ6qY6izNeUZJ6Ie1iujQOEmnLSXMikcptGf5YC9C KY0f9MsCI75uCx2HKQRRcj/nOHE+dkwo5XyUbSuWhQu6bOHJI5S0ixkjVp6JQ4E1NBLR3P3V Kr1jg6ODbJ0w9B8peSumzFhGf0qo2RYkPYKkUFfejmUhphSAS2WmdGHbut32ibDn6vd/XTjs vGQUDQ2Bp3fXdqeTw79T5zGpS87omdnz/Wpavntjv9IbVTnCmJMfSBYUmMoBK94IEWttKmL/ UCmcoruhhLs1A3Xdn17gt6k+AkBapBd8IC15QiMedzCINtug399M9MMfgkW5NpGOunpLBbhG xUD2nqdK2j347/dGTT53sUa6tQw6IDNZrCWOJTqTeP6PD7BJt67tlywPgmLSBGYgWpnRNJhb 9QKzyn3KnUzp9lzUDLReEu2gdY2Kz1N5PVmmF/ysfKVJZ0ZGWPB4iR/HgAc6OY2TnHXiifKT EXmAO6RvoR7+8se4PUnv0mR1wsFlBBgBCgAPAhsMBQJaLoRUBQkDwPoDAAoJEGyIV+DY6PB0 XoMP/i+6XvyNE/XsdFgeAO/rtdELWphFUu1HbaKYeh6YMYjg71eR8KbYe2sz3M1Bawj/D7Kb tGRsxFshkLHau0N0cJHEr3U6j/U7sEWCW/YDlWSIyBWYg+j1k/aBczfL/oC9E9h8LOUUjjj3 vpRs2rHmIHT2aAvbRom1d4xaFh1kwn7sUKtc+0AoP5PCeBcfqMduunEPqsfsbmz1Dz+O5FJ7 LRG8YXyV+5YTT1pEuNjFm+GNBEvwhfJqN+H459ngMdZUkCyKwWLAMaJj6y9/ZJ8lrPLCjGDR p9FzhLg39gQqV5Vu41VyBr+9YucX/sWfQ1SuvWDMBnTKSOKX01RAHGvnOmtl3Vr4SqWDhFsO VdWluKugMiIdajKwgM9Bp+35O/l8QQbxxrRAy/TI+dB4w8Urn2oVPkAq8RgYJIzpYYUFnhKD EwcdoG8Lk2EqO60g9UR6tGVsW9/vYvVGHlm0kArIDF9o0zAo5wsuZE9kO4oneoIsCRLwjuZk bqQ+2V+8R3P5YkV8VogwwYPCAhkpGD/ACblux5ip1ilLWFm75Hj3aPkvJSWi5DfkoxzntZBM KrhpyhCKJFUPZovREteTzl8ns3/KvoUJ5VQF3HqXKw49sWrWSDHEugt9ERfCBzAuYl4WB7Qt xwe2q0voV3BFy8kd04NRiyJkBU0BeBHEHblrGY23 Organization: Metacode Message-ID: <0d6a0960-cf40-9a5a-06e1-c6cbb74309e7@metacode.biz> Date: Mon, 2 Jul 2018 07:42:29 +0200 MIME-Version: 1.0 In-Reply-To: <7CA41263-1E09-4866-A89E-EB6F01797257@icloud.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [openpgp] Overhauling User IDs / Standardizing User Attributes (was: Re: Scoped trust (signatures)) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 05:42:45 -0000 >> From what I've seen Keybase is not interested in purely OpenPGP solution - they want to keep the data on their site [0]. > > So it’s not worthwhile solving this problem? Or are you saying that because they are doing it no one else should do it in a standard way? I'm saying Keybase - as a company - will not do it in a standard way, that's all, no hidden meaning there. > I think it’s really cool that Keybase lets you authenticate these other networking points. And it sounds like this is at least part of the problem. Yeah, I like it too. But you know what's really cool? That there already *is* an I-D for that but using OpenPGP: https://tools.ietf.org/html/draft-vb-openpgp-linked-ids-01 I highly recommend reading that, it's already implemented and working in OpenKeychain. It uses User Attributes. Actually I asked for it to get the proper User Attribute ID assigned: https://www.ietf.org/mail-archive/web/openpgp/current/msg08913.html It did not happen. >> I didn't agree with him back then, but after longer thought I changed my opinion - user attributes do not have any fallback mechanism - either most software supports that custom special attribute or it's practically impossible to work with them (yes, they are supported, but displayed as an opaque string [4]). And I say this as a person that added this packet "by hand" and use it on my key. > > I don’t agree with him now. This is *precisely* the sort of thing that User Attributes were created to solve. Maybe that's just me but what's the difference between User Attribute that has value "https://github.com/wiktor-k" and a User ID that has value "https://github.com/wiktor-k"? I see only one - you can read the User ID just fine using existing frontends and UAT will be "opaque". User Attribute will have ID, right. > Sure, but it means that you are using a generic text field in ways that are hard to parse. Why not define it? I'm not opposed to defining it (actually I'd very much welcome that!). But the difference between User ID that has URI format and User Attribute that has URI format does not affect the difficulty of parsing (you still need to handle broken data in both cases). Kind regards, Wiktor From nobody Thu Jul 5 23:45:54 2018 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 74B72130DF1 for ; Thu, 5 Jul 2018 23:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01, 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 oTbvZ2dCGtvb for ; Thu, 5 Jul 2018 23:45:51 -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 E89DD130DE2 for ; Thu, 5 Jul 2018 23:45:50 -0700 (PDT) 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 D544DF99A; Fri, 6 Jul 2018 02:45:48 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 2BF6420381; Fri, 6 Jul 2018 02:43:26 -0400 (EDT) From: Daniel Kahn Gillmor To: Justus Winter , openpgp@ietf.org Cc: barryleiba@computer.org In-Reply-To: <8736wxzbtx.fsf@europa.jade-hamburg.de> References: <874lhg4wr3.fsf@europa.jade-hamburg.de> <871schmr3u.fsf@fifthhorseman.net> <8736wxzbtx.fsf@europa.jade-hamburg.de> Date: Fri, 06 Jul 2018 02:43:26 -0400 Message-ID: <87tvpclv8x.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] Test message, sorry for the noise X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 06:45:53 -0000 On Thu 2018-07-05 22:06:50 +0200, Justus Winter wrote: > I'm having difficulties sending mails to the list. If this one should > make it, please excuse the inconvenience. hm, this doesn't appear anywhere on the administrative interface that i can see :/ do you have any logs from your mailserver (probably avior.uberspace.de [185.26.156.32] if the copy i got is coming from the same MTA) handing off to mail.ietf.org (or to some other mx for ietf.org)? If so, can you share those logs? --dkg From nobody Mon Jul 23 07:33:51 2018 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 C0239130DD4 for ; Mon, 23 Jul 2018 07:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 K-3wdEvfQwAu for ; Mon, 23 Jul 2018 07:33:47 -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 5EE7C130DC0 for ; Mon, 23 Jul 2018 07:33:47 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1fhbuC-0007xX-HF for ; Mon, 23 Jul 2018 16:33:44 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1fhbjY-00006d-HI; Mon, 23 Jul 2018 16:22:44 +0200 From: Werner Koch To: Peter Gutmann Cc: Marcus Brinkmann , "openpgp\@ietf.org" References: <1530428015814.83795@cs.auckland.ac.nz> <7080a271-6244-13d3-04da-d00a32766de1@ruhr-uni-bochum.de> <1530453318943.37822@cs.auckland.ac.nz> <8f10ae91-9656-4f6d-b41d-9a579b7eb283@ruhr-uni-bochum.de> <1530500589685.30228@cs.auckland.ac.nz> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: Peter Gutmann , Marcus Brinkmann , "openpgp\@ietf.org" Date: Mon, 23 Jul 2018 16:22:38 +0200 In-Reply-To: <1530500589685.30228@cs.auckland.ac.nz> (Peter Gutmann's message of "Mon, 2 Jul 2018 03:03:22 +0000") Message-ID: <87in56ghg1.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=bank_MP5K-SD_Delta_Force_Mantis_Exon_Shell_brigand_bce_Abbas_event=s"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] AEAD mode unverified chunks X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 14:33:50 -0000 --=bank_MP5K-SD_Delta_Force_Mantis_Exon_Shell_brigand_bce_Abbas_event=s Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2 Jul 2018 05:03, pgut001@cs.auckland.ac.nz said: > security. It's just a personal preference, but I'd add a somewhat strong= er > warning to the text in 5.16 for per-chunk unique/random IVs and the > consequences of not using them when some AEAD modes are used. What about this: A new random initialization vector MUST be used for each message. Failure to do so for each message will lead to a catastrophic failure depending on the used AEAD mode. Or propose a different text. Salam-Shalom, Werner =2D-=20 # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=bank_MP5K-SD_Delta_Force_Mantis_Exon_Shell_brigand_bce_Abbas_event=s Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCW1XkrgAKCRD/gK6dHew1 jUGpAPwICRSF44qH1czI2COQsUNA15oyrJKmbA/Ng7kixrdGNQD/T7gaVASRQcnX qYDCECT4ptVM/W9rjrpLlpE6skI75Q0= =PLVR -----END PGP SIGNATURE----- --=bank_MP5K-SD_Delta_Force_Mantis_Exon_Shell_brigand_bce_Abbas_event=s-- From nobody Tue Jul 24 00:18:43 2018 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 C3C13130EC0 for ; Tue, 24 Jul 2018 00:18:41 -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 NpqXIJmUEdzA for ; Tue, 24 Jul 2018 00:18: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 76E17130E4A for ; Tue, 24 Jul 2018 00:18:40 -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=1532416720; x=1563952720; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IRtXpIU+Y6FtZfRF6aYhgbqjLpp3GRAJWGGdsEtYHi0=; b=MGwXL3LtHTiTrN8FO53tWUz7dNTbPjhSJiEzErlySseXm6vRqKvxeBt4 z8vwNA+k5noRCE7oTc4KWpi1z8Aok6sRY0M/5D4jYXaXC6OWs704nVrqW U5AnbwWZSP9EknQDJOP7UVrs7dHFkYZZfpUYNliLlCzWcGKNAJwBW/HLI NB9WcRRuYWWQq8c8VivlRdnZDhTK3Qwa6VAPLFf4q97QRmNF1yXCWXtns piprqM8ge/SGSMYHYsMKmLezsWrEJPOQeTctM1Ul5G2eUzpY54BtXOLCx xQhpqXEIgS1KTXwxF/ghvmV7ZT7s92AQyBvk5kQg3oU4REojATjFtpdZA Q==; X-IronPort-AV: E=Sophos;i="5.51,397,1526299200"; d="scan'208";a="22771281" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.3 - Outgoing - Outgoing Received: from exchangemx.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; 24 Jul 2018 19:18:34 +1200 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.1263.5; Tue, 24 Jul 2018 19:18:33 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Tue, 24 Jul 2018 19:18:34 +1200 From: Peter Gutmann To: Werner Koch CC: Marcus Brinkmann , "openpgp@ietf.org" Thread-Topic: [openpgp] AEAD mode unverified chunks Thread-Index: AQHUIpIz8+wkVO7KxEm10X+iojCKLKSd982r Date: Tue, 24 Jul 2018 07:18:34 +0000 Message-ID: <1532416712094.21297@cs.auckland.ac.nz> References: <1530428015814.83795@cs.auckland.ac.nz> <7080a271-6244-13d3-04da-d00a32766de1@ruhr-uni-bochum.de> <1530453318943.37822@cs.auckland.ac.nz> <8f10ae91-9656-4f6d-b41d-9a579b7eb283@ruhr-uni-bochum.de> <1530500589685.30228@cs.auckland.ac.nz>, <87in56ghg1.fsf@wheatstone.g10code.de> In-Reply-To: <87in56ghg1.fsf@wheatstone.g10code.de> 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 mode unverified chunks X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 07:18:42 -0000 Werner Koch writes:=0A= >What about this:=0A= >=0A= > A new random initialization vector MUST be used for each message.=0A= > Failure to do so for each message will lead to a catastrophic failure=0A= > depending on the used AEAD mode.=0A= =0A= Sounds good.=0A= =0A= Peter.=0A= From nobody Tue Jul 24 00:43:50 2018 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 79EB413103F for ; Tue, 24 Jul 2018 00:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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-arAn72ko2c for ; Tue, 24 Jul 2018 00:43:47 -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 2D8B9130E16 for ; Tue, 24 Jul 2018 00:43:47 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1fhryz-0005MC-C9 for ; Tue, 24 Jul 2018 09:43:45 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1fhrov-0005AD-NF for ; Tue, 24 Jul 2018 09:33:21 +0200 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: Tue, 24 Jul 2018 09:33:21 +0200 Message-ID: <87va95f5q6.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=security_lynch_Project_Monarch_Gazprom_Merlin_COSCO_TELINT_AMEMB_Rul"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: [openpgp] Need to publish bis-05 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 07:43:50 -0000 --=security_lynch_Project_Monarch_Gazprom_Merlin_COSCO_TELINT_AMEMB_Rul Content-Type: text/plain Hi -04 is about to expire. These will be the changes in -05: --8<---------------cut here---------------start------------->8--- ** New key flag: # The second octet: + 0x04 - This key may be used as an additional decryption subkey (ADSK). # The idea is that implementations will also encrypt to a second subkey # which for example is used on a second device. I am not sure whether # this is suitable solution and makes much sense so this is intended as a # bait for discussion. ** Deprecation of Symmetrically Encrypted Data Packet + This packet is obsolete. An implementation MUST not create this + packet. An implementation MAY process such a packet but it MUST + return a clear diagnostic that a non-integrity protected packet has + been processed. The implementation SHOULD also return an error in + this case and stop processing. ** Limit the chunk size of AEAD packets: An implementation MUST support chunk size octets with values from 0 to 56. Chunk size octets with other values are reserved for future + extensions. Implementations SHOULD NOT create data with a chunk size + octet value larger than 21 (128 MiB chunks) to facilitate buffering of + not yet authenticated plaintext. ** Explict warning reading the AEAD IV: A new random initialization vector MUST be used for each message. + Failure to do so for each message will lead to a catastrophic failure + depending on the used AEAD mode. ** More pressure to use AEAD: - This attack can be defeated by the use of Modification Detection, + This attack can be defeated by the use of modification detection, provided that the implementation does not let the user naively - return the data to the attacker. An implementation MUST treat an MDC - failure as a security problem, not merely a data problem. - - In either case, the implementation MAY allow the user access to the - erroneous data, but MUST warn the user as to potential security - problems should that data be returned to the sender. + return the data to the attacker. The modification detection is + prefereabble implemented by using the AEAD Encrypted Data Packet + and only if the recipients don't supports this by use of the + Symmmetric Encrypted and Integrity Protected Data Packet. An + implementation MUST treat an authentication or MDC failure as a + security problem, not merely a data problem. + + In either case, the implementation SHOULD NOT allow the user + access to the erroneous data, and MUST warn the user as to + potential security problems should that data be returned to the + sender. and changed the following suggestion to read permits someone to trick a user to decrypt a message. Consequently, it is important that: 1. Implementers treat authentication errors, MDC errors, decompression failures or no use of MDC or AEAD as security problems. 2. Implementers implement AEAD with all due speed and encourage its spread. 3. Users migrate to implementations that support AEAD encryption with all due speed. ** Clarify / cleanup OCB section, add EAX and OCB test vectors --8<---------------cut here---------------end--------------->8--- See also git@gitlab.com/openpgp-wg/rfc4880bis Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=security_lynch_Project_Monarch_Gazprom_Merlin_COSCO_TELINT_AMEMB_Rul Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCW1bWQQAKCRD/gK6dHew1 jdJ0AQDvaASruqDpYBS/Sp6P8srQ3EvX1+LWwU/BGQW76ElF6AEA/qtWWa5EmLYU JjjhWHuzchOMZYmPD4Bf6/wKGoiBqwg= =G46c -----END PGP SIGNATURE----- --=security_lynch_Project_Monarch_Gazprom_Merlin_COSCO_TELINT_AMEMB_Rul-- From nobody Tue Jul 24 04:57:47 2018 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 39163130E63 for ; Tue, 24 Jul 2018 04:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 6p0GR3BaShEc for ; Tue, 24 Jul 2018 04:57:43 -0700 (PDT) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29C281292AD for ; Tue, 24 Jul 2018 04:57:42 -0700 (PDT) Received: from computer ([2001:2012:127:3e00:ff5e:3a82:43d7:a6d6]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Tue, 24 Jul 2018 13:57:40 +0200 id 000000000000012C.000000005B571434.000027BA Date: Tue, 24 Jul 2018 13:57:44 +0200 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: openpgp@ietf.org Message-ID: <20180724135744.6972c8d3@computer> In-Reply-To: <87va95f5q6.fsf@wheatstone.g10code.de> References: <87va95f5q6.fsf@wheatstone.g10code.de> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-10170-1532433460-0001-2" Archived-At: Subject: Re: [openpgp] Need to publish bis-05 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 11:57:47 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zucker.schokokeks.org-10170-1532433460-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, On Tue, 24 Jul 2018 09:33:21 +0200 Werner Koch wrote: > ** Limit the chunk size of AEAD packets: >=20 > An implementation MUST support chunk size octets with values from 0 > to 56. Chunk size octets with other values are reserved for future > + extensions. Implementations SHOULD NOT create data with a chunk > size > + octet value larger than 21 (128 MiB chunks) to facilitate buffering > of > + not yet authenticated plaintext. This does not seem to reflect the lessons to be learned from efail. I think it is very important to hard-restrict the chunk size to a manageable size, also manageable for small devices (i.e. even 128 mb is far too much), so that authenticating before any output is produced is always feasible. I.e. I propose to change it to a MUST NOT and to have a smaller maximum chunk size (I think something in the kilobyte range is a good choice). --=20 Hanno B=C3=B6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 --=_zucker.schokokeks.org-10170-1532433460-0001-2 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEn3wfQCCb9MicJwD8dkhfABMwL8oFAltXFDgACgkQdkhfABMw L8pJyQ/+IYs3rA8X9d7qsdPjNw06o6KZNK28wEWElSkh7Mel4WNfgqrAnG2EksI7 ABLaDV7IpEsfY7ds3R/eAjpN7E8i1lCzA6fOKoXdRE1wcyMVO2Ayl383WRst2/uH wtSWEfmHJOvzPGX9RSR+X94sszM5KfjcZFCJCPzeQ/6iSTZhJonDh6/5CuBMtrEW yKHiqgSPPoUCWifp5F1t3rgAeWMZhbC17WxvZg+GYySGA9L75fwiMp3MpGDPdJJR H1d20FHFgvhHBIhCBLeK4bFZhyAt/1dicx6bP4/43WdXv1Nf1f7izPxIw2xYXp+Y IzAFKMLSVW7TH7VNKf/oD/sJRmLS1WWFLBNEdt0pPt6Khq5zKZzkcXwHm6sInyRd E4eeaSmAX+fJZSsUorI+D7b7695Og0v4dPbireQ/ZbGscK42wtdUU/nJdD8yC91Y BorLZyCvXKsJPUlqvTAV4f7xl/eFG/L/LXmI++pXQGxjtV8aoBLaQDqSeILHIhNH Y9aATugyyhm8dxcWfyDgjmYxHIPgo9nhLO5CxRiPrFN3BBnTmtHGA5FvFG3C0e0Y oNp0gPr3kR6ioUfXlcHuhpm0Igv8DOmAWorF5eM4ksHw6yiN16zfE8tMtxSgT+8t NDUR4OeEFyAA3qnfjOUTig3dQ4mTUueXMrMOatgxjUY3nKZW80o= =cYEm -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-10170-1532433460-0001-2-- From nobody Tue Jul 24 08:03:52 2018 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 48D35131117 for ; Tue, 24 Jul 2018 08:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 69G_MwlSkzld for ; Tue, 24 Jul 2018 08:03:47 -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 92DC2131110 for ; Tue, 24 Jul 2018 08:03:47 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1fhyqn-00082W-Gz for ; Tue, 24 Jul 2018 17:03:45 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1fhyee-0000BE-Oe; Tue, 24 Jul 2018 16:51:12 +0200 From: Werner Koch To: Hanno =?utf-8?Q?B=C3=B6ck?= Cc: openpgp@ietf.org References: <87va95f5q6.fsf@wheatstone.g10code.de> <20180724135744.6972c8d3@computer> Organisation: GnuPG e.V. X-message-flag: Mails containing HTML will not be read! Please send only plain text. Mail-Followup-To: Hanno =?utf-8?Q?B=C3=B6ck?= , openpgp@ietf.org Date: Tue, 24 Jul 2018 16:51:12 +0200 In-Reply-To: <20180724135744.6972c8d3@computer> ("Hanno =?utf-8?Q?B=C3=B6c?= =?utf-8?Q?k=22's?= message of "Tue, 24 Jul 2018 13:57:44 +0200") Message-ID: <87in54g00v.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=kilderkin_chameleon_man_class_struggle_NATO_ammunition_e-bomb_DRM=Gu"; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] Need to publish bis-05 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 15:03:50 -0000 --=kilderkin_chameleon_man_class_struggle_NATO_ammunition_e-bomb_DRM=Gu Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, 24 Jul 2018 13:57, hanno@hboeck.de said: > This does not seem to reflect the lessons to be learned from efail. Sorry, that remark does not make any sense. We have explained in detail why it was bot possible to hard fail on MDC and we can do this only know with the =E2=80=9Csupport=E2=80=9D of EFFail. The major points of Efail ar= e bad integration and in-correct use of tools. You can shoot into your foot even with simple standard toools like cat. > I think it is very important to hard-restrict the chunk size to a > manageable size, also manageable for small devices (i.e. even 128 mb is > far too much), so that authenticating before any output is produced is If you have a small device you don't have a way to store large amounts of data and thus even a lower limit does not make sense because it won't be reached. The only option an implementation hast to trow up the hands and say : message too large to decrypt. That is even before checking the message. > I.e. I propose to change it to a MUST NOT and to have a smaller > maximum chunk size (I think something in the kilobyte range is a good A kilobyte is - sorry I have no other words for this - stupid. We are talking about gigs and not a single memory page. I think 128 MiB is a good compromise - in particular for small device which suffer more for the expensive steps of the chunk processing. For large amounts of data that is acceptable high. Salam-Shalom, Werner =2D-=20 # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=kilderkin_chameleon_man_class_struggle_NATO_ammunition_e-bomb_DRM=Gu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTX/8BjtAoilLlm20f/gK6dHew1jQUCW1c84AAKCRD/gK6dHew1 jV6LAP46HR6Pxn92wZDLxE+UryWWq90mVYkqjMg8ShD1Ywjx2gD9G2qR/QgZHjzn r9G5ufYT5TWng0nGwjVvsoVyZEqW9gY= =XxKO -----END PGP SIGNATURE----- --=kilderkin_chameleon_man_class_struggle_NATO_ammunition_e-bomb_DRM=Gu-- From nobody Thu Jul 26 02:01:47 2018 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 7C094130E5F for ; Thu, 26 Jul 2018 02:01:45 -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 A9gMuCT1nM5l for ; Thu, 26 Jul 2018 02:01:41 -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 6B6B2130F73 for ; Thu, 26 Jul 2018 02:01:41 -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 41bmLG6J6dz4xXM for ; Thu, 26 Jul 2018 11:01:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ruhr-uni-bochum.de; s=mail-2017; t=1532595702; bh=t08P5SYk/8Ln89OX2I4Y751pnj0pcgyjbQW61yg1lLw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=lLm9wvIk/8PUmRvBvANF5FmNzJu6l64dcWYHYzw2QQZ42XCe9to2fH2lmHDn9ndnh rP7e4xU5doXraDTE5+9vOwRpC76qC2oYJaOGHOmTMQM16kI9t+33tcNbJIzx5NzwjA wUQBtCxLMC6KrSrKNhntvGfSsrJMYNnO54rQIl/I= 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 41bmLG5YX8z4yJp for ; Thu, 26 Jul 2018 11:01:42 +0200 (CEST) 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 41bmLF3hYCz4yKg for ; Thu, 26 Jul 2018 11:01:41 +0200 (CEST) Received: from [192.168.142.139] (p5B049981.dip0.t-ipconnect.de [91.4.153.129]) by mail1.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 41bmJj2JjCzysB for ; Thu, 26 Jul 2018 11:00:21 +0200 (CEST) To: openpgp@ietf.org References: <87va95f5q6.fsf@wheatstone.g10code.de> From: Marcus Brinkmann Openpgp: preference=signencrypt Message-ID: <8952ea67-4a6e-95ab-67c2-8d61c3dd2a1f@ruhr-uni-bochum.de> Date: Thu, 26 Jul 2018 11:00:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: <87va95f5q6.fsf@wheatstone.g10code.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] Need to publish bis-05 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 09:01:46 -0000 The new wording for the AEAD chunk size makes it logically impossible to write a conforming implementation that guarantees to never output or process unauthenticated plaintext. This is a serious security concern, which is addressed by state of the art standards like TLS 1.3, and for which there was rough consensus on this list. Here is the reason that it is impossible for conforming implementations to always be secure: * The draft requires implementations to support chunks up to 4 Exibyte ("An implementation MUST support chunk size octets with values from 0 to 56"). * It is impossible to buffer 4 Exbyte on any device or system that is not planet-scale. Thus, any conforming implementation must have a chunk size that must be supported for which it can not buffer the whole chunk. For that chunk size, the implementation must either abort (resulting in non-conforming behaviour) or output unauthenticated data (resulting in non-secure behaviour). This is in stark contrast to the original proposal, which had valid chunk sizes between 64 Byte and 64 KiB, all of which can be supported securely on a wide range of devices. Multiple people expressed support for that approach. On 07/24/2018 09:33 AM, Werner Koch wrote: > Hi > > -04 is about to expire. These will be the changes in -05: > > --8<---------------cut here---------------start------------->8--- > ** New key flag: > > # The second octet: > > + 0x04 - This key may be used as an additional decryption subkey (ADSK). > > # The idea is that implementations will also encrypt to a second subkey > # which for example is used on a second device. I am not sure whether > # this is suitable solution and makes much sense so this is intended as a > # bait for discussion. > > ** Deprecation of Symmetrically Encrypted Data Packet > > + This packet is obsolete. An implementation MUST not create this > + packet. An implementation MAY process such a packet but it MUST > + return a clear diagnostic that a non-integrity protected packet has > + been processed. The implementation SHOULD also return an error in > + this case and stop processing. > > ** Limit the chunk size of AEAD packets: > > An implementation MUST support chunk size octets with values from 0 to > 56. Chunk size octets with other values are reserved for future > + extensions. Implementations SHOULD NOT create data with a chunk size > + octet value larger than 21 (128 MiB chunks) to facilitate buffering of > + not yet authenticated plaintext. > > ** Explict warning reading the AEAD IV: > > A new random initialization vector MUST be used for each message. > + Failure to do so for each message will lead to a catastrophic failure > + depending on the used AEAD mode. > > ** More pressure to use AEAD: > > - This attack can be defeated by the use of Modification Detection, > + This attack can be defeated by the use of modification detection, > provided that the implementation does not let the user naively > - return the data to the attacker. An implementation MUST treat an MDC > - failure as a security problem, not merely a data problem. > - > - In either case, the implementation MAY allow the user access to the > - erroneous data, but MUST warn the user as to potential security > - problems should that data be returned to the sender. > + return the data to the attacker. The modification detection is > + prefereabble implemented by using the AEAD Encrypted Data Packet > + and only if the recipients don't supports this by use of the > + Symmmetric Encrypted and Integrity Protected Data Packet. An > + implementation MUST treat an authentication or MDC failure as a > + security problem, not merely a data problem. > + > + In either case, the implementation SHOULD NOT allow the user > + access to the erroneous data, and MUST warn the user as to > + potential security problems should that data be returned to the > + sender. > > and changed the following suggestion to read > > permits someone to trick a user to decrypt a message. Consequently, > it is important that: > > 1. Implementers treat authentication errors, MDC errors, > decompression failures or no use of MDC or AEAD as security > problems. > > 2. Implementers implement AEAD with all due speed and encourage > its spread. > > 3. Users migrate to implementations that support AEAD > encryption with all due speed. > > > ** Clarify / cleanup OCB section, add EAX and OCB test vectors > --8<---------------cut here---------------end--------------->8--- > > > See also git@gitlab.com/openpgp-wg/rfc4880bis > > > Shalom-Salam, > > Werner > > > -- > # Please read: Daniel Ellsberg - The Doomsday Machine # > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > From nobody Fri Jul 27 00:53:55 2018 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 1837F130DC9 for ; Fri, 27 Jul 2018 00:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.65 X-Spam-Level: X-Spam-Status: No, score=-6.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_HI=-5] 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 HapR--T3H3Ry for ; Fri, 27 Jul 2018 00:53:51 -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 A3C4F12F295 for ; Fri, 27 Jul 2018 00:53:51 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1fixZN-0006xl-R6 for ; Fri, 27 Jul 2018 09:53:49 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1fixN3-0005h8-Uq for ; Fri, 27 Jul 2018 09:41:05 +0200 Resent-To: openpgp@ietf.org Resent-From: Werner Koch Resent-Date: Fri, 27 Jul 2018 09:41:05 +0200 Resent-Message-ID: <876011azxq.fsf@wheatstone.g10code.de> Received: from uucp by wheatstone.g10code.de with local-rmail (Exim 4.84 #3 (Debian)) id 1fimou-0002TN-LS for ; Thu, 26 Jul 2018 22:25:08 +0200 Received: from mail.ietf.org ([2001:1900:3001:11::2c]) by kerckhoffs.g10code.com with esmtps (Exim 4.89 #1 (Debian)) id 1fimvq-0003oO-7s for ; Thu, 26 Jul 2018 22:32:18 +0200 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7377E130ED2 for ; Thu, 26 Jul 2018 12:15:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: "Werner Koch" X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153263251346.24798.5273179663142259681.idtracker@ietfa.amsl.com> Date: Thu, 26 Jul 2018 12:15:13 -0700 X-Sender-Host: mail.ietf.org Archived-At: Subject: [openpgp] New Version Notification for draft-ietf-openpgp-rfc4880bis-05.txt X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.27 List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 07:53:54 -0000 A new version of I-D, draft-ietf-openpgp-rfc4880bis-05.txt has been successfully submitted by Werner Koch and posted to the IETF repository. Name: draft-ietf-openpgp-rfc4880bis Revision: 05 Title: OpenPGP Message Format Document date: 2018-07-26 Group: Individual Submission Pages: 123 URL: https://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc4880bis-05.txt Status: https://datatracker.ietf.org/doc/draft-ietf-openpgp-rfc4880bis/ Htmlized: https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-05 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-rfc4880bis Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-openpgp-rfc4880bis-05 Abstract: { Work in progress to update the OpenPGP specification from RFC4880 } This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Fri Jul 27 12:10:14 2018 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 59A94124D68 for ; Fri, 27 Jul 2018 12:10:12 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 N7J-8Cv5ab-K for ; Fri, 27 Jul 2018 12:10:09 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::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 39C37130DBE for ; Fri, 27 Jul 2018 12:10:09 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 41cdnq0jrczKHW; Fri, 27 Jul 2018 21:10:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1532718607; bh=zd43Q+L4da5K8C1L/NsQe3Re8eAmHE/9++6g7z6v70g=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=OsB/UKGUwDG9/pTpQO8EPJ2vuwA5FuVj2/whLFMW8FU3/ObDzlaRXA8oAnp3TrZRY qddyDwVmd3PM/fLj7qf8+o11OPEEI6kL+nM63AuTtcBN0CHNv5jj1iut2i3H++plxV KJ9jCa1ji0W8TMa6VrJa0s1Dfw1a/LAfukuJDMLA= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 09fm7R1qSjg1; Fri, 27 Jul 2018 21:10:03 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 27 Jul 2018 21:10:02 +0200 (CEST) Received: from [192.168.1.73] (23-118-109-227.lightspeed.sntcca.sbcglobal.net [23.118.109.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 606A2381FC8; Fri, 27 Jul 2018 15:10:01 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 606A2381FC8 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (15G77) In-Reply-To: <153263251346.24798.5273179663142259681.idtracker@ietfa.amsl.com> Date: Fri, 27 Jul 2018 12:09:54 -0700 Cc: Werner Koch Content-Transfer-Encoding: quoted-printable Message-Id: <05AD686F-CB7C-41A1-85E2-EB721388B3C7@nohats.ca> References: <153263251346.24798.5273179663142259681.idtracker@ietfa.amsl.com> To: openpgp@ietf.org Archived-At: Subject: Re: [openpgp] New Version Notification for draft-ietf-openpgp-rfc4880bis-05.txt X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 19:10:12 -0000 Sad to see the size issue people discussed here to have been dismissed by th= is update. It will lead to people ignoring the requirement or to people looking for an a= lternative solution for IoT things. Paul Sent from my phone > On Jul 26, 2018, at 12:15, internet-drafts@ietf.org wrote: >=20 >=20 > A new version of I-D, draft-ietf-openpgp-rfc4880bis-05.txt > has been successfully submitted by Werner Koch and posted to the > IETF repository. >=20 > Name: draft-ietf-openpgp-rfc4880bis > Revision: 05 > Title: OpenPGP Message Format > Document date: 2018-07-26 > Group: Individual Submission > Pages: 123 > URL: https://www.ietf.org/internet-drafts/draft-ietf-openpgp-rf= c4880bis-05.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-openpgp-rfc488= 0bis/ > Htmlized: https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-= 05 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-r= fc4880bis > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-openpgp-rfc= 4880bis-05 >=20 > Abstract: > { Work in progress to update the OpenPGP specification from RFC4880 } >=20 > This document is maintained in order to publish all necessary > information needed to develop interoperable applications based on the > OpenPGP format. It is not a step-by-step cookbook for writing an > application. It describes only the format and methods needed to > read, check, generate, and write conforming packets crossing any > network. It does not deal with storage and implementation questions. > It does, however, discuss implementation issues necessary to avoid > security flaws. >=20 > OpenPGP software uses a combination of strong public-key and > symmetric cryptography to provide security services for electronic > communications and data storage. These services include > confidentiality, key management, authentication, and digital > signatures. This document specifies the message formats used in > OpenPGP. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submissi= on > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 >=20 > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp From nobody Fri Jul 27 12:17:43 2018 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 17D54128CF3 for ; Fri, 27 Jul 2018 12:17:42 -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 O-RhrxwqH05I for ; Fri, 27 Jul 2018 12:17:39 -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 24B79127AC2 for ; Fri, 27 Jul 2018 12:17:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id DD1D8E2040; Fri, 27 Jul 2018 15:17:37 -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 30552-10; Fri, 27 Jul 2018 15:17:32 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 6FAF2E2046; Fri, 27 Jul 2018 15:17:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1532719052; bh=IFEQ3Sws7kfNuVuuMoJEe7fNPzVXpq5fw7CrIVAxOeE=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=nc/VbcGldABIH/Boh+jAtIfA/GcNel2yVU714YtdvYE1iJQijUGNA3NT4AXzY/vAB 8N+jhkRZX1Bp2Aiksim021N95ZiWZ/nmLYwdgm8dkp7KK7Wr3liZIIM4K4l1MV/bZG Rb6+oXZEMZvSsNl4qfdAp84WcIi1iM+nBwnzcjKI= Received: from 192.168.248.158 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Fri, 27 Jul 2018 15:17:32 -0400 Message-ID: In-Reply-To: <05AD686F-CB7C-41A1-85E2-EB721388B3C7@nohats.ca> References: <153263251346.24798.5273179663142259681.idtracker@ietfa.amsl.com> <05AD686F-CB7C-41A1-85E2-EB721388B3C7@nohats.ca> Date: Fri, 27 Jul 2018 15:17:32 -0400 From: "Derek Atkins" To: "Paul Wouters" Cc: openpgp@ietf.org, "Werner Koch" 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] New Version Notification for draft-ietf-openpgp-rfc4880bis-05.txt X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 19:17:42 -0000 Paul -- don't throw out the baby with the bathwater. Just because the change didn't make it into this version of the fraft doesn't mean it wont change. The conversation is, IMHO, far from over on the topic, but Werner needed to get an update published so it didn't expire. So by all means, please continue the conversation. Personally, I believe that a 2^56 block size is WAYYY to big. Or even a 56-bit encoded block size. I think blocks should be limited to 32 bits, and recomended to be smaller. On the other hand, a 1K block is IMHO way too small for the default. I think we need a happy medium. Considering the size is upfront, a small device can know a priori whether or not it can cache the block, so it should be able to fail early if it gets a block too big to process. And I think that's okay. -derek On Fri, July 27, 2018 3:09 pm, Paul Wouters wrote: > Sad to see the size issue people discussed here to have been dismissed by > this update. > > It will lead to people ignoring the requirement or to people looking for > an alternative solution for IoT things. > > Paul > > Sent from my phone > >> On Jul 26, 2018, at 12:15, internet-drafts@ietf.org wrote: >> >> >> A new version of I-D, draft-ietf-openpgp-rfc4880bis-05.txt >> has been successfully submitted by Werner Koch and posted to the >> IETF repository. >> >> Name: draft-ietf-openpgp-rfc4880bis >> Revision: 05 >> Title: OpenPGP Message Format >> Document date: 2018-07-26 >> Group: Individual Submission >> Pages: 123 >> URL: >> https://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc4880bis-05.txt >> Status: >> https://datatracker.ietf.org/doc/draft-ietf-openpgp-rfc4880bis/ >> Htmlized: >> https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-05 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-rfc4880bis >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-openpgp-rfc4880bis-05 >> >> Abstract: >> { Work in progress to update the OpenPGP specification from RFC4880 } >> >> This document is maintained in order to publish all necessary >> information needed to develop interoperable applications based on the >> OpenPGP format. It is not a step-by-step cookbook for writing an >> application. It describes only the format and methods needed to >> read, check, generate, and write conforming packets crossing any >> network. It does not deal with storage and implementation questions. >> It does, however, discuss implementation issues necessary to avoid >> security flaws. >> >> OpenPGP software uses a combination of strong public-key and >> symmetric cryptography to provide security services for electronic >> communications and data storage. These services include >> confidentiality, key management, authentication, and digital >> signatures. This document specifies the message formats used in >> OpenPGP. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> >> _______________________________________________ >> openpgp mailing list >> openpgp@ietf.org >> https://www.ietf.org/mailman/listinfo/openpgp > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Jul 27 13:01:15 2018 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 1B57B130DF5 for ; Fri, 27 Jul 2018 13:01:12 -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=unavailable 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 Bx08de3Rl2KP for ; Fri, 27 Jul 2018 13:01:10 -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 C6CDE130DD1 for ; Fri, 27 Jul 2018 13:01:10 -0700 (PDT) Received: from genre.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:f1fc:eee3:60de:bdd8]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by injection.crustytoothpaste.net (Postfix) with ESMTPSA id EA6506046C; Fri, 27 Jul 2018 20:00:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net; s=default; t=1532721638; bh=l5f9EYnCThzYm6W6pY3qFNlWGv/vtEZA8v/bcOz5F8M=; 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=PyQTAIMh7RWblpoYKPYqrMXnAn4lrWFx9RnSF+nBUaREz62BUmwJverzyHCk99K98 t1DKrBlnKpvmev+kKLAYq93o2GFRBh80HhCpXx8YQB2tseiZuC6RhP7MjxbiHJctnG TmmRVHSsTjW7cHIn3uS0d/M8uO4Ig+9g2fH2/E9H4fgAT9FkvylHF3jHE53NJI0Ruk bHQ3lMUiA2m/uzXIReJxY2FI9FjThhjLHBc9jClIRPyMjuRGzi4SAhpewkXYr+TDj+ RkiGU1Dh4tvIYcd/MWObemmhuACeCxOqUroUYQJhO/ayYkp82ABLCkPYCWbQ4pv1YK 4u8xeW0PVWAt8YuKtOT1PJg/Y9jql8CBlScahpusCWbyLIlPe2R1Xmq3K1/yrFC6H5 WiNlRz6ONl0ZHtj/RE9W+UuA+MUTzW7S5pReqdrSPpWGKuQwnDt7nxmQI+XLvT9NHp niGFvUBb0lSSd3IUDZ3wHyowEXmXwgCjjD7HE6rrC9rlSmxwcY5 Date: Fri, 27 Jul 2018 20:00:33 +0000 From: "brian m. carlson" To: Marcus Brinkmann Cc: openpgp@ietf.org Message-ID: <20180727200033.GA376343@genre.crustytoothpaste.net> References: <87va95f5q6.fsf@wheatstone.g10code.de> <8952ea67-4a6e-95ab-67c2-8d61c3dd2a1f@ruhr-uni-bochum.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline In-Reply-To: <8952ea67-4a6e-95ab-67c2-8d61c3dd2a1f@ruhr-uni-bochum.de> X-Machine: Running on genre using GNU/Linux on x86_64 (Linux kernel 4.17.0-1-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] Need to publish bis-05 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 20:01:12 -0000 --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 26, 2018 at 11:00:21AM +0200, Marcus Brinkmann wrote: > The new wording for the AEAD chunk size makes it logically impossible to > write a conforming implementation that guarantees to never output or > process unauthenticated plaintext. This is a serious security concern, > which is addressed by state of the art standards like TLS 1.3, and for > which there was rough consensus on this list. >=20 > Here is the reason that it is impossible for conforming implementations > to always be secure: >=20 > * The draft requires implementations to support chunks up to 4 Exibyte > ("An implementation MUST support chunk size octets with values from 0 to > 56"). > * It is impossible to buffer 4 Exbyte on any device or system that is > not planet-scale. >=20 > Thus, any conforming implementation must have a chunk size that must be > supported for which it can not buffer the whole chunk. For that chunk > size, the implementation must either abort (resulting in non-conforming > behaviour) or output unauthenticated data (resulting in non-secure > behaviour). >=20 > This is in stark contrast to the original proposal, which had valid > chunk sizes between 64 Byte and 64 KiB, all of which can be supported > securely on a wide range of devices. Multiple people expressed support > for that approach. I agree that we should lower this. I happen to think the overhead involved in 64 KiB chunks isn't that significant, but if that's a concern, we could raise it to 1 MiB. I'd like to point out, though, that I suggested a smaller chunk size because that's what TLS has traditionally done: most TLS implementations don't allow the full 16 MiB chunk size for DoS reasons. Even if we do allow large chunk sizes, I expect most implementations will limit them for security and DoS reasons, in which case we'll end up with the same effective behavior, but poorer interoperability. On almost any reasonable system with AES acceleration, encryption throughput is faster than disk or gigabit network, so I hardly think the encryption overhead is painful here, even for smaller ARM systems. --=20 brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 --BOKacYhQ+x31HxR3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.2.9 (GNU/Linux) iQIzBAABCgAdFiEEX8OngXdrJt+H9ww3v1NdgR9S9osFAltbeeAACgkQv1NdgR9S 9ovLWRAAhxdBJL1TiICeuFA0129YGPkE0K+cA/UoRJ0tSRpTFk2UD05ljdSTVB3W xdyFh96G/XIJ0L7UNBpvA+K8Qs7nxD1x8c3wMJx6cBPP6lKFF3hvu8PKCX5k1Cqe ErEYfIPB0Bv5O2hPMc5XClrDoSrKWYNpvLjKuilCFmdhYNjxIwqhM+hvLQpalgXN CjMzeDgJvO2MhzwKc570usDy1kJSTv/0db5jvb7FbSIVXWRgn9aqprmBGWW/b0qb GMBEMuHqCZ1jmSZ2i1aibXaTRlTRBlxLIn+F4/GzOxo0btOBuiG0nkgXcyeJbZja Ad9a1Et6B6G4qg9m5pkzl177dav7Q5+5RQ8cSSpAV6VDWdYgT9sd18NHE333VU2O 9nh5znRz+eygLewNlBot5T/j80Yoph/KTXjGprcBdKjcGUsXnLn2f678ux2vYA7N B9PPL/8cIMTt5HQQyOBifXZP/SYZBnMHDqa0GAMsFtP7PuTwQhlnNybK9wGV7hQD yA+nu0LfKSCYE2yT9OywAk/UsRWExAfWmuBxalAtqHly3lwd1hxu1CZn/f0aTx+k PPkrvbswnwUcBPvlDc3ls4Z8crH1tHO132udL4OX9sbS/fjaSMbch5cz9AYOi073 h2QRT6E/eorSNh6ho5uK/cMfM2CINVSFRq7KlTkVLPpSREdBO0k= =ZJ0u -----END PGP SIGNATURE----- --BOKacYhQ+x31HxR3-- From nobody Fri Jul 27 13:20:43 2018 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 1D0D2130DF5 for ; Fri, 27 Jul 2018 13:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, 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 EWgnEd-56EAx for ; Fri, 27 Jul 2018 13:20:39 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 9FE02130E10 for ; Fri, 27 Jul 2018 13:20:39 -0700 (PDT) X-AuditID: 1209190f-227ff70000003a9f-8e-5b5b7e960507 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id A6.E2.15007.69E7B5B5; Fri, 27 Jul 2018 16:20:38 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w6RKKaBY015243; Fri, 27 Jul 2018 16:20:37 -0400 Received: from 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.13.8/8.12.4) with ESMTP id w6RKKWM4029953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 Jul 2018 16:20:35 -0400 Date: Fri, 27 Jul 2018 15:20:32 -0500 From: Benjamin Kaduk To: "brian m. carlson" Cc: Marcus Brinkmann , openpgp@ietf.org Message-ID: <20180727202032.GJ12983@mit.edu> References: <87va95f5q6.fsf@wheatstone.g10code.de> <8952ea67-4a6e-95ab-67c2-8d61c3dd2a1f@ruhr-uni-bochum.de> <20180727200033.GA376343@genre.crustytoothpaste.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="/Uq4LBwYP4y1W6pO" Content-Disposition: inline In-Reply-To: <20180727200033.GA376343@genre.crustytoothpaste.net> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFKsWRmVeSWpSXmKPExsUixG6nrjutLjra4Ow5IYv+eTEWDf8eslu0 zfzB5MDssfzmXyaPE8uusHosWfKTKYA5issmJTUnsyy1SN8ugStj8uOUglX8FVPmzGJqYJzF 28XIySEhYCKx6d1Vpi5GLg4hgcVMEncX32GEcDYySkxeuRPKOcsksf/JN6AyDg4WAVWJ2b0R IN1sAioSDd2XmUFsEQFTiSXv9zGB2MwCaRI3lz8Fs4UFdCVWtV5nBbF5BXQkLk+cyAIxcymj xOepc1ggEoISJ2c+YYFoLpPYu/g7K8guZgFpieX/OEDCnAKOEjuuvgPbJSqgLLG37xD7BEaB WUi6ZyHpnoXQDRHWkrjx7yUThrC2xLKFr5khbFuJdevesyxgZF/FKJuSW6Wbm5iZU5yarFuc nJiXl1qka6KXm1mil5pSuokRFBWckvw7GOc0eB9iFOBgVOLhvWATHS3EmlhWXJl7iFGSg0lJ lPdCAVCILyk/pTIjsTgjvqg0J7X4EKMK0K5HG1ZfYJRiycvPS1US4RVWAarjTUmsrEotyocp k+ZgURLnvVcTHi0kkJ5YkpqdmlqQWgSTleHgUJLgVakFahQsSk1PrUjLzClBSDNxcB5ilODg ARrOBlLDW1yQmFucmQ6RP8Woy/Hn/dRJzEJgF0iJ84aBFAmAFGWU5sHNASU5iez9Na8YxYFe FObdXANUxQNMkHCTXgEtYQJacjwuEmRJSSJCSqqBcWG24dz8I7J7JZ8sEnnY2+kv0S64pYl3 WuQ83403lvHP4rQTLHjBZ3/ew/y7ZcfKzZ4dyWdeahjmZM79qbvQLTh8CT/L48LMiqW5jZc9 BJzKZzrM+3B3WmpY9tf7nCYTqmakyG9Wysu177Jve1W+6PT3n1z61/kfyuw4cbdJ7rXzl3SH 76y+SizFGYmGWsxFxYkA7Ycpl00DAAA= Archived-At: Subject: Re: [openpgp] Need to publish bis-05 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 20:20:41 -0000 --/Uq4LBwYP4y1W6pO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 27, 2018 at 08:00:33PM +0000, brian m. carlson wrote: >=20 > I agree that we should lower this. I happen to think the overhead > involved in 64 KiB chunks isn't that significant, but if that's a > concern, we could raise it to 1 MiB. I'd like to point out, though, > that I suggested a smaller chunk size because that's what TLS has > traditionally done: most TLS implementations don't allow the full 16 MiB > chunk size for DoS reasons. Can you expound on this more? It does not match my understanding of the TLS ecosystem. (Also, isn't it 16K?) Thanks, Ben > Even if we do allow large chunk sizes, I expect most implementations > will limit them for security and DoS reasons, in which case we'll end up > with the same effective behavior, but poorer interoperability. >=20 > On almost any reasonable system with AES acceleration, encryption > throughput is faster than disk or gigabit network, so I hardly think the > encryption overhead is painful here, even for smaller ARM systems. --/Uq4LBwYP4y1W6pO Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQG3BAABCgAdFiEE2WGV4E2ARf9BYP0XKNmm82TrdRIFAltbfowACgkQKNmm82Tr dRJQ5gwfS/HRhKVFAURU2hUxxGG9nq2tXFlGLiNEIzFvw4EgIDrZg0wszZOCtcVa z5NnHaLGeQIQg4fi/QPZvpulFFI2fdASsFdJmdsu7WHwTLVTkKYbQmM+RFFFXALq ZCLL4nQ6OvzMsbUqAUTMaSV2NHmmgvsDnravkC/OGfuomPMBRz02uZnfMvrVVRY4 PbU1wF4TPd28cQe4+3mybw3hX5yRg25oP0dPvFbhUCo/AkyWIsrhppWnESf/HQ14 o6pAUlUUDHtnTXqu7q1sq6ExEZbY3fVzraWyD79gNr9UYUQ5DPguL69UXsip+HIp rK+K/YD6IdUSztR+DJ4sDu7wRRUIH/QS1sXrH6qTJvCvM6tz6OgE6yOKfC2a4t7G CV5HtFpf4TVq0Zsl9Mef4cSO5zVL1BEm2NlsXwhCClIU2LJXrbQEANHWHR81wHcO BUgvkns3dI2+ju49PRX/1NWtgHEhebMp7B1UgcCCHFdIDlIIvujqrF3Aln6atF+Q 9utRNLO+LERIXA== =pY1/ -----END PGP SIGNATURE----- --/Uq4LBwYP4y1W6pO-- From nobody Fri Jul 27 13:37:12 2018 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 E25C0130E10 for ; Fri, 27 Jul 2018 13:37:10 -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 (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 fAYTnv0nv92K for ; Fri, 27 Jul 2018 13:37:09 -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 21EE8129385 for ; Fri, 27 Jul 2018 13:37:09 -0700 (PDT) Received: from genre.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:f1fc:eee3:60de:bdd8]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by injection.crustytoothpaste.net (Postfix) with ESMTPSA id 71CDB6046C for ; Fri, 27 Jul 2018 20:37:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net; s=default; t=1532723827; bh=xDBjxz8NuJtbrPQuH7xhKhW/R/GJIGRHHrH0jN+TB5w=; h=Date:From:To: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=lvJB9XLCRQv0YOoNYTC/XsXWKHZzLsBunTT3p4iE57yWCRCjuvzJ3F8PfH2j7gXJ6 pn/e6zjgDtOLrkBuRPHTJAXQ13MaFm2g2PSDZG4bqS+XB2Uy+S60r3j6PJA2sd3+Uj wWU5N123E7fT8RZnVxzzYSc3g6oczByJTEgk0x9Gl+WRRhDyReQesAEgDSTLa4tPMk ZKl4FCTtNbu4peBEWIwIIxVhGolLFRVbZCKNaOEcHSHFCcZtolEYVrdfuMpxDXAf/K tfWqmvPDKLrRnLTRzy76dofI0bOeDkIreNqF39ackmbZHC9ya598M7T6gV+DgkY3iL bWyg0dxrU0BR4hsO8YRbjwJJ130Z7n+gvXKqWEpLz3Qrsm9Os42fNbVyOwjTld+ZuA So8QfQ3MNePbMPzmyqTvYcOfMkVglFOwDh/QLKv34ArqFlaQAZ+gCFKqGXZME504JW J84elsJtJUDUrwTj+nJf5GFvviOeB0T8D5gwsMfCfq3QeVr3g+r Date: Fri, 27 Jul 2018 20:37:02 +0000 From: "brian m. carlson" To: openpgp@ietf.org Message-ID: <20180727203702.GB376343@genre.crustytoothpaste.net> References: <87va95f5q6.fsf@wheatstone.g10code.de> <8952ea67-4a6e-95ab-67c2-8d61c3dd2a1f@ruhr-uni-bochum.de> <20180727200033.GA376343@genre.crustytoothpaste.net> <20180727202032.GJ12983@mit.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3uo+9/B/ebqu+fSQ" Content-Disposition: inline In-Reply-To: <20180727202032.GJ12983@mit.edu> X-Machine: Running on genre using GNU/Linux on x86_64 (Linux kernel 4.17.0-1-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] Need to publish bis-05 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 20:37:11 -0000 --3uo+9/B/ebqu+fSQ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 27, 2018 at 03:20:32PM -0500, Benjamin Kaduk wrote: > On Fri, Jul 27, 2018 at 08:00:33PM +0000, brian m. carlson wrote: > >=20 > > I agree that we should lower this. I happen to think the overhead > > involved in 64 KiB chunks isn't that significant, but if that's a > > concern, we could raise it to 1 MiB. I'd like to point out, though, > > that I suggested a smaller chunk size because that's what TLS has > > traditionally done: most TLS implementations don't allow the full 16 MiB > > chunk size for DoS reasons. >=20 > Can you expound on this more? It does not match my understanding of the > TLS ecosystem. (Also, isn't it 16K?) Ah, I believe I was misremembering. The chunk size for encryption is indeed 2^14 bytes; I think I was remembering the handshake messages, which are 2^24 bytes. OpenSSL at least does limit the size of the handshake messages, although, as you pointed out, not encrypted messages. Regardless, my (mistaken) impression was the reason for the original decision. I think we should pick values that are safe for all reasonable implementations, including smaller ones, and where possible, be willing to see what other protocol specifiers have done and learn =66rom their wisdom and mistakes. --=20 brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 --3uo+9/B/ebqu+fSQ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.2.9 (GNU/Linux) iQIzBAABCgAdFiEEX8OngXdrJt+H9ww3v1NdgR9S9osFAltbgm4ACgkQv1NdgR9S 9ou4ahAAoMKtL5mK/byQSeu9iZ6o/NEZDMAFPEgwnbXvcAtjNj4d1DpH+kIQvaoy 9w5xF71A4LHN4jdxpbQji7TbeuEC7RxyWjMZpzHygXUhXp6K6R3cckokCDSulbrf 46N9QIDoYPSDK8uR91MybwEvd+VVjAkTJyMdKqJzjm0kV9BTjoarW1z5oUEYMUsW 5rMaH50GgSTQlxhg4O3PG2nhTi8gFlEuSrhG+dlrNUCdCK+xxbExZIYRmfE4rTLg 9YLS+jAz1OxoU9lJhyOCFX5y3Xop8mOgaGhDf8W3icgKACzrN1f6SlBrpYM2fwh9 4keNQMcxBG3fvoXB1BdMJV4fnXJlkSu/oMMqfSIkriLesrDWMrIRvrQ3yNnTWMkg 9/2+qws0mMDhXf2bs6P9DGyaADW5aGBe5ivZL1Q9FD8B6568WEjg4aO6U/B6i55Z wX4Z9vQ1kxEzXxPCeZwNOvQZ26z2hq9sdR0i54j66OOB0SzdGwdcmVhknuTGYujP NaIwYkJX6rLY40M010isrXlWzWznAP3xXqL522V5hp5IleEhBteIWSwZzYwjZOt4 HisBfrJ86RhGPLlJUXng5ZsA2hSVTHhwOWAB6Vm6yJmxosUr7r/ns7M7Ybxjdhtc 9QUfeuOc5iej6rI0Z+epG0nNP03xyQBhbJkQykMkwoJD5fwmdhM= =vxFp -----END PGP SIGNATURE----- --3uo+9/B/ebqu+fSQ-- From nobody Fri Jul 27 13:42:27 2018 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 EB666130E2F for ; Fri, 27 Jul 2018 13:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 sTpkDsFDrxro for ; Fri, 27 Jul 2018 13:42:24 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 5790C130E10 for ; Fri, 27 Jul 2018 13:42:24 -0700 (PDT) X-AuditID: 12074424-10dff70000004129-26-5b5b83add450 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 29.A2.16681.EA38B5B5; Fri, 27 Jul 2018 16:42:22 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w6RKgKxB007560; Fri, 27 Jul 2018 16:42:20 -0400 Received: from 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.13.8/8.12.4) with ESMTP id w6RKgGCm003556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 Jul 2018 16:42:19 -0400 Date: Fri, 27 Jul 2018 15:42:16 -0500 From: Benjamin Kaduk To: "brian m. carlson" Cc: openpgp@ietf.org Message-ID: <20180727204216.GK12983@mit.edu> References: <87va95f5q6.fsf@wheatstone.g10code.de> <8952ea67-4a6e-95ab-67c2-8d61c3dd2a1f@ruhr-uni-bochum.de> <20180727200033.GA376343@genre.crustytoothpaste.net> <20180727202032.GJ12983@mit.edu> <20180727203702.GB376343@genre.crustytoothpaste.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fXStkuK2IQBfcDe+" Content-Disposition: inline In-Reply-To: <20180727203702.GB376343@genre.crustytoothpaste.net> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEKsWRmVeSWpSXmKPExsUixCmqrbuuOTra4MRtNYuGfw/ZLdpm/mBy YPJYfvMvk8eSJT+ZApiiuGxSUnMyy1KL9O0SuDLmtq1iKpgmXPHl+kLmBsYZAl2MnBwSAiYS vxuWsXQxcnEICSxmkpj8czMzhLORUeLf0aVQmbNMErNfrWEFaWERUJV4fa2BEcRmE1CRaOi+ zAxiiwiYSix5v4+pi5GDg1lAROL4jlSQsLCArsSq1utgrbwCOhI77j5ghZj5n1Hizfe/UAlB iZMzn7CA2MwCZRJP729kh5gjLbH8HwdImFPAUeLqobVgq0QFlCX29h1in8AoMAtJ9ywk3bMQ uiHCWhI3/r1kwhDWlli28DUzhG0rsW7de5YFjOyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdM31 cjNL9FJTSjcxgqKA3UVlB2N3j/chRgEORiUe3gs20dFCrIllxZW5hxglOZiURHkvFACF+JLy UyozEosz4otKc1KLDzGqAO16tGH1BUYplrz8vFQlEV5hFaA63pTEyqrUonyYMmkOFiVx3rs1 4dFCAumJJanZqakFqUUwWRkODiUJ3rAmoEbBotT01Iq0zJwShDQTB+chRgkOHqDhHxtBhhcX JOYWZ6ZD5E8x6nL8eT91ErMQ2AVS4rw3QIoEQIoySvPg5oCSmkT2/ppXjOJALwrzhoOs4wEm RLhJr4CWMAEtOR4XCbKkJBEhJdXAuHaahty5O+aNEnnZV1ZX9mvEztFhjZ/e1lP2wDPpcIyd wlWvSUINn2YHLLrr6Xn9Eaf55WsnkvbeWH059KjDHZsPjK5fJsyWbRbkPC+Y9DxD6b6r5H5F 2QcH9LvXl3PEndV1fTV7/nxBVht9ndel06PXNK6XY+Fn3Oh+ocJGZqVlN9ejA43ySizFGYmG WsxFxYkAwnmWaEUDAAA= Archived-At: Subject: Re: [openpgp] Need to publish bis-05 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 20:42:26 -0000 --fXStkuK2IQBfcDe+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 27, 2018 at 08:37:02PM +0000, brian m. carlson wrote: > On Fri, Jul 27, 2018 at 03:20:32PM -0500, Benjamin Kaduk wrote: > > On Fri, Jul 27, 2018 at 08:00:33PM +0000, brian m. carlson wrote: > > >=20 > > > I agree that we should lower this. I happen to think the overhead > > > involved in 64 KiB chunks isn't that significant, but if that's a > > > concern, we could raise it to 1 MiB. I'd like to point out, though, > > > that I suggested a smaller chunk size because that's what TLS has > > > traditionally done: most TLS implementations don't allow the full 16 = MiB > > > chunk size for DoS reasons. > >=20 > > Can you expound on this more? It does not match my understanding of the > > TLS ecosystem. (Also, isn't it 16K?) >=20 > Ah, I believe I was misremembering. The chunk size for encryption is > indeed 2^14 bytes; I think I was remembering the handshake messages, > which are 2^24 bytes. OpenSSL at least does limit the size of the > handshake messages, although, as you pointed out, not encrypted > messages. Thanks for clarifying (and looking it up!). > Regardless, my (mistaken) impression was the reason for the original > decision. I think we should pick values that are safe for all > reasonable implementations, including smaller ones, and where possible, > be willing to see what other protocol specifiers have done and learn > from their wisdom and mistakes. FWIW, I agree that we should have values safe for all reasonable implementations. -Ben --fXStkuK2IQBfcDe+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQG3BAABCgAdFiEE2WGV4E2ARf9BYP0XKNmm82TrdRIFAltbg6MACgkQKNmm82Tr dRKcGgwdFS9/pDcHeFXGCG9mwV1LYL1TTCpasdqZFo3nHVUXpFYOgdHgVlxQhy/3 AMVEOe7Jnpxrpixa8jOLJS6LuoX0YTKaYwv3ey7wGyPZ7hGZJcdL+dHMc91pncov Uhbg9inNyUpnnufXflsdPx7Bx4ZT+2DqmERpjJPvZ1mPWbkzV1EfZeg/xYz5sOLe VCf6dR9zXK9Sh6344N5baxlGIAajr6Tyc0Cow3visbGgri7AVNxt0hrxISfAVc0j fqHfl4ik/THlg7FWpcbQj9tAjN006C8kDkEpqKQUZkobROGX/ifksetgYnmBrquZ bKkC2o8HlX1c8aIYpTlpae5UT9nOFgJUnbyiZh0jOchTqy7KvLzsmDQGxYPVZd/T a1ugUMPxidESzMbUhXm7JFkYoeCKjzshdsqKkC+cUCaQ10NHmKf54ijsPtJPf+iv 5MnZEUBmiSSn0jGd0bhoF25C/D+vxcMa1XVbJ28sg1SaoMXTH1bGaT8JzNb3m6TM VdB4IJztsdLSYQ== =k/bN -----END PGP SIGNATURE----- --fXStkuK2IQBfcDe+--