From owner-ietf-openpgp@mail.imc.org Sat Mar 1 01:23:23 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F03CA28C285 for ; Sat, 1 Mar 2008 01:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jLl147glWJL for ; Sat, 1 Mar 2008 01:23:21 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 3AA8B28C2D7 for ; Sat, 1 Mar 2008 01:22:50 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m2197KXX049575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Mar 2008 02:07:20 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m2197K8h049574; Sat, 1 Mar 2008 02:07:20 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m2197I0S049566 for ; Sat, 1 Mar 2008 02:07:19 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 988604A95; Sat, 1 Mar 2008 10:03:15 +0100 (CET) Date: Sat, 1 Mar 2008 10:03:15 +0100 To: Andrey Jivsov Cc: ietf-openpgp@imc.org, David Crick Subject: Re: ECC in OpenPGP proposal Message-ID: <20080301090315.GB8868@epointsystem.org> References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C7FDEA.5070103@systemics.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V0207lvV8h4k8FAm" Content-Disposition: inline In-Reply-To: <47C8EB4B.9010909@brainhub.org> User-Agent: Mutt/1.5.9i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --V0207lvV8h4k8FAm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I think, Andrey makes a very important point here. The option to use 3DES symmetric encryption, SHA1 digest and ZLIB compression must remain open unt= il a formal process of phasing them out is initiated, with a clear road map. Right now, excluding these algorithms would break interoperability in a very bad way, as described by Andrey. Of course, SHA1 and 3DES are not without problems, but for most security-critical applications they are still perfectly adequate. Also note that prior to ECC, any symmetric cipher could have been matched with any public key algorithm, because the secure block size for asymmetric encryption algorithms (ElGamal and RSA) well exceeded the key sizes for symmetric block ciphers. The encryption of session keys with random padding has never been an issue. With ECC, this is no longer the case. For instance, 256-bit AES keys won't fit into one ECC ElGamal blocks, which are otherwise reasonably secure. Heck, even 3DES might be a little problematic, if 192-bit curves are used. Finally, I would like to draw the group's attention to a special need of moblie communication, that seems not to receive due attention. While it is true that computational power is less and less of an issue with mobile phones (although there are still plenty of under-powered devices in use and even in production), the message size issue is here to stay for much longer. In GSM networks, which are by far the most common around the globe, peer-to-peer messaging between handsets is done in 1120-bit chunks, for which operators charge money. Using an RFC4880-compliant format, even the shortest message using reasonably strong asymmetric encryption (1024-bit RSA), requires two chunks, which cost exactly twice as much for the sender (and in some North-American setups even the recipient) as a regular text message. Short public key and encrypted session key sizes of ECC may actually prove to be the primary driving force behind its adoptation in the mobile world, even if Moore's law renders low computational costs irrelevant. On Fri, Feb 29, 2008 at 09:36:11PM -0800, Andrey Jivsov wrote: >=20 > David Crick wrote: > ... > > > >The ecc-pre-6.txt's section 2 pretty much says "this is how to > >do ECC with AES," and we've said that this proposal is a "MAY." > >In a sense this is therefore some kind of a fork (sub-superset?) > >of 4880, so we're not concerned with 3DES (or CAST), and - as > >with DSA - we can make specific restrictions in order to meet > >compliance. >=20 > I think we need to be careful here. Let's examine a use case. >=20 > I am a user of some RFC 4880 OpenPGP application. All algorithms are=20 > available to me, e.g. I am not a government employee. >=20 > * I use the application to encrypt mail to 5 recipients, my friends.=20 > They use RSA/DSA/ElGamal keys. >=20 > * I upgraded the application to the next version that happened to=20 > implement "ECC in OpenPGP". >=20 > I assume that we agree that if I encrypt to exactly the same 5 people=20 > with new version, as far as algorithm selection is concerned, the result= =20 > is identical to the previous version. >=20 > * I added 6th recipient to the list, which uses ECDH key. >=20 > I hope we will agree that it must be possible to send single e-mail to 6= =20 > recipients. RFC 4880 specifies that the default encryption algorithm is= =20 > 3DES, thus, there is always a match. Why shouldn't single e-mail be sent= =20 > to 6 recipients with 3DES symmetric key? >=20 > If the application is operating in Suite-B mode, or FIPS more, etc, then= =20 > the situation is different. >=20 > > > >Dependant on the "low spec" argument/evidence, we could just > >make one of the larger curve-hash pairs as the MUST, and make > >AES256 as the must cipher. Then if we need to encrypt to one > >of the two bigger curves *and* a smaller curve then we just > >"up" the cipher to AES256 for the small curve recipient. >=20 > RFC 4880 currently grants to a user of embedded device a method to say=20 > "don't do AES-256 to me" by using cipher preferences that exclude AES=20 > 256. We should respect this. We cannot change the fact that there are=20 > hardware platforms that don't implement or don't like AES 256. --V0207lvV8h4k8FAm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iQDVAwUBR8kb0tlNfsjr6fBFAQKjrwX+NzA41sPlgcox94sp1JcreQW93wjawLLH bS/LeScya9eeOG9uQheVZ9d+JTN/1HDfioHQuEAAg2gBKbZ49l2GvPv6FVhZJCpT yzrO4UO/qwgqMA0SS81gU2jHtjmgbEYcw7m6MscJc4nbXRLxXGlhTbJHduNVhEcy gks6pqkuiCwvRpe6gFKt02DrtTR0JB0gKbd0NJlLs/FXwdO2crR+KvFjn8x0xENE eqBg6wIiwuMvvwvuVy0uKACswGc8SIFV =K1tq -----END PGP SIGNATURE----- --V0207lvV8h4k8FAm-- From owner-ietf-openpgp@mail.imc.org Sat Mar 1 02:52:10 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8101128C8DA for ; Sat, 1 Mar 2008 02:52:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dODfT6KH3F8s for ; Sat, 1 Mar 2008 02:52:05 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id F3F243A6BF8 for ; Sat, 1 Mar 2008 02:52:04 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m21AYKxr058091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Mar 2008 03:34:20 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m21AYKIh058090; Sat, 1 Mar 2008 03:34:20 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m21AYIme058077 for ; Sat, 1 Mar 2008 03:34:19 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id C23304AAE; Sat, 1 Mar 2008 11:30:14 +0100 (CET) Date: Sat, 1 Mar 2008 11:30:14 +0100 To: ietf-openpgp@imc.org Subject: Thoughts and suggestions on V5 key format Message-ID: <20080301103008.GC8868@epointsystem.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="t0UkRYy7tHLRMCai" Content-Disposition: inline User-Agent: Mutt/1.5.9i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --t0UkRYy7tHLRMCai Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable As noted earlier, there are many problems with V4 public and private key formats that merit the consideration of a new key format (V5). This message is intended as a list of the problems and solutions that come to my mind in order to initiate a discussion that would hopefully lead to a sound design that can be standardized. 1. Private key format 1.1. Purpose I think, it should be explicitly stated that private key packet format is specified solely for the purpose of exporting and importing private keys. While implementations may choose to store private keys in this format, as it has no bearing on interoperability, it is outside the scope of the standard. 1.2. Structure The straightforward structure of public key material followed by private key material is fine, but the symmetrically encrypted private key material must be ditched, in my opinion. For confidentiality protection, the entire private key packet (including both public and private key material) must be encapsulated in a symmetrically encrypted and integrity protected packet (with an optional compression in between). This has several benefits: it prevents the Klima-Rosa attack, removes the need to define and implement symmetric encryption twice in slightly different ways, etc. For RSA keys, facilities for the multiprime variant must be included. Public keys with two or more prime factors should not be distinguished, though. 2. Fingerprints and Key IDs 2.1. Hashed material I think that only the key material and the algorithm identifier should influence the fingerprint; creation time should not, because it may not be readily available even if the public key is. However, I like the feature of V4 that the fingerprint is simply the hash of a canonized public key packet. Thus, I would recommend removing creation time from the public key packet altogether. This approach would facilitate (partial) interoperability with hardware and software not specifically designed for OpenPGP, as OpenPGP fingerprints and key IDs can then be calculated for any public key, no matter where it comes =66rom. 2.2. String representation Key IDs should be either decimal or octal. There are many crypto-capable devices with numeric-only keypads (e.g. cellphones). It would be very nice if key IDs could be conveniently typed on such devices. As an added benefit, it would reinforce the metaphor of the KeyID being something similar to a phone number, making it a good shot at the middle of Zooko's triangle. Since the key id being part of the fingerprint is a nice feature, fingerprints may also be decimal or octal, respectively. We could also blur the boundary between fingerprints and key ID by allowing the use of any sufficiently long (e.g. 10 decimal or 11 octal digits) suffix of the fingerprint as a key identifier (which is not necessarily unique, of course). 2.3. Hash function There should be only one, because the fingerprint must uniquely identify the corresponding key; there shouldn't be different fingerprints for the same key. Increasing the length of the fingerprint reduces its usability. Again, I would suggest the blurring of the boundary between fingerprints and key IDs, as above. Thus, we could use some super-safe hash function (e.g. SHA-512), but use only a sufficiently long tail for practical purposes. Regards, --=20 Daniel --t0UkRYy7tHLRMCai Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iQDVAwUBR8kwL9lNfsjr6fBFAQKhlgYArjjVXkmXe1lDJhDML+M/z6iZ57N1b4r2 cIjXA/+6wyMI80dAl7ZDv6d7tg0sMVwJk1mt26cWxx86jzgljRfznFOFY2JKbthv PHuSKKMWw3h2CtioNsJWKnK9fKkaH9W+FnFqu4IjUk+caoCpM4fRGYFqNKKpGF48 nGyCB+nVKmG5SFAt+fbkR3RipUwUs2W8gZdrazj+WfR7bH3k4GIn39KmOiJcI8ll uxqB+hJ2eCdUU3b+DZtDUjjXSjiWxPRD =y739 -----END PGP SIGNATURE----- --t0UkRYy7tHLRMCai-- From owner-ietf-openpgp@mail.imc.org Sat Mar 1 05:44:39 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F8072A2B48 for ; Sat, 1 Mar 2008 05:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.943 X-Spam-Level: X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdQ-pwpAqxum for ; Sat, 1 Mar 2008 05:40:46 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 19D0E28DC4D for ; Sat, 1 Mar 2008 05:10:17 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m21CiOu5075359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Mar 2008 05:44:24 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m21CiOro075358; Sat, 1 Mar 2008 05:44:24 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m21CiNMF075352 for ; Sat, 1 Mar 2008 05:44:24 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by wf-out-1314.google.com with SMTP id 28so4302920wff.28 for ; Sat, 01 Mar 2008 04:44:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Klvn1HOv+K9p/TGxgJ9JUzV86fRRNDOYMbMxxG9v8cc=; b=cWbYSnrqG1oLZDFo3ExXKAGldoXNU9DDEapridD1DvyE3aSbtmdbXQQuhJXv0CoNbe/2Shjop5p3nKiTj7dL/7NbaslNlUXaX1g3xb8gbljPDCpkBVcNM2HxgZSicw9yO6XygmSbYd4OHLgIdToWF/DWzV7kI0Zso2qulBcXvgw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uYloaQzddwWe04D9XMIowOpLIYHlkJXKDKym+77FAUDBlYc39XjxXS6TNJ3YHHm0suI1g+trm/MNcFNHluje2fdjZhdPvCBPhI7+j5vG/2i0v/a88y2ySW2ho1LsEa4yu3C/ZNtoBXYHOOa6KDkvwYmNEH816Zr0ofHGiVRAMYA= Received: by 10.142.89.9 with SMTP id m9mr7695511wfb.35.1204375463094; Sat, 01 Mar 2008 04:44:23 -0800 (PST) Received: by 10.143.172.3 with HTTP; Sat, 1 Mar 2008 04:44:23 -0800 (PST) Message-ID: <117bad160803010444l6fd5732fsc8d92e282a16c72d@mail.gmail.com> Date: Sat, 1 Mar 2008 12:44:23 +0000 From: "David Crick" To: ietf-openpgp@imc.org Subject: Re: ECC in OpenPGP proposal Cc: "Andrey Jivsov" In-Reply-To: <47C8EB4B.9010909@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C7FDEA.5070103@systemics.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 3/1/08, Andrey Jivsov wrote: > David Crick wrote: > > The ecc-pre-6.txt's section 2 pretty much says "this is how to > > do ECC with AES," and we've said that this proposal is a "MAY." > > In a sense this is therefore some kind of a fork (sub-superset?) > > of 4880, so we're not concerned with 3DES (or CAST), and - as > > with DSA - we can make specific restrictions in order to meet > > compliance. (further to my point above, if we really want ECC to support 3DES then the ECC document needs to be updated for that) > I think we need to be careful here. Let's examine a use case. > > I am a user of some RFC 4880 OpenPGP application. All algorithms are > available to me, e.g. I am not a government employee. > > * I use the application to encrypt mail to 5 recipients, my friends. > They use RSA/DSA/ElGamal keys. > > * I upgraded the application to the next version that happened to > implement "ECC in OpenPGP". > > I assume that we agree that if I encrypt to exactly the same 5 people > with new version, as far as algorithm selection is concerned, the result > is identical to the previous version. > > * I added 6th recipient to the list, which uses ECDH key. > > I hope we will agree that it must be possible to send single e-mail to 6 > recipients. RFC 4880 specifies that the default encryption algorithm is > 3DES, thus, there is always a match. Why shouldn't single e-mail be sent > to 6 recipients with 3DES symmetric key? I use PGP 2.6, I upgrade to PGP 5.0. Shiny new DH/DSS keys - but no RSA support! Until the RSA patent expired (well, was placed prematurely into the public domain) we ran parallel systems and/or kept "old" and "new" keys. Even now with 3DES as a must, we have this delightful phrase in 4880: "Implementations MUST implement TripleDES. Implementations SHOULD implement AES-128 and CAST5. Implementations that interoperate with PGP 2.6 or earlier *need to* support IDEA, as that is the only symmetric cipher those versions use. Implementations MAY implement any other algorithm." "need to"! But, NB, "might not be able to" - due to the IDEA patent. I seem to recall one of the PGP (5+) versions popping up a message about mixed V3/V4 (or RSA/DH) keys when I attempted to encrypt something (or maybe it was due to an IDEA/3DES conflict). (Maybe Jon can confirm my vague recollections here?) > If the application is operating in Suite-B mode, or FIPS more, etc, then > the situation is different. right. > RFC 4880 currently grants to a user of embedded device a method to say > "don't do AES-256 to me" by using cipher preferences that exclude AES > 256. We should respect this. We cannot change the fact that there are > hardware platforms that don't implement or don't like AES 256. OK, but they SHOULD support AES-128 (which would make a 128-256-256 ECC MUST not seem absolutely unworkable). Question: how "interoperable" do these "embedded devices" need to be with the rest of the world? From owner-ietf-openpgp@mail.imc.org Sat Mar 1 06:24:16 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC49A28D5F2 for ; Sat, 1 Mar 2008 06:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLjU9Xe2-w3V for ; Sat, 1 Mar 2008 06:20:34 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 996C2294832 for ; Sat, 1 Mar 2008 05:41:28 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m21DQ3ZT080419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Mar 2008 06:26:03 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m21DQ3Hb080418; Sat, 1 Mar 2008 06:26:03 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m21DQ2Dr080412 for ; Sat, 1 Mar 2008 06:26:02 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by wf-out-1314.google.com with SMTP id 28so4321324wff.28 for ; Sat, 01 Mar 2008 05:26:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=ofgnbfC9WiEADZRkVWTeyLY8hs/K8D4EIAOw6bE0X/A=; b=rQA7blW9mQ6VCgKH135oAUJsZhJovOGJUIfsPVGxcAqWLOrV18xx2FidlmGoO/JBDiI6L050T0/oVAIjeDGXYj/3AhXodRnQXIvcNgS/BI2PgxF1Ex6eRHFPAXtOry9JOpCApKZmcKPwGqZW7bH7X97Lq4oUKPtfVxBog5ycnfY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IVm/kpFiLoLHmfrfrAZWed/8gHas4BM035Agwx9mR+Syh/Qo7B8oNgluP6qrCaysnFnhL7pY9soV+mSRrEIhF8umCuvzUWEAW2h++MqpesU9ePZGu6+dd2U5VSPLRLL8K3/BrPooAn7pBmGPs72dOrasBP3GDqA7nZ3B5RCfOGQ= Received: by 10.142.49.4 with SMTP id w4mr795264wfw.57.1204377962038; Sat, 01 Mar 2008 05:26:02 -0800 (PST) Received: by 10.143.172.3 with HTTP; Sat, 1 Mar 2008 05:26:01 -0800 (PST) Message-ID: <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> Date: Sat, 1 Mar 2008 13:26:01 +0000 From: "David Crick" To: ietf-openpgp@imc.org Subject: Re: ECC in OpenPGP proposal Cc: "Andrey Jivsov" , "Daniel A. Nagy" In-Reply-To: <20080301090315.GB8868@epointsystem.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C7FDEA.5070103@systemics.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 3/1/08, Daniel A. Nagy wrote: > I think, Andrey makes a very important point here. The option to use 3DES > symmetric encryption, SHA1 digest and ZLIB compression must remain open until > a formal process of phasing them out is initiated, with a clear road map. > Right now, excluding these algorithms would break interoperability in a very > bad way, as described by Andrey. as someone said about alternative V5 key routes - let's absolutely make sure we break it! > Of course, SHA1 and 3DES are not without problems, but for most > security-critical applications they are still perfectly adequate. SHA1 is due to be retired in 2010 (at least for US Federal agencies). That means 1024-bit DSA keys are due to demise soon. The most recent bruteforce of RSA was on a "special" form of ~1024-bit keys (2^1039 -1); no doubt the normal form will fall in the not too considerable future. Germany has apparently said 1024-bit crypto is no longer allowed as of 2008 (this was posted regarding OpenPGP smartcards on one of the gnupg mailing lists). CSE say 80-bit ciphers will no longer be acceptable for Protected A & B information from 2010 (for protected C it was 2005) and that for A & B pk modulus 1024 will no longer be acceptable from 2010 (again, for C it is already 2048 minimum). The writing is on the wall for 1024 pks / 160 hashes / 80 ciphers! That means our applications (and RFCs) need to be updated to reflect this (*now!*; someone tell SSL web site maintainers...). 3DES is more of a "problem" - it's set to co-exist with AES until 2030 (for US Fed.), and even if we obliterate 1024-160-80 crypto we've still got 3DES as our OpenPGP vestigial tail. So maybe we can mangle ECC support so that we can still use 3DES with it, or maybe we need to crack on with V5, make it ECC only, and - as with the PGP 2 -> PGP 5 transition - have people run parallel apps (or send multiple messages) if they want to inter operate with 2048-3072-bit mod. non-ECC OpenPGP users. > Also note that prior to ECC, any symmetric cipher could have been matched > with any public key algorithm, because the secure block size for asymmetric > encryption algorithms (ElGamal and RSA) well exceeded the key sizes for > symmetric block ciphers. The encryption of session keys with random padding > has never been an issue. With ECC, this is no longer the case. For instance, > 256-bit AES keys won't fit into one ECC ElGamal blocks, which are otherwise > reasonably secure. Heck, even 3DES might be a little problematic, if 192-bit > curves are used. > > Finally, I would like to draw the group's attention to a special need of > moblie communication, that seems not to receive due attention. While it is > true that computational power is less and less of an issue with mobile > phones (although there are still plenty of under-powered devices in use and > even in production), the message size issue is here to stay for much longer. > In GSM networks, which are by far the most common around the globe, > peer-to-peer messaging between handsets is done in 1120-bit chunks, for > which operators charge money. Using an RFC4880-compliant format, even the > shortest message using reasonably strong asymmetric encryption (1024-bit > RSA), requires two chunks, which cost exactly twice as much for the sender > (and in some North-American setups even the recipient) as a regular text > message. Short public key and encrypted session key sizes of ECC may > actually prove to be the primary driving force behind its adoptation in the > mobile world, even if Moore's law renders low computational costs > irrelevant. From owner-ietf-openpgp@mail.imc.org Mon Mar 3 14:00:05 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EDE028C29D for ; Mon, 3 Mar 2008 14:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, URIBL_GREY=0.25] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3ZU1OmJxBmi for ; Mon, 3 Mar 2008 13:59:59 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 802C328C2DD for ; Mon, 3 Mar 2008 13:59:32 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m23LgH0G072916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Mar 2008 14:42:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m23LgHUL072915; Mon, 3 Mar 2008 14:42:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from brainhub.org (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m23LgFTj072908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 3 Mar 2008 14:42:16 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from [63.251.255.221] (63-251-255-221.pgp.com [63.251.255.221] (may be forged)) by brainhub.org (8.14.2/8.14.1) with ESMTP id m23Lg8wD006558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Mar 2008 13:42:09 -0800 Message-ID: <47CC70AB.5050909@brainhub.org> Date: Mon, 03 Mar 2008 13:42:03 -0800 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: "Daniel A. Nagy" Subject: Re: ECC in OpenPGP proposal References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C7FDEA.5070103@systemics.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> In-Reply-To: <20080301090315.GB8868@epointsystem.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel A. Nagy wrote: > I think, Andrey makes a very important point here. The option to use 3DES > symmetric encryption, SHA1 digest and ZLIB compression must remain open until > a formal process of phasing them out is initiated, with a clear road map. > Right now, excluding these algorithms would break interoperability in a very > bad way, as described by Andrey. > > Of course, SHA1 and 3DES are not without problems, but for most > security-critical applications they are still perfectly adequate. > > I agree. As a side note, it is a easier to deal with hashes, because the sender produces one signature data structure. Compare this with encryption when the sender may need to creates multiple ESK. I think we can disallow encoding with SHA-1 from this proposal without compatibility issues, but not RFC 4880 encryption algorithms. > Also note that prior to ECC, any symmetric cipher could have been matched > with any public key algorithm, because the secure block size for asymmetric > encryption algorithms (ElGamal and RSA) well exceeded the key sizes for > symmetric block ciphers. The encryption of session keys with random padding > has never been an issue. With ECC, this is no longer the case. For instance, > 256-bit AES keys won't fit into one ECC ElGamal blocks, which are otherwise > reasonably secure. Heck, even 3DES might be a little problematic, if 192-bit > curves are used. > I will note that current proposal doesn't have this limitation. It doesn't use ElGamal ECC. It uses key wrapping mechanism defined in RFC3394 for session key transport. I provided source code to see how the wrapping is done: http://brainhub.googlepages.com/aeswrap-RFC3394.c.html. > Finally, I would like to draw the group's attention to a special need of > moblie communication, that seems not to receive due attention. While it is > true that computational power is less and less of an issue with mobile > phones (although there are still plenty of under-powered devices in use and > even in production), the message size issue is here to stay for much longer. > In GSM networks, which are by far the most common around the globe, > peer-to-peer messaging between handsets is done in 1120-bit chunks, for > which operators charge money. Using an RFC4880-compliant format, even the > shortest message using reasonably strong asymmetric encryption (1024-bit > RSA), requires two chunks, which cost exactly twice as much for the sender > (and in some North-American setups even the recipient) as a regular text > message. Short public key and encrypted session key sizes of ECC may > actually prove to be the primary driving force behind its adoptation in the > mobile world, even if Moore's law renders low computational costs > irrelevant. > I agree. It is likely that many mobile vendors that entertained the idea of implementing OpenPGP passed on this format because of resource constrains. We will never know for sure, but we should attempt to give them another opportunity. OpenPGP makes a lot of sense for mobile communication. I paid special attention in this proposal to the size of per-message data structures, such as ESKs. I moved anything that can be moved from the per-message data structures into the public key. From owner-ietf-openpgp@mail.imc.org Mon Mar 3 14:30:38 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F08B28C18D for ; Mon, 3 Mar 2008 14:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.004 X-Spam-Level: X-Spam-Status: No, score=-2.004 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1A4n1-Kdr39B for ; Mon, 3 Mar 2008 14:30:32 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 6F44C28C203 for ; Mon, 3 Mar 2008 14:27:58 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m23MAdfk074874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Mar 2008 15:10:39 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m23MAdXi074873; Mon, 3 Mar 2008 15:10:39 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from brainhub.org (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m23MAbpH074864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 3 Mar 2008 15:10:38 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from [63.251.255.221] (63-251-255-221.pgp.com [63.251.255.221] (may be forged)) by brainhub.org (8.14.2/8.14.1) with ESMTP id m23MATA4006750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Mar 2008 14:10:30 -0800 Message-ID: <47CC7750.7080206@brainhub.org> Date: Mon, 03 Mar 2008 14:10:24 -0800 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: David Crick , "Daniel A. Nagy" Subject: Re: ECC in OpenPGP proposal References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C7FDEA.5070103@systemics.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> In-Reply-To: <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Let me explain my choices in this respect in the ECC proposal. We need 3DES as a fallback default to smoothly integrate ECC keys into existing installed base, as I mentioned earlier. Fortunately, we are lucky with signatures. * We know that most of deployed applications support SHA-256 already, the code is written and tested. * We can assume that when an applications understands ECC keys, it understands SHA-256. * Although there are smartcard hardware vendors today that insist on exclusively using SHA-1, they only support RSA keys. (We hope their new release with ECC support will not have hardcoded 20 bytes + ASN.1 prefix size check.) It follows then that: ** Self-signatures can use SHA-256. (If an applications doesn't understand SHA-256, it doesn't understand ECC.) ** Because the key's self-signatures must be verified, data signatures and certifications with ECC keys can use SHA-256. ** Certifications on RSA/DSA keys with ECC keys can use SHA-256 too. ** Back signatures by subkeys can use SHA-256 too. So, SHA-1, which is too weak for any curve in this proposal, can be safely disallowed for generation or verification of signatures made by an ECC key. Applications should be tolerant to SHA-1 on other keys or existing structures. David Crick wrote: > On 3/1/08, Daniel A. Nagy wrote: > >> I think, Andrey makes a very important point here. The option to use 3DES >> symmetric encryption, SHA1 digest and ZLIB compression must remain open until >> a formal process of phasing them out is initiated, with a clear road map. >> Right now, excluding these algorithms would break interoperability in a very >> bad way, as described by Andrey. >> > > as someone said about alternative V5 key routes - let's absolutely > make sure we break it! > > >> Of course, SHA1 and 3DES are not without problems, but for most >> security-critical applications they are still perfectly adequate. >> > > SHA1 is due to be retired in 2010 (at least for US Federal agencies). > > That means 1024-bit DSA keys are due to demise soon. The most > recent bruteforce of RSA was on a "special" form of ~1024-bit keys > (2^1039 -1); no doubt the normal form will fall in the not too > considerable future. > > Germany has apparently said 1024-bit crypto is no longer allowed > as of 2008 (this was posted regarding OpenPGP smartcards on > one of the gnupg mailing lists). > > CSE say 80-bit ciphers will no longer be acceptable for Protected > A & B information from 2010 (for protected C it was 2005) and > that for A & B pk modulus 1024 will no longer be acceptable from > 2010 (again, for C it is already 2048 minimum). > > > The writing is on the wall for 1024 pks / 160 hashes / 80 ciphers! > > > That means our applications (and RFCs) need to be updated to > reflect this (*now!*; someone tell SSL web site maintainers...). > > 3DES is more of a "problem" - it's set to co-exist with AES until > 2030 (for US Fed.), and even if we obliterate 1024-160-80 crypto > we've still got 3DES as our OpenPGP vestigial tail. > > > So maybe we can mangle ECC support so that we can still use > 3DES with it, or maybe we need to crack on with V5, make it ECC > only, and - as with the PGP 2 -> PGP 5 transition - have people > run parallel apps (or send multiple messages) if they want to > inter operate with 2048-3072-bit mod. non-ECC OpenPGP users. > > ... From owner-ietf-openpgp@mail.imc.org Mon Mar 3 15:05:43 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29B2728C264 for ; Mon, 3 Mar 2008 15:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.984 X-Spam-Level: X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plA3M2KCcLh2 for ; Mon, 3 Mar 2008 15:05:37 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 317A73A6B33 for ; Mon, 3 Mar 2008 15:05:32 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m23MnBi2077774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Mar 2008 15:49:11 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m23MnBC4077773; Mon, 3 Mar 2008 15:49:11 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m23MnAQK077767 for ; Mon, 3 Mar 2008 15:49:10 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by wf-out-1314.google.com with SMTP id 28so402485wff.28 for ; Mon, 03 Mar 2008 14:49:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=zvmjLW5kTiwZ7/sHpS7o29jyT5ZKSZzEVTKLV/b2HZM=; b=VEYLlJgjfSEPXkpKh/ubSx3/uDbhkZOI88l0AyhG2yjYK4HQBOiER6k6c6OQxyHaWuHg5NnidqOroi0jPOcoXrfLLCM34GjAeanjE0fD990G7xL7aTJrmYvaCkd4I2zmBPe7OCoD7verCEFuTKG1qPwb2iFVMxVTZ7tmZ5pJIpk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XNaf0AzoeA8AmZ5aoEEF/ko9i34mWy8JqzDy4whPgV4gKzonJ4JjxYvYZ8/EtsJNhb/2wcYoNqQnbhJnwNRwcWnjjrU7sSwHWsk0mUkQ7MFNoY5r91pwJIWijye9CnwOEiPajoDreH4v2KzkPpkxciijMF1Hy5Yc3T7pk/C+wjE= Received: by 10.142.213.9 with SMTP id l9mr395744wfg.104.1204584550053; Mon, 03 Mar 2008 14:49:10 -0800 (PST) Received: by 10.143.172.3 with HTTP; Mon, 3 Mar 2008 14:49:09 -0800 (PST) Message-ID: <117bad160803031449p1efb03bao654561db48a5dbb2@mail.gmail.com> Date: Mon, 3 Mar 2008 22:49:09 +0000 From: "David Crick" To: ietf-openpgp@imc.org Subject: Re: ECC in OpenPGP proposal Cc: "Andrey Jivsov" , "Daniel A. Nagy" In-Reply-To: <47CC7750.7080206@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <47CC7750.7080206@brainhub.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > We need 3DES as a fallback default to smoothly integrate ECC keys > into existing installed base, as I mentioned earlier. then (reluctantly, but not violently against) how about: MAY implement ECC o MUST implement SHA256 o MUST implement ECC256 [ o MUST implement 3DES - directly inherited from 4880, like it or not] o MUST implement AES128 [or just inherit the SHOULD from 4880??] o SHOULD implement AES256-SHA512-521ECC o MAY implement AES256-SHA384-384ECC o SHOULD try to match cipher strength with ECC strength, where recipient key preferences allow. (then need to add wording in about restrictions required for if strict Suite B compliance is required.) From owner-ietf-openpgp@mail.imc.org Tue Mar 4 00:33:41 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B0CD3A6CB8 for ; Tue, 4 Mar 2008 00:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.374 X-Spam-Level: X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=0.672, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwpn57lUwFxM for ; Tue, 4 Mar 2008 00:33:37 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id A57673A6EA2 for ; Tue, 4 Mar 2008 00:32:35 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m248C7Hb029492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 01:12:07 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m248C76c029490; Tue, 4 Mar 2008 01:12:07 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m248C5Tj029478 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 4 Mar 2008 01:12:06 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from localhost.localdomain (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by mail.cyberonic.com (8.12.8/8.12.8) with ESMTP id m248Dqo5015423; Tue, 4 Mar 2008 03:13:53 -0500 Message-ID: <47CD0451.9000503@brainhub.org> Date: Tue, 04 Mar 2008 00:12:01 -0800 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: David Crick Subject: Re: ECC in OpenPGP proposal References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <47CC7750.7080206@brainhub.org> <117bad160803031449p1efb03bao654561db48a5dbb2@mail.gmail.com> In-Reply-To: <117bad160803031449p1efb03bao654561db48a5dbb2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Crick wrote: >> We need 3DES as a fallback default to smoothly integrate ECC keys >> into existing installed base, as I mentioned earlier. >> > > then (reluctantly, but not violently against) how about: > > MAY implement ECC > o MUST implement SHA256 > o MUST implement ECC256 > [ o MUST implement 3DES - directly inherited from 4880, like it or not] > o MUST implement AES128 [or just inherit the SHOULD from 4880??] > > o SHOULD implement AES256-SHA512-521ECC > o MAY implement AES256-SHA384-384ECC > > o SHOULD try to match cipher strength with ECC strength, where > recipient key preferences allow. > > (then need to add wording in about restrictions required for if strict > Suite B compliance is required.) > David, I agree with this. Assuming this is consensus, I will change section 11.1 to "MUST implement curve with ID 1 and SHOULD implement curve with ID 3". Also in section 11.1, I will change to "MUST implement SHA2-256 and should implement SHA2-512,", dropping curve ID 2 and dropping SHA2-384 as MUST for OpenPGP profile. I will add a few sentences about Suite B and RFC4880 (in)compatibility. The problems are very very similar to the issue of FIPS mode of operation and RFC 4880. Regarding algorithm tupples, Section 12 already lists AES256-SHA512-521ECC and AES256-SHA384-384ECC as SHOULD combinations. I think it is better to break tupples into 3 pieces and address them independently. The choice of symmetric algorithm is governed by key preferences of (multiple) recipients. We shouldn't disregard preference list and prefer AES-256 (even for ECC keys). So section 11.1 tell MUST/SHOULD for individual algorithms and section 12 gives SHOULD recommendations regarding dependencies between algorithms. After above changes to section 11.1, the only missing correction there is "SHOULD implement AES-256". From owner-ietf-openpgp@mail.imc.org Tue Mar 4 07:26:22 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC5E83A699D for ; Tue, 4 Mar 2008 07:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.994 X-Spam-Level: X-Spam-Status: No, score=-1.994 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lz3Q32dJvp3u for ; Tue, 4 Mar 2008 07:26:22 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id E1E673A68F9 for ; Tue, 4 Mar 2008 07:26:21 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24EtZCC071675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 07:55:36 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m24EtZTp071674; Tue, 4 Mar 2008 07:55:35 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24EtYp8071668 for ; Tue, 4 Mar 2008 07:55:35 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by wf-out-1314.google.com with SMTP id 28so919796wff.28 for ; Tue, 04 Mar 2008 06:55:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=bStQoE/7PYO+5oz8HgYI1kk5BuA7+GEKxSQVsNpJ/Cw=; b=Bak20KbIK0BZSjZ+D/+kyFYyOPcfYqGZDIxD7mZejvTZU0NFzggfkiJlxlfFZp3gWNiob+PhXecXQ0ni/CqYhyAMwSLxRsojqjNoIaCOFqDgDvGHa3sMdbdyYubgflOn9k0886lwc9UyHJx7nCxpVHYw3VKPya8MByOUCK4bNqc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fP58sfmm9PezKwyOH5q9BPVqyBk11QTUFPu3jrMneIFVNVfCr/Fs8LwT8KFoKBabb4mw4JAhAwYGG7l1W0ir2yG2mPnKTCX3yHUoipQmR3YDu1F2MJAB/EAR86l+U77TAe4+6qHBq8tI/AK0H11na62frskJ6X5g4d7aeT9sykk= Received: by 10.142.222.21 with SMTP id u21mr557950wfg.41.1204642533770; Tue, 04 Mar 2008 06:55:33 -0800 (PST) Received: by 10.143.172.3 with HTTP; Tue, 4 Mar 2008 06:55:33 -0800 (PST) Message-ID: <117bad160803040655x3f393c7cuda72f361fbd119a4@mail.gmail.com> Date: Tue, 4 Mar 2008 14:55:33 +0000 From: "David Crick" To: ietf-openpgp@imc.org Subject: Re: ECC in OpenPGP proposal Cc: "Andrey Jivsov" In-Reply-To: <47CD0451.9000503@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <47CC7750.7080206@brainhub.org> <117bad160803031449p1efb03bao654561db48a5dbb2@mail.gmail.com> <47CD0451.9000503@brainhub.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 3/4/08, Andrey Jivsov wrote: > David Crick wrote: > >> We need 3DES as a fallback default to smoothly integrate ECC keys > >> into existing installed base, as I mentioned earlier. > >> > > > > then (reluctantly, but not violently against) how about: > > > > MAY implement ECC > > o MUST implement SHA256 > > o MUST implement ECC256 > > [ o MUST implement 3DES - directly inherited from 4880, like it or not] > > o MUST implement AES128 [or just inherit the SHOULD from 4880??] > > > > o SHOULD implement AES256-SHA512-521ECC > > o MAY implement AES256-SHA384-384ECC > > > > o SHOULD try to match cipher strength with ECC strength, where > > recipient key preferences allow. > > > > (then need to add wording in about restrictions required for if strict > > Suite B compliance is required.) > > > > > David, I agree with this. > > Assuming this is consensus, I will change section 11.1 to "MUST > implement curve with ID 1 and SHOULD implement curve with ID 3". Also in > section 11.1, I will change to "MUST implement SHA2-256 and should > implement SHA2-512,", dropping curve ID 2 and dropping SHA2-384 as MUST > for OpenPGP profile. this sounds like what what we've got to so far, although I note that this makes the [AES256-]SHA384-384ECC an *implicit* MAY rather than *specifically* mentioning SHA384 and ECC384 as MAYs. So, should we *explicitly* mention them? (also, an aside regarding repetition of a point I've previous made: the (e.g.) keywrapping text in -pre6 only talks about AES; this needs to be made more general, referring instead to keylengths.) > I will add a few sentences about Suite B and RFC4880 (in)compatibility. > The problems are very very similar to the issue of FIPS mode of > operation and RFC 4880. yes > Regarding algorithm tupples, Section 12 already lists > AES256-SHA512-521ECC and AES256-SHA384-384ECC as SHOULD combinations. the -pre6 document specifically lists P384-SHA384-AES192 in 12 (which, as per NIST, *are* the matching strengths), with the "MAY use stronger" in the paragraph before the table, but with the the AES256 (as per Suite B) in 11.2.2 before. All these pieces *together* allow for our discussed AES256-SHA384-384ECC combination, i.e. to support Suite B and to "drop" AES192. > I think it is better to break tupples into 3 pieces and address them > independently. Maybe it's because I haven't re-read the document as a whole with all our changes in place, but I'm personally finding it a bit hard to read our discussed cipher suggestions when they are split up as they currently are. Do you want to try producing a -pre7 so that we can see if we think it (a) matches our growing consensus and, (b) says it in a clear manner? If it does then great, otherwise some section, paragraph and topic re-ordering might be required. > The choice of symmetric algorithm is governed by key > preferences of (multiple) recipients. We shouldn't disregard preference > list and prefer AES-256 (even for ECC keys). 4880 section 13.2 says this: An implementation MUST NOT use a symmetric algorithm that is not in the recipient's preference list. When encrypting to more than one recipient, the implementation finds a suitable algorithm by taking the intersection of the preferences of the recipients. Note that the MUST-implement algorithm, TripleDES, ensures that the intersection is not null. *The implementation may use any mechanism to pick an algorithm in the intersection.* I suggest we *use* this freedom by (but!) tightening it in OpenPGP ECC applications. So, our ECC document would have something like: Having obtained an intersection of symmetric algorithm preferences, implementations SHOULD attempt to match symmetric algorithm size with public key size. [*Personally*, I'd like to continue: ", favouring longer lengths where possible."] The following table provides current equivalent recommendations (SP800-57). Note TripleDES is considered to have 112-bit security. Asymmetric | Hash | Symmetric | Elliptic key size | size | key size | curve key (RSA + D-H) | | | size ------------+--------+-------------------------- 1024 160 80 160 2048 224 112 224 3072 256 128 256 7680 384 192 384 15360 512 256 521 [the columns should probably be in a "better" order, this was just copied from 4800 with ECC then added on the end] > So section 11.1 tell > MUST/SHOULD for individual algorithms and section 12 gives SHOULD > recommendations regarding dependencies between algorithms. Subject to my "clarity" point above, then OK, yes, I can see this is how you are conveying this at present. > After above changes to section 11.1, the only missing correction there > is "SHOULD implement AES-256". yup. From owner-ietf-openpgp@mail.imc.org Tue Mar 4 07:29:35 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F26A28C286 for ; Tue, 4 Mar 2008 07:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzXWERXgWnpD for ; Tue, 4 Mar 2008 07:29:34 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 515DA28C51A for ; Tue, 4 Mar 2008 07:28:03 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24F2jAc072659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 08:02:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m24F2jkg072658; Tue, 4 Mar 2008 08:02:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from goten.sonance.net (goten.sonance.net [88.198.58.135]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24F2iOK072644 for ; Tue, 4 Mar 2008 08:02:44 -0700 (MST) (envelope-from iang@systemics.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id 0E12E57B17; Tue, 4 Mar 2008 16:02:41 +0100 (CET) Received: from goten.sonance.net ([127.0.0.1]) by localhost (goten.sonance.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yphsffn-jT5s; Tue, 4 Mar 2008 16:02:40 +0100 (CET) Received: from zhukov.local (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id 51CEF57B0B; Tue, 4 Mar 2008 16:02:40 +0100 (CET) Message-ID: <47CD648E.10705@systemics.com> Date: Tue, 04 Mar 2008 16:02:38 +0100 From: Ian G User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Andrey Jivsov CC: ietf-openpgp@imc.org, David Crick , "Daniel A. Nagy" Subject: Re: ECC in OpenPGP proposal References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C7FDEA.5070103@systemics.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <47CC7750.7080206@brainhub.org> In-Reply-To: <47CC7750.7080206@brainhub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Andrey Jivsov wrote: > > Let me explain my choices in this respect in the ECC proposal. > > We need 3DES as a fallback default to smoothly integrate ECC keys into > existing installed base, as I mentioned earlier. Can you say more about this? I do not see any reason to specify 3DES with ECC. (Yes, I know it is in RFC4880. I just don't know what that has to do with a separate ECC proposal.) We all know that 3DES should be retired in favour of AES. This means, in principle, not to write it into any new proposals, and smooth the way forward to let the implementors phase it out. The installed base is about private/public keys. They *will* create the ECC keys any way you tell them. If you don't tell them to set a preference for 3DES ... they won't do it. Or have I got something wrong? >> 3DES is more of a "problem" - it's set to co-exist with AES until >> 2030 (for US Fed.), and even if we obliterate 1024-160-80 crypto >> we've still got 3DES as our OpenPGP vestigial tail. Sure. Leave it there in RFC4880. That's history. Or are you telling us that Suite B mandates 3DES??? >> So maybe we can mangle ECC support so that we can still use >> 3DES with it,or maybe we need to crack on with V5, make it ECC >> only, and - as with the PGP 2 -> PGP 5 transition - have people >> run parallel apps (or send multiple messages) if they want to >> inter operate with 2048-3072-bit mod. non-ECC OpenPGP users. iang From owner-ietf-openpgp@mail.imc.org Tue Mar 4 08:14:25 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1587228C232 for ; Tue, 4 Mar 2008 08:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.946 X-Spam-Level: X-Spam-Status: No, score=-1.946 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QPRXJU11efd for ; Tue, 4 Mar 2008 08:14:19 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 6EE1628C3BC for ; Tue, 4 Mar 2008 08:14:19 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24FfcJe076740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 08:41:38 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m24Ffcbt076739; Tue, 4 Mar 2008 08:41:38 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from goten.sonance.net (goten.sonance.net [88.198.58.135]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24FfapA076731 for ; Tue, 4 Mar 2008 08:41:37 -0700 (MST) (envelope-from iang@systemics.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id B6C0557B17; Tue, 4 Mar 2008 16:41:35 +0100 (CET) Received: from goten.sonance.net ([127.0.0.1]) by localhost (goten.sonance.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlKUfFxkQ83Q; Tue, 4 Mar 2008 16:41:35 +0100 (CET) Received: from zhukov.local (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id 4DCFB57B0B; Tue, 4 Mar 2008 16:41:35 +0100 (CET) Message-ID: <47CD6DAE.9010409@systemics.com> Date: Tue, 04 Mar 2008 16:41:34 +0100 From: Ian G User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: "Daniel A. Nagy" , Andrey Jivsov , David Crick Subject: Re: ECC in OpenPGP proposal References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C7FDEA.5070103@systemics.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> In-Reply-To: <20080301090315.GB8868@epointsystem.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: OK, I think I found it. Sorry for not keeping up! Daniel A. Nagy wrote: > I think, Andrey makes a very important point here. The option to use 3DES > symmetric encryption, SHA1 digest and ZLIB compression must remain open until > a formal process of phasing them out is initiated, with a clear road map. > Right now, excluding these algorithms would break interoperability in a very > bad way, as described by Andrey. I disagree, below :) > Of course, SHA1 and 3DES are not without problems, but for most > security-critical applications they are still perfectly adequate. Right. The question is not about the security of the algorithms (which are more or less Pareto-secure-ish). Instead, it is about the business aspects of delivering the most security to the most people. > On Fri, Feb 29, 2008 at 09:36:11PM -0800, Andrey Jivsov wrote: >> David Crick wrote: >> ... >>> The ecc-pre-6.txt's section 2 pretty much says "this is how to >>> do ECC with AES," and we've said that this proposal is a "MAY." >>> In a sense this is therefore some kind of a fork (sub-superset?) >>> of 4880, so we're not concerned with 3DES (or CAST), and - as >>> with DSA - we can make specific restrictions in order to meet >>> compliance. Yes. This is a natural fork. It is for people who want Suite B. Which means the various USG organisations. Which before have not in the past been that impressed with OpenPGP. Actually, not impressed with anything in the open world, I'd say. We are really in new territory now that the NSA/NIST people have opened their hearts and declared Suite B. Which isn't to say that we shouldn't consider compatibility, but to say that this is a good, natural fork. We should also think about taking it... (I would. I remember the pain that was PGP 5.) >> I think we need to be careful here. Let's examine a use case. >> >> I am a user of some RFC 4880 OpenPGP application. All algorithms are >> available to me, e.g. I am not a government employee. >> >> * I use the application to encrypt mail to 5 recipients, my friends. >> They use RSA/DSA/ElGamal keys. >> >> * I upgraded the application to the next version that happened to >> implement "ECC in OpenPGP". >> >> I assume that we agree that if I encrypt to exactly the same 5 people >> with new version, as far as algorithm selection is concerned, the result >> is identical to the previous version. >> >> * I added 6th recipient to the list, which uses ECDH key. OK I see that. If... >> I hope we will agree that it must be possible to send single e-mail to 6 >> recipients. RFC 4880 specifies that the default encryption algorithm is >> 3DES, thus, there is always a match. Why shouldn't single e-mail be sent >> to 6 recipients with 3DES symmetric key? Sorry, I don't agree. The RFC4880 specification is only for applications that apply (more or less) to RFC4880! Applications that implement both RFC4880 *and* OpenPGP/ECC/Suite B are given no guarantee that this is likely to be seamless and joyful and without any degradation in their promised user experience. Just like S/MIME and RFC4880. To imagine otherwise would be to say that RFC4880's promise is that *all future work* is also compatible. That's hopeless. How far do we want to take that promise? OpenPGP quantum key exchange? What happens if the Russkies decide they want an OpenPGP GOST and they decide it is incompatible by definition with OpenPGP ECC? Or, we can retitle S/MIME as OpenPGP/S/Mime and insist on compatibility :) My point: It is *not* a given that people using OpenPGP Suite B can talk to people using RFC4880. Desirable, sure, but not a given. (I'd bet the NSA would prefer this *not* to be the case ;) Example: Consider properly written small-device platforms using the ECC stuff: They will likely implement the AES128-ECC-SHA "small" profile, and not include 3DES at all. The last thing anyone in the smart card / mobile world wants is incompatibility forced by vestigial circumstances. They want all *their* people talking, and that means one system, one algorithm. Talking to other people is a distant second in most business plans, and a controversial one at that. >> If the application is operating in Suite-B mode, or FIPS more, etc, then >> the situation is different. Yes, there are security ramifications. Are we really implementing Suite B if the application can leak info by sending out emails encrypted in Suite B (strong) and in 3DES to some 512 RSA key (not so strong)? iang From owner-ietf-openpgp@mail.imc.org Tue Mar 4 08:36:52 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4C4A28C23F for ; Tue, 4 Mar 2008 08:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.446 X-Spam-Level: X-Spam-Status: No, score=-1.446 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_27=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jgpo1vFz4Mr4 for ; Tue, 4 Mar 2008 08:36:47 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 155CB28C6DF for ; Tue, 4 Mar 2008 08:36:21 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24GDG5U079455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 09:13:16 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m24GDGNF079454; Tue, 4 Mar 2008 09:13:16 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24GDFgP079448 for ; Tue, 4 Mar 2008 09:13:15 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by wr-out-0506.google.com with SMTP id 76so1236878wra.10 for ; Tue, 04 Mar 2008 08:13:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=9hUbHy1oLYxGM5ioyvI0jpOllXN9Hzj2bnjMwf7w8zc=; b=J2TzRx9bq7buoHi71o/6wN2EtEJ+rhTnqFtM8A2gr21UTKgI08MgO6RYWOv20nOxzwyhpxiuXCe2J0MSRmF1wo4tZ3B7UPtgOh2DDL2EcXyN5Ytqx5goJSkNrMFuJvZLqqDCFJGNjWMJlWGr4IpsrnzbWYCaBnjvBhHC3QZHsUY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FXh7dwd0bYkIdlnbxFtogH3WfeZHXhf6sxH/PUBRZwdqGhXbPw3Xso1MIHv1SOROu6Bk8Jt3WDVZcudzMpltoslvgjhHhG1fetP1fJNzA3YWp6UFPz41c+U2JYYJBD4yCHM6LrXpdt9nCBLmLZSgcV41T+u7MvlL2JBWiPezKVg= Received: by 10.141.210.21 with SMTP id m21mr728220rvq.33.1204647193959; Tue, 04 Mar 2008 08:13:13 -0800 (PST) Received: by 10.141.201.6 with HTTP; Tue, 4 Mar 2008 08:13:13 -0800 (PST) Message-ID: <117bad160803040813q3129b0d1le46c26920c5be771@mail.gmail.com> Date: Tue, 4 Mar 2008 16:13:13 +0000 From: "David Crick" To: ietf-openpgp@imc.org, "Ian G" , "Andrey Jivsov" , "Daniel A. Nagy" Subject: Fwd: ECC in OpenPGP proposal In-Reply-To: <117bad160803040807n5ee9f31fsd69857e14ca24756@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <47CC7750.7080206@brainhub.org> <47CD648E.10705@systemics.com> <117bad160803040807n5ee9f31fsd69857e14ca24756@mail.gmail.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: sorry, I did "reply to Ian" rather than reply to all (including the list), which I meant to do. ---------- Forwarded message ---------- From: David Crick Date: Mar 4, 2008 4:07 PM Subject: Re: ECC in OpenPGP proposal To: Ian G On 3/4/08, Ian G wrote: > Andrey Jivsov wrote: > > > > Let me explain my choices in this respect in the ECC proposal. > > > > We need 3DES as a fallback default to smoothly integrate ECC keys into > > existing installed base, as I mentioned earlier. > > Can you say more about this? I do not see any reason to > specify 3DES with ECC. > > (Yes, I know it is in RFC4880. I just don't know what that > has to do with a separate ECC proposal.) The argument has been that if we are to "add" ECC *onto* OpenPGP (which for the WG means "RFC4880") then we "MUST" implement 3DES. If we wanted to create an ECC-*only* standard or application then no 3DES would be fine, but it wouldn't be compliant with 4880 or (necessarily) interoperable with an OpenPGP application (which might only understand 3DES) or respectful of a user's [existing] key preferences. > We all know that 3DES should be retired in favour of AES. > This means, in principle, not to write it into any new > proposals, and smooth the way forward to let the > implementors phase it out. NIST have handled it this way: FIPS46-3 has been withdrawn. FIPS187 is the standard, which you are *encouraged* to use. 3DES has been taken out of FIPS46-3 and issued as a (lesser) "special recommendation". 3DES lifetime is until 2030. Therefore, NIST say 3DES is OK but that AES is the preferred choice. *We* (4880) say that 3DES is a MUST and that AES128 (and CAST5, which CSE are also OK with) are SHOULDs. *NSA*, meanwhile, say that for *classified* stuff you may use any of the AESes, but that for TOP SECRET you must use one of the larger. Further, they specify PK strengths, which at these lengths are ECC rather than absurdly big IFP/DLP RSA/DH ones. So, now that we are coming to implement ECC in OpenPGP, we naturally want to base things on the NIST/NSA guidelines, as well as considering implementation limitations and market requirements. We also have our OpenPGP history to take into account. So this means that have to support the 4880 MUSTs to remain compatible with current applications and user base. > The installed base is about private/public keys. They > *will* create the ECC keys any way you tell them. If you > don't tell them to set a preference for 3DES ... they won't > do it. > > Or have I got something wrong? that 3DES is an implied preference, even if not there. > >> 3DES is more of a "problem" - it's set to co-exist with AES until > >> 2030 (for US Fed.), and even if we obliterate 1024-160-80 crypto > >> we've still got 3DES as our OpenPGP vestigial tail. > > > > Sure. Leave it there in RFC4880. That's history. > > Or are you telling us that Suite B mandates 3DES??? no, Suite B doesn't mandate 3DES it doesn't. If we want to integrate into/with the current 4880 then 3DES needs to be in[herited in!] OpenPGP-ECC. I'm not "over-joyed" by this, but if my "longer keys are preferred" bit is added onto the "SHOULD try and match sym. and pub. key lengths" bit then that's about as near to the "encouraging" of AES over 3DES as we are likely to be able to get. From owner-ietf-openpgp@mail.imc.org Tue Mar 4 09:06:34 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C536128C91E for ; Tue, 4 Mar 2008 09:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5erK4Y6O2vV for ; Tue, 4 Mar 2008 09:06:29 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id A69F828C57D for ; Tue, 4 Mar 2008 09:02:12 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24GaNaI081815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 09:36:24 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m24GaNsd081814; Tue, 4 Mar 2008 09:36:23 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.182]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24GaKf7081798 for ; Tue, 4 Mar 2008 09:36:23 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by el-out-1112.google.com with SMTP id o28so1201426ele.3 for ; Tue, 04 Mar 2008 08:36:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=OdvgzS3v055+X2j46PFtClxCgLfNL3JUJAdF3FCFJ+s=; b=ryrjcH/HICn5ZMKhBwqgBDrZw/HItiAp/V1drZzYryFiA71z6FcHaMgG9w7b0sr6BNDshcD4jJXZ6F26p0zttmyBLsI1rD5fBzkkyFkKPi6J4yvkWIn1ubT+rl5Jq2SIqzcQxNEevx2PZg10+NqPQUX4enDWOPJFxCAIO9W3998= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=vhmoXZjRMLa9dpyUT7Q34nyRMnr8T+3gSFHRs8UzKosb/ITewAjKWG7lSeVXtwMUhIi7M2nrmIuSKTQgedbpIT0yIq9HMUoH2CnalKTrAx3Rr0dthyueKSq6OPI38H7xPKft2h0yU1B16BWv4o4F2sX+izvkpnKj+ZxdYQ4EdxM= Received: by 10.141.113.6 with SMTP id q6mr750297rvm.36.1204648579369; Tue, 04 Mar 2008 08:36:19 -0800 (PST) Received: by 10.141.201.6 with HTTP; Tue, 4 Mar 2008 08:36:19 -0800 (PST) Message-ID: <117bad160803040836w62c31febmd08825ad552324e8@mail.gmail.com> Date: Tue, 4 Mar 2008 16:36:19 +0000 From: "David Crick" To: "Ian G" Subject: Re: ECC in OpenPGP proposal Cc: ietf-openpgp@imc.org, "Daniel A. Nagy" , "Andrey Jivsov" In-Reply-To: <47CD6DAE.9010409@systemics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C7FDEA.5070103@systemics.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <47CD6DAE.9010409@systemics.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 3/4/08, Ian G wrote: > OK, I think I found it. Sorry for not keeping up! no problem. Also, note that yours and my emails have overlapped in our composing/sending, and that I unintentionally sent me last email to just you rather than the list. Hopefully everyone can now re-follow the discussion! > Daniel A. Nagy wrote: > > I think, Andrey makes a very important point here. The option to use 3DES > > symmetric encryption, SHA1 digest and ZLIB compression must remain open until > > a formal process of phasing them out is initiated, with a clear road map. > > Right now, excluding these algorithms would break interoperability in a very > > bad way, as described by Andrey. > > > > I disagree, below :) yes, I have also disagreed - and still do "in principle". *However,* I can (now) accept that as a "way forward" compromise we can have both ECC and some interoperability with current OpenPGP. I'm attempting to (subtly ;) ) try and implement wording for us that similarly "encourages" use of AES over 3DES by having an "implementations SHOULD try and match sym & pk key lengths" bit, together if possible (help me here Ian ;) ) with a further "longer lengths should be preferred". Maybe we should even add an example: If Alice has a 1024 bit RSA key and Bob a 521-bit ECC key, and both Alice and Bob have AES256 as one of their possible cipher preferences, then implementations SHOULD choose this stronger cipher. This is a hack on 4880's "implementations may choose any method of selecting from the intersection of preferences" - i.e., for ECC we are saying how implementations SHOULD (but, note, not any stronger than SHOULD). I feel this is both within the spirit of 4880 *as well as* our best intentions to encourage AES. > > > > > Of course, SHA1 and 3DES are not without problems, but for most > > security-critical applications they are still perfectly adequate. > > > > Right. The question is not about the security of the > algorithms (which are more or less Pareto-secure-ish). > Instead, it is about the business aspects of delivering the > most security to the most people. > > > > > On Fri, Feb 29, 2008 at 09:36:11PM -0800, Andrey Jivsov wrote: > >> David Crick wrote: > >> ... > >>> The ecc-pre-6.txt's section 2 pretty much says "this is how to > >>> do ECC with AES," and we've said that this proposal is a "MAY." > >>> In a sense this is therefore some kind of a fork (sub-superset?) > >>> of 4880, so we're not concerned with 3DES (or CAST), and - as > >>> with DSA - we can make specific restrictions in order to meet > >>> compliance. > > > Yes. This is a natural fork. But it has been pointed out that we can still keep 4880 compliance by inheriting its 3DES (and then "encouraging" AES when used with Ecc). > It is for people who want > Suite B. I think there are "people who want *ECC*" and *also* people who want Suite B. Personally, I'd like to *only* see Suite B ECC, but consider people thinking "hey, OpenPGP only has 384-bit ECC, but has 521-bit. OpenPGP sucks!" > Which means the various USG organisations. > Which before have not in the past been that impressed with > OpenPGP. Actually, not impressed with anything in the open > world, I'd say. We are really in new territory now that the > NSA/NIST people have opened their hearts and declared Suite B. yes, we certainly are. > Which isn't to say that we shouldn't consider compatibility, > but to say that this is a good, natural fork. We should > also think about taking it... > > (I would. I remember the pain that was PGP 5.) We could "force" a split, *or*, we could orchestrate a slow migration, through adding ECC ("hey, cool, PGP has a new public key algorithm. It must be better!"), and then perhaps with V5 keys. > >> I think we need to be careful here. Let's examine a use case. > >> > >> I am a user of some RFC 4880 OpenPGP application. All algorithms are > >> available to me, e.g. I am not a government employee. > >> > >> * I use the application to encrypt mail to 5 recipients, my friends. > >> They use RSA/DSA/ElGamal keys. > >> > >> * I upgraded the application to the next version that happened to > >> implement "ECC in OpenPGP". > >> > >> I assume that we agree that if I encrypt to exactly the same 5 people > >> with new version, as far as algorithm selection is concerned, the result > >> is identical to the previous version. > >> > >> * I added 6th recipient to the list, which uses ECDH key. > > > > OK I see that. If... > > > >> I hope we will agree that it must be possible to send single e-mail to 6 > >> recipients. RFC 4880 specifies that the default encryption algorithm is > >> 3DES, thus, there is always a match. Why shouldn't single e-mail be sent > >> to 6 recipients with 3DES symmetric key? > > > > Sorry, I don't agree. The RFC4880 specification is only for > applications that apply (more or less) to RFC4880! > > Applications that implement both RFC4880 *and* > OpenPGP/ECC/Suite B are given no guarantee that this is > likely to be seamless and joyful and without any degradation > in their promised user experience. we're now saying there's a way. > > Just like S/MIME and RFC4880. > > To imagine otherwise would be to say that RFC4880's promise > is that *all future work* is also compatible. That's > hopeless. How far do we want to take that promise? OpenPGP > quantum key exchange? What happens if the Russkies decide > they want an OpenPGP GOST and they decide it is incompatible > by definition with OpenPGP ECC? Or, we can retitle S/MIME > as OpenPGP/S/Mime and insist on compatibility :) > > My point: It is *not* a given that people using OpenPGP > Suite B can talk to people using RFC4880. Desirable, sure, > but not a given. > > (I'd bet the NSA would prefer this *not* to be the case ;) > > Example: Consider properly written small-device platforms > using the ECC stuff: They will likely implement the > AES128-ECC-SHA "small" profile, and not include 3DES at all. Then they're not OpenPGP/4880 compliant/compatible/ > The last thing anyone in the smart card / mobile world > wants is incompatibility forced by vestigial circumstances. > They want all *their* people talking, and that means one > system, one algorithm. Talking to other people is a distant > second in most business plans, and a controversial one at that. That one algorithm *at present* is 3DES. > >> If the application is operating in Suite-B mode, or FIPS more, etc, then > >> the situation is different. > > > > Yes, there are security ramifications. Are we really > implementing Suite B if the application can leak info by > sending out emails encrypted in Suite B (strong) and in 3DES > to some 512 RSA key (not so strong)? Going forward we need to re-establish what is considered minimally secure. With ECC we're effectively closing off SHA1 (as a hash; it'll still be there for, e.g., the fingerprint, at least as I understand it). With V5 keys we could vape SHA1 entirely, and set 2048 (IF/DLP) / 256 (ECC) public keys as the minimum lengths. 2030 is our next "target" - that will likely mark the point when we need to shift from 3DES, SHA224 and 2048IFDLP/224ECC to (for the lowest strength) SHA256-AES128-3072IFDLP/256ECC. > > iang > From owner-ietf-openpgp@mail.imc.org Tue Mar 4 09:13:59 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8822928C361 for ; Tue, 4 Mar 2008 09:13:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.007 X-Spam-Level: X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhcXUeXp3W6M for ; Tue, 4 Mar 2008 09:13:54 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id A80233A6EA2 for ; Tue, 4 Mar 2008 09:08:45 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24Gmftw083190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 09:48:41 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m24Gmf1S083189; Tue, 4 Mar 2008 09:48:41 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.184]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24GmeHb083178 for ; Tue, 4 Mar 2008 09:48:40 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by rv-out-0910.google.com with SMTP id c27so425263rvf.34 for ; Tue, 04 Mar 2008 08:48:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=OT3CIu/nMO5CGBldw/0dNT2SE62+5TYQMqVSjeOTWps=; b=b8gbqbuPZM8bEIe8Dg48KSmIAu26tBjP230V+6dsLrMpa13lQJfkJHnV0ZKsOZWCMD3TubQzuXjw8eqf6RT+hvsvpCCPNJjEoz7jXvpNxPcGWaTi4zs+fR3sHCnfOpt6pt5Remc2egTqKvx8Ui8RDfRt37g/KXMPRovrqihoww4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YHX36wEOSZqn3GUVCEBSukkknROapo4rljOLk0+Sbwkx04u8gAulUvi9gPH93f4VCMGJVNkdi1lq8JOtEFd6X0gpjq59im0n7QeylAl2iQsj0C7n89NuGqRorBgfcR/SEJykE0DaK3BZEUtssl8lqrP6tY8/O3aiRSXrgwMfaD0= Received: by 10.141.83.15 with SMTP id k15mr749276rvl.120.1204649319522; Tue, 04 Mar 2008 08:48:39 -0800 (PST) Received: by 10.141.201.6 with HTTP; Tue, 4 Mar 2008 08:48:39 -0800 (PST) Message-ID: <117bad160803040848v74533155t8dac4db74c0458f3@mail.gmail.com> Date: Tue, 4 Mar 2008 16:48:39 +0000 From: "David Crick" To: "Ian G" Subject: Re: ECC in OpenPGP proposal Cc: ietf-openpgp@imc.org, "Daniel A. Nagy" , "Andrey Jivsov" In-Reply-To: <117bad160803040836w62c31febmd08825ad552324e8@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <47CD6DAE.9010409@systemics.com> <117bad160803040836w62c31febmd08825ad552324e8@mail.gmail.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Yes, there are security ramifications. Are we really > > implementing Suite B if the application can leak info by > > sending out emails encrypted in Suite B (strong) and in 3DES > > to some 512 RSA key (not so strong)? > > > Going forward we need to re-establish what is considered > minimally secure. I should have also have added that in our OpenPGP-ECC doc we are pointing out equivalent strengths and further stating that for Suite B compliance there are further restrictions. I can see quite easily a PGP option checkbox or Gnupg flag that says --strict-SuiteB-ECC. This could *refuse* to encrypt to multiple keys using a smaller cipher. We have the same situation today. There's no point me changing my GnuPG source to allow me to generate a 7K RSA encryption key, because unless all my correspondents *also* use the same/equivalent/stronger lengths, then the session key is at the mercy of the smallest public key size. From owner-ietf-openpgp@mail.imc.org Tue Mar 4 09:18:38 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8FDB28C5BA for ; Tue, 4 Mar 2008 09:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyXl6zLOdOSG for ; Tue, 4 Mar 2008 09:18:33 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 0816228C7AB for ; Tue, 4 Mar 2008 09:15:08 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24Gq7cS083668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 09:52:07 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m24Gq7ao083667; Tue, 4 Mar 2008 09:52:07 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24Gq56A083655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 4 Mar 2008 09:52:06 -0700 (MST) (envelope-from rabbi@abditum.com) Received: by thetis.deor.org (Postfix, from userid 500) id 1F1F0452B3; Tue, 4 Mar 2008 08:52:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by thetis.deor.org (Postfix) with ESMTP id 0AFA548052; Tue, 4 Mar 2008 08:52:05 -0800 (PST) Date: Tue, 4 Mar 2008 08:52:04 -0800 (PST) From: Len Sassaman X-X-Sender: rabbi@thetis.deor.org To: David Crick Cc: ietf-openpgp@imc.org, Andrey Jivsov , "Daniel A. Nagy" Subject: Re: ECC in OpenPGP proposal In-Reply-To: <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> Message-ID: References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C7FDEA.5070103@systemics.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, 1 Mar 2008, David Crick wrote: > > On 3/1/08, Daniel A. Nagy wrote: > > I think, Andrey makes a very important point here. The option to use 3DES > > symmetric encryption, SHA1 digest and ZLIB compression must remain open until > > a formal process of phasing them out is initiated, with a clear road map. > > Right now, excluding these algorithms would break interoperability in a very > > bad way, as described by Andrey. > > as someone said about alternative V5 key routes - let's absolutely > make sure we break it! That was more than one person, I think, but I was one of them. Breaking compatibility on the protocol level doesn't mean breaking it on the actually application level. In a different thread, there as discussion of people using "regular" DSA/EG keys and then adding a recipient who uses ECC. So what? The application can encrypt twice, and send the properly encrypted messages to the appropriate people. Backwards compatibility on the protocol level means forward compatibility on protocol level attacks. Let's not do that, eh? [Obviously we don't want to be breaking compatility all the time, but for something as big as v5, that we've been talking about for almost a decade, I think it's reasonable to both get it right, and cut the last decade+'s legacy of cruft loose, and leave the application to support v4 and v5 if the designer so desires. A lot of the things done in OpenPGP are, in hindsight, missteps. Hindsight is cheap. Let's make use of it when it is appropriate.] --Len. From owner-ietf-openpgp@mail.imc.org Tue Mar 4 09:35:14 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC78828C3C9 for ; Tue, 4 Mar 2008 09:35:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l11f4B7eYg00 for ; Tue, 4 Mar 2008 09:35:09 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 3AFC33A6965 for ; Tue, 4 Mar 2008 09:35:09 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24HHPTj086204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 10:17:25 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m24HHPv1086203; Tue, 4 Mar 2008 10:17:25 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24HHOhs086197 for ; Tue, 4 Mar 2008 10:17:25 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by el-out-1112.google.com with SMTP id o28so1237538ele.3 for ; Tue, 04 Mar 2008 09:17:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=OdBgBOXgEIOO+XM0zotZiXfpiSVcZjGiwZGjvI6X/D8=; b=e/V+nj8yErx5bqqhQswkoMA9NamM8sYKfy7j9ynRbeLXr4KFzN6B5njPkY3hGkjdwaZfq3rlq6I4IuV1FadcKAau6RSbNzFen64Pkpg8/3gWQBa73bczAHynFqJbNCpUBVrqixsfV0zQqQlHvwE4WHbXjKlaEUy/W1s5JITimZs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VkITaGfsqkRsgaPnVKk1xOiT7YFuf1JAyR32PpvtQg1oD44G7PF9VRVHTsHy5wprBw9nSzo6Z3oIJZSRJj3e3qPGFHb9Y7gR+U1B697xgAb5ctKPB3r2sudyZFbKhFaGwcHAX0brirWOtwlidCOlSJQyE4wxCDvfmbe1NXEkS6M= Received: by 10.140.82.40 with SMTP id f40mr800633rvb.16.1204651043326; Tue, 04 Mar 2008 09:17:23 -0800 (PST) Received: by 10.141.201.6 with HTTP; Tue, 4 Mar 2008 09:17:23 -0800 (PST) Message-ID: <117bad160803040917g75814d55oc63250a0591017bd@mail.gmail.com> Date: Tue, 4 Mar 2008 17:17:23 +0000 From: "David Crick" To: ietf-openpgp@imc.org, "Andrey Jivsov" , "Daniel A. Nagy" , "Len Sassaman" Subject: ECC in OpenPGP proposal In-Reply-To: <117bad160803040915h556db896ma53ad69a4a5feb50@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <117bad160803040915h556db896ma53ad69a4a5feb50@mail.gmail.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: sorry, I once again did reply to sender rather than reply to all - my reply was meant for everyone and not just Len. Hey, it's a *good* security habit to have! :) ---------- Forwarded message ---------- From: David Crick Date: Mar 4, 2008 5:15 PM Subject: Re: ECC in OpenPGP proposal To: Len Sassaman On 3/4/08, Len Sassaman wrote: > On Sat, 1 Mar 2008, David Crick wrote: > > > > > On 3/1/08, Daniel A. Nagy wrote: > > > I think, Andrey makes a very important point here. The option to use 3DES > > > symmetric encryption, SHA1 digest and ZLIB compression must remain open until > > > a formal process of phasing them out is initiated, with a clear road map. > > > Right now, excluding these algorithms would break interoperability in a very > > > bad way, as described by Andrey. > > > > as someone said about alternative V5 key routes - let's absolutely > > make sure we break it! > > > That was more than one person, I think, but I was one of them. thanks for clarifying this. > Breaking compatibility on the protocol level doesn't mean breaking it on > the actually application level. In a different thread, there as discussion > of people using "regular" DSA/EG keys and then adding a recipient who uses > ECC. So what? The application can encrypt twice, and send the properly > encrypted messages to the appropriate people. I think I've also pointed this out (either that or I've thought it but not explicitly said it!) > Backwards compatibility on the protocol level means forward compatibility > on protocol level attacks. Let's not do that, eh? > > [Obviously we don't want to be breaking compatility all the time, but for > something as big as v5, that we've been talking about for almost a decade, > I think it's reasonable to both get it right, and cut the last decade+'s > legacy of cruft loose, and leave the application to support v4 and v5 if > the designer so desires. A lot of the things done in OpenPGP are, in > hindsight, missteps. Hindsight is cheap. Let's make use of it when it is > appropriate.] I really would *ideally* like to see just one cipher suite, which I see could see would be: SHA384-AES256-ECC384_DH_DSA. This uses our largest respective algorithms while being Suite B compliant. As Ian pointed out, we really are into new territory with Suite B - PGP (2) used to say "military strength" when listing larger key sizes; now we can legitimately say "TOP SECRET strength"! [Yes, as an aside, I know that the latter would actually require restricted key generations, physical security measures, tamper evident seals, blah, blah, blah.] I'm actually more concerned that web sites are still using 1024 bit (well, 1120 Bits it says for gmail for me) SSL public keys and SHA1, rather than the fact that somebody might use 3DES as a cipher when sending a message to my 521-bit ECC key. From owner-ietf-openpgp@mail.imc.org Tue Mar 4 10:12:13 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EC4628C50E for ; Tue, 4 Mar 2008 10:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fGR9TBYTOUC for ; Tue, 4 Mar 2008 10:12:08 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id B10AC28C57D for ; Tue, 4 Mar 2008 10:12:03 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24HnS1v089235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 10:49:28 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m24HnSPZ089234; Tue, 4 Mar 2008 10:49:28 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24HnQML089226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 4 Mar 2008 10:49:27 -0700 (MST) (envelope-from rabbi@abditum.com) Received: by thetis.deor.org (Postfix, from userid 500) id 3522445228; Tue, 4 Mar 2008 09:49:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by thetis.deor.org (Postfix) with ESMTP id 21DC948053; Tue, 4 Mar 2008 09:49:26 -0800 (PST) Date: Tue, 4 Mar 2008 09:49:26 -0800 (PST) From: Len Sassaman X-X-Sender: rabbi@thetis.deor.org To: David Crick Cc: ietf-openpgp@imc.org, Andrey Jivsov , "Daniel A. Nagy" Subject: Re: ECC in OpenPGP proposal In-Reply-To: <117bad160803040917g75814d55oc63250a0591017bd@mail.gmail.com> Message-ID: References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <117bad160803040915h556db896ma53ad69a4a5feb50@mail.gmail.com> <117bad160803040917g75814d55oc63250a0591017bd@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 4 Mar 2008, David Crick wrote: > I really would *ideally* like to see just one cipher suite, which I see > could see would be: SHA384-AES256-ECC384_DH_DSA. I'm with you on the one cipher suite. I think good protocols must have methods by which new ciphers can be added (and implementors might actually want to have them in the code and tested and ready should they need to enable them), but the more options we add to a cipher suite, the more that can go wrong. (This is also my argument for why we should be using Whirlpool with AES, but the counter argument of popularity/support for the second-gen SHAs probably out-weighs it.) Ian G. has written about this a lot, and he and I don't always agree on everything, on this point, we do. OpenPGP already wants to do what I want it to do; except the current notion is that if a cipher is broken, everyone will disable support for it. That might have been a reasonable assumption when only cypherpunks were using it, but it is naive now. If you give the user a way to break their security, they will -- especially if "not doing something" means breaking their security. (As for which ciphers should go in, I'm going to remain agnostic. I would pick differently than you did, but we all have our pet favorites. What matters is that we limit the avenues of attack -- it's not about putting all our eggs in one basket, as some confused people think; rather, it's about limiting the possible crypto-level attacks on has available to them when trying to break the system.) --Len. From owner-ietf-openpgp@mail.imc.org Tue Mar 4 11:31:05 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26A6828C3B5 for ; Tue, 4 Mar 2008 11:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.015 X-Spam-Level: X-Spam-Status: No, score=-2.015 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7A5OZEHa4gUO for ; Tue, 4 Mar 2008 11:31:04 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 07D0928C481 for ; Tue, 4 Mar 2008 11:31:03 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24JCqh1003527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 12:12:52 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m24JCqx3003526; Tue, 4 Mar 2008 12:12:52 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.188]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24JCoXS003515 for ; Tue, 4 Mar 2008 12:12:51 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by rv-out-0910.google.com with SMTP id c27so464948rvf.34 for ; Tue, 04 Mar 2008 11:12:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=HWNFPayjaKS9M7r2OGfJZdXM293rO7rgnPoU1LnaOmY=; b=tJY1/C8G436KLiAsCBbCkSX8E3XcCNKuhD5Hhdbq8sIn3omzBFKbi9RWVeCSDmcnzw4Ngfu7w64H30GjmFJCBglV7qu9PRFQK2P30gPMFEpe9SyTAVr1+m3eWGKmMEEPDM04a6GOJWbbwpKvkjOjx0ZnDf9/QIPK0Bmeyft2X5Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=xyP2i+qpkhLFFRuDX8JGezjen1mRPd3SaqAgqrR3KfOpR3PVXbV4P1p1wbIfO/pkio+WkzBon/4KM+dCiQTd8Xw+06rENKZbGLWk7cqT7PCI7T/+/u+eKmrDJ3Q11jlCdn9CV1Xifmp5KGEGj953N62waerLAgX7ZEea1qFmKTE= Received: by 10.141.164.13 with SMTP id r13mr909924rvo.65.1204657969678; Tue, 04 Mar 2008 11:12:49 -0800 (PST) Received: by 10.141.201.6 with HTTP; Tue, 4 Mar 2008 11:12:49 -0800 (PST) Message-ID: <117bad160803041112h5e187096vcc698d071a2e4251@mail.gmail.com> Date: Tue, 4 Mar 2008 19:12:49 +0000 From: "David Crick" To: "Len Sassaman" Subject: Re: ECC in OpenPGP proposal Cc: ietf-openpgp@imc.org, "Andrey Jivsov" , "Daniel A. Nagy" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <117bad160803040915h556db896ma53ad69a4a5feb50@mail.gmail.com> <117bad160803040917g75814d55oc63250a0591017bd@mail.gmail.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 3/4/08, Len Sassaman wrote: > On Tue, 4 Mar 2008, David Crick wrote: > > > I really would *ideally* like to see just one cipher suite, which I see > > could see would be: SHA384-AES256-ECC384_DH_DSA. > > > I'm with you on the one cipher suite. I think good protocols must have > methods by which new ciphers can be added (and implementors might actually > want to have them in the code and tested and ready should they need to > enable them), but the more options we add to a cipher suite, the more that > can go wrong. > > (This is also my argument for why we should be using Whirlpool with AES, > but the counter argument of popularity/support for the second-gen SHAs > probably out-weighs it.) > > Ian G. has written about this a lot, and he and I don't always agree on > everything, on this point, we do. OpenPGP already wants to do what I want > it to do; except the current notion is that if a cipher is broken, > everyone will disable support for it. That might have been a reasonable > assumption when only cypherpunks were using it, but it is naive now. If > you give the user a way to break their security, they will -- especially > if "not doing something" means breaking their security. > > (As for which ciphers should go in, I'm going to remain agnostic. I would > pick differently than you did, but we all have our pet favorites. What > matters is that we limit the avenues of attack -- it's not about putting > all our eggs in one basket, as some confused people think; rather, it's > about limiting the possible crypto-level attacks on has available to them > when trying to break the system.) > > > > --Len. > hey, you quoted my One Cipher choice without my corresponding relevant justification! :) But yeah, I agree that others will disagree. I think we *all* agree that we'd like to see ECC in OpenPGP (and for those that don't, the current proposal appears to supplement, not obsolete, 4880, so they can continue in their non-ECC world). ECC will: 1) bring equiv. of 3K pub key to small devices 2) bring equiv. of 7 to 15K pub key to larger devices 3) allow OpenPGP to compete in the ECC marketplace 4) bring Suite B support (this is subset of some of the previous) Now, we're currently fixating on the general topic of reducing algorithms. AES192 seems to be departing without too much protest, but 3DES (and the wider topic of 4880 compatibility) seems to be the current "issue." With V5 keys I think we're envisaging some form of incompatibility? For instance, Daniel's recently posted "Thoughts and suggestions on V5 key format" suggests using SHA512 for the fingerprint (which I'd agree with given present specified 4880 hashes). Clearly that would make SHA512 a MUST for V5 key applications - but it's not even widely implemented/deployed yet (e.g. the last time I checked, PGP9 wouldn't recognise SHA512 as a cert-digest-algo). * So for me I think the whole ECC current point in question appears to be: _when_ do we want to introduce ECC? Do we want to have it as an alternative V4 choice (in which case we seem to, e.g., by default allow 3DES with ECC), or do we wait until V5 (when we then might be able to say: only AES with ECC) ? * Now, let's say our user installs PGP 10 and is allowed to generate a V4 ECC key. Several years later ;) with PGP 12 they are prompted to generate a different (V5) ECC key as the default. They are left wondering: "didn't I already switch to the "new" ECC keys a few years ago???" I think we want/need ECC in OpenPGP *soon*; I also think we need to move away from SHA1/1024 bit IFP/DLP *soon* as well (where for me, given various national and security bodies' recommendations, "soon" = "by/before 2010"). So, do we try and do both together, or do we try and get ECC done as a V4 alternative *now*, and think about V5 keys afterwards? Thinking about is as I'm typing, I would favour ECC *first* and then V5 after, the reason being that we're (hopefully!) likely to get ECC consensus in a relatively short time, whereas V5 may take longer and might/should also take into account the result of the SHA3 contest, which isn't scheduled to finish until 2012. (We could probably (??!) flesh out V5 before then, just leaving a gap for the details on SHA3.) From owner-ietf-openpgp@mail.imc.org Tue Mar 4 12:35:36 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE69D28C473 for ; Tue, 4 Mar 2008 12:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pi1k-LIV401O for ; Tue, 4 Mar 2008 12:35:36 -0800 (PST) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 7419728C5AE for ; Tue, 4 Mar 2008 12:35:15 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m24KCItq014189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 13:12:18 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m24KCIdr014188; Tue, 4 Mar 2008 13:12:18 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from goten.sonance.net (goten.sonance.net [88.198.58.135]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m24KCG1K014175 for ; Tue, 4 Mar 2008 13:12:17 -0700 (MST) (envelope-from iang@systemics.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id 4D68B57B0B; Tue, 4 Mar 2008 21:12:16 +0100 (CET) Received: from goten.sonance.net ([127.0.0.1]) by localhost (goten.sonance.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HS7wFTaCjfW5; Tue, 4 Mar 2008 21:12:16 +0100 (CET) Received: from zhukov.local (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id C840857AF8; Tue, 4 Mar 2008 21:12:15 +0100 (CET) Message-ID: <47CDAD1E.5030605@systemics.com> Date: Tue, 04 Mar 2008 21:12:14 +0100 From: Ian G User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: David Crick CC: Len Sassaman , ietf-openpgp@imc.org, Andrey Jivsov , "Daniel A. Nagy" Subject: Re: ECC in OpenPGP proposal References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <117bad160803040915h556db896ma53ad69a4a5feb50@mail.gmail.com> <117bad160803040917g75814d55oc63250a0591017bd@mail.gmail.com> <117bad160803041112h5e187096vcc698d071a2e4251@mail.gmail.com> In-Reply-To: <117bad160803041112h5e187096vcc698d071a2e4251@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Lots of questions! For me, the confusion is swirling around these questions: The proposal in question is: (a) Suite B (b) ECC, and/or (c) mobile Is it one of these? All of them? Two of them? I would argue that (a) sounds good. When the NSA speaks, I listen. (normally it is the other way around...) I like their Suite B and would copy it exactly, word for word, no deviations. (b) sounds less good, as this involves much more work (e.g., doing it properly) and would tempt me to say "wait for V5!" or "just listen to the NSA, guys." (c) is something that should be done by the mobile guys, as Dani pointed out, there are special things that need to be considered. One-size-fits-all will probably result in nobody being happy. iang From owner-ietf-openpgp@mail.imc.org Tue Mar 4 12:39:59 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEA373A6DCF for ; Tue, 4 Mar 2008 12:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[AWL=-0.586, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5KKImJheGz2 for ; Tue, 4 Mar 2008 12:39:58 -0800 (PST) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 1AB4228C6C4 for ; Tue, 4 Mar 2008 12:38:27 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m24KM27O014895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 13:22:02 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m24KM2T7014894; Tue, 4 Mar 2008 13:22:02 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from brainhub.org (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m24KM017014885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Mar 2008 13:22:01 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from [63.251.255.221] (63-251-255-221.pgp.com [63.251.255.221] (may be forged)) by brainhub.org (8.14.2/8.14.1) with ESMTP id m24KLqSd006119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 12:21:53 -0800 Message-ID: <47CDAF5B.9050105@brainhub.org> Date: Tue, 04 Mar 2008 12:21:47 -0800 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Ian G , ietf-openpgp@imc.org CC: "Daniel A. Nagy" , David Crick Subject: Re: ECC in OpenPGP proposal References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C7FDEA.5070103@systemics.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <47CD6DAE.9010409@systemics.com> In-Reply-To: <47CD6DAE.9010409@systemics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I respectfully remind you that the target of this proposal is 1) to better match AES key strength with OpenPGP by extending RFC 4880, 2) to meet Suite-B, 3) to offer more usable alternative for mobile/embedded systems. Suite B is limited to section 11.2. Suite B will have limited interoperability with RFC 4880, just like currently FIPS certification is incompatible with RFC 4880. Most of your comments in this e-mail apply to small section 11.2. The discussion earlier was mostly about OpenPGP ECC keys that are compatible with RFC 4880. Ian G wrote: > OK, I think I found it. Sorry for not keeping up! > > > > Daniel A. Nagy wrote: >> I think, Andrey makes a very important point here. The option to use >> 3DES >> symmetric encryption, SHA1 digest and ZLIB compression must remain >> open until >> a formal process of phasing them out is initiated, with a clear road >> map. >> Right now, excluding these algorithms would break interoperability in >> a very >> bad way, as described by Andrey. > > > I disagree, below :) > > >> Of course, SHA1 and 3DES are not without problems, but for most >> security-critical applications they are still perfectly adequate. > > > Right. The question is not about the security of the algorithms > (which are more or less Pareto-secure-ish). Instead, it is about the > business aspects of delivering the most security to the most people. > > >> On Fri, Feb 29, 2008 at 09:36:11PM -0800, Andrey Jivsov wrote: >>> David Crick wrote: >>> ... >>>> The ecc-pre-6.txt's section 2 pretty much says "this is how to >>>> do ECC with AES," and we've said that this proposal is a "MAY." >>>> In a sense this is therefore some kind of a fork (sub-superset?) >>>> of 4880, so we're not concerned with 3DES (or CAST), and - as >>>> with DSA - we can make specific restrictions in order to meet >>>> compliance. > > Yes. This is a natural fork. It is for people who want Suite B. > Which means the various USG organisations. Which before have not in > the past been that impressed with OpenPGP. Actually, not impressed > with anything in the open world, I'd say. We are really in new > territory now that the NSA/NIST people have opened their hearts and > declared Suite B. > > Which isn't to say that we shouldn't consider compatibility, but to > say that this is a good, natural fork. We should also think about > taking it... > > (I would. I remember the pain that was PGP 5.) > > >>> I think we need to be careful here. Let's examine a use case. >>> >>> I am a user of some RFC 4880 OpenPGP application. All algorithms are >>> available to me, e.g. I am not a government employee. >>> >>> * I use the application to encrypt mail to 5 recipients, my friends. >>> They use RSA/DSA/ElGamal keys. >>> >>> * I upgraded the application to the next version that happened to >>> implement "ECC in OpenPGP". >>> >>> I assume that we agree that if I encrypt to exactly the same 5 >>> people with new version, as far as algorithm selection is concerned, >>> the result is identical to the previous version. >>> >>> * I added 6th recipient to the list, which uses ECDH key. > > > OK I see that. If... > >>> I hope we will agree that it must be possible to send single e-mail >>> to 6 recipients. RFC 4880 specifies that the default encryption >>> algorithm is 3DES, thus, there is always a match. Why shouldn't >>> single e-mail be sent to 6 recipients with 3DES symmetric key? > > > Sorry, I don't agree. The RFC4880 specification is only for > applications that apply (more or less) to RFC4880! > > Applications that implement both RFC4880 *and* OpenPGP/ECC/Suite B are > given no guarantee that this is likely to be seamless and joyful and > without any degradation in their promised user experience. > > Just like S/MIME and RFC4880. > > To imagine otherwise would be to say that RFC4880's promise is that > *all future work* is also compatible. That's hopeless. How far do we > want to take that promise? OpenPGP quantum key exchange? What > happens if the Russkies decide they want an OpenPGP GOST and they > decide it is incompatible by definition with OpenPGP ECC? Or, we can > retitle S/MIME as OpenPGP/S/Mime and insist on compatibility :) > > My point: It is *not* a given that people using OpenPGP Suite B can > talk to people using RFC4880. Desirable, sure, but not a given. > > (I'd bet the NSA would prefer this *not* to be the case ;) > > Example: Consider properly written small-device platforms using the > ECC stuff: They will likely implement the AES128-ECC-SHA "small" > profile, and not include 3DES at all. The last thing anyone in the > smart card / mobile world wants is incompatibility forced by vestigial > circumstances. They want all *their* people talking, and that means > one system, one algorithm. Talking to other people is a distant > second in most business plans, and a controversial one at that. > > >>> If the application is operating in Suite-B mode, or FIPS more, etc, >>> then the situation is different. > > > Yes, there are security ramifications. Are we really implementing > Suite B if the application can leak info by sending out emails > encrypted in Suite B (strong) and in 3DES to some 512 RSA key (not so > strong)? > > iang From owner-ietf-openpgp@mail.imc.org Tue Mar 4 12:50:11 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EA7C3A67D0 for ; Tue, 4 Mar 2008 12:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mj79rmgUjcNg for ; Tue, 4 Mar 2008 12:50:10 -0800 (PST) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 0691B28C697 for ; Tue, 4 Mar 2008 12:48:15 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m24KXLZf015613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 13:33:21 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m24KXLC9015612; Tue, 4 Mar 2008 13:33:21 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m24KXJv7015605 for ; Tue, 4 Mar 2008 13:33:20 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by wf-out-1314.google.com with SMTP id 28so1133067wff.28 for ; Tue, 04 Mar 2008 12:33:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=9Audti9sF4YVUr9NPSNRbyImIy5xxGIqHcRHsj1qvNI=; b=TzH9UELllirmE7uxiinh17973LiR/XI5zYox4qivOx2c7vHkWGBzn/qH96FeBbZdUjHNDMEGrC/JpcKmnT1qe42bxve6O7K0fqgziGLJiVNam0oHLTjLtJ3QwE4DX3/xZhOjKKwZVgDsBmWTFiSpvySHgVv1TDjk8cjx4dS+qY4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hHdHzrKcaBfPDKHXORLUhHHdCMQcY2cd8uwqPzDcAB3nC6rKpqXOLDPT9PpkFTuoi9Wqn8PgFVPQBVlAsMQiqn9FwisLgLqiOcAqYpraPtzoOLFiQi1xo6u8qKcrNCtgEz6WK7Tipwtal44wEgl3JNbhU8TIVRFFfanLvX5QTD0= Received: by 10.142.178.13 with SMTP id a13mr605688wff.129.1204662799575; Tue, 04 Mar 2008 12:33:19 -0800 (PST) Received: by 10.143.172.3 with HTTP; Tue, 4 Mar 2008 12:33:19 -0800 (PST) Message-ID: <117bad160803041233l56ee9d22ge585c5533c280c1d@mail.gmail.com> Date: Tue, 4 Mar 2008 20:33:19 +0000 From: "David Crick" To: "Ian G" Subject: Re: ECC in OpenPGP proposal Cc: "Len Sassaman" , ietf-openpgp@imc.org, "Andrey Jivsov" , "Daniel A. Nagy" In-Reply-To: <47CDAD1E.5030605@systemics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <117bad160803040915h556db896ma53ad69a4a5feb50@mail.gmail.com> <117bad160803040917g75814d55oc63250a0591017bd@mail.gmail.com> <117bad160803041112h5e187096vcc698d071a2e4251@mail.gmail.com> <47CDAD1E.5030605@systemics.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 3/4/08, Ian G wrote: > Lots of questions! For me, the confusion is swirling around > these questions: > > The proposal in question is: > > (a) Suite B > (b) ECC, and/or > (c) mobile the *original* document basically suggested (a), *BUT* with the unsaid (but since spelled out) point that 3DES is implicitly *also* allowed *if* we are extending 4880 / interoperating with 4880. > Is it one of these? All of them? Two of them? was have since shifted to (b), with the (c) bit as the MUST. > I would argue that (a) sounds good. When the NSA speaks, I > listen. It's the biggest endorsement (particularly after Suite B) that [a subset of] our OpenPGP algorithms could possibly have. > (normally it is the other way around...) LOL > I like > their Suite B and would copy it exactly, word for word, no > deviations. ideally, yes, I'd say this too (extra ideally, I'd just go for their bigger suite, the SHA384-AES256-ECC384_DH_DSA). > (b) sounds less good, as this involves much more work (e.g., > doing it properly) and would tempt me to say "wait for V5!" > or "just listen to the NSA, guys." agree with you on all your points here > (c) is something that should be done by the mobile guys, as > Dani pointed out, there are special things that need to be > considered. I think it was Dani that said that AES128 was too slow on the Nokia (and so he was using RC4)? In any case, I agree that just justifying the smaller algorithms "*because of* mobiles" isn't in itself necessarily right. (However, choosing the smaller algorithms "because of mobiles *and* because they're secure enough generally *and* because they're a Suite B subset *is* closer to what we're saying) > One-size-fits-all will probably result in nobody being happy. > > iang How unhappy would *you* (personally; this is also open to other people!) be with (each stage being possible points of objection): 1) AES128-SHA256-ECC256 as the MUST (still talking V4 btw) 2) with 3DES as an implicit MUST for 4880 interoperability 2a) wording to encourage (SHOULD) matching algo. sizes 2b) wording to point out additional restrictions for Suite B 3) Future V5 keys to possibly make further restrictions From owner-ietf-openpgp@mail.imc.org Tue Mar 4 13:20:30 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F5903A6C7B for ; Tue, 4 Mar 2008 13:20:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.281 X-Spam-Level: X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[AWL=-0.469, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4uhDEH3Uark for ; Tue, 4 Mar 2008 13:20:29 -0800 (PST) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 725C73A6E2E for ; Tue, 4 Mar 2008 13:18:25 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m24Ktdeq017285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 13:55:39 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m24Ktd38017284; Tue, 4 Mar 2008 13:55:39 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from brainhub.org (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m24Ktbf1017277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Mar 2008 13:55:38 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from [63.251.255.221] (63-251-255-221.pgp.com [63.251.255.221] (may be forged)) by brainhub.org (8.14.2/8.14.1) with ESMTP id m24KtNfb006353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 12:55:27 -0800 Message-ID: <47CDB736.5030100@brainhub.org> Date: Tue, 04 Mar 2008 12:55:18 -0800 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Ian G CC: David Crick , Len Sassaman , ietf-openpgp@imc.org, "Daniel A. Nagy" Subject: Re: ECC in OpenPGP proposal References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <117bad160803040915h556db896ma53ad69a4a5feb50@mail.gmail.com> <117bad160803040917g75814d55oc63250a0591017bd@mail.gmail.com> <117bad160803041112h5e187096vcc698d071a2e4251@mail.gmail.com> <47CDAD1E.5030605@systemics.com> In-Reply-To: <47CDAD1E.5030605@systemics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Once again, this proposal is for each 3 of 1) ECC with OpenPGP within RFC 4880, 2) Suite B and 3) mobile. This is a pragmatic proposal to extend RFC4880 to get benefits in each of 3 areas. This may not be perfect, for example, for PC folks and for mobile folks if they only focus on their hardware, but I believe it can be agreed upon if interested parties forgo some features in the interest of interoperability. This promotes the idea of a single key. Instead of having a SuiteB key, why not have an RFC 4880 ECC key that can be used for SuiteB or OpenPGP, PCs, PDAs, smartcards, HSMs, depending on software configuration? Regarding V5, I don't see justification for it. I would view ECC DSA is a variant of DSA. Granted, it as a change in public key algorithm, but we have a mechanism to add new public key algorithm to RFC 4880. Ian G wrote: > Lots of questions! For me, the confusion is swirling around these > questions: > > The proposal in question is: > > (a) Suite B > (b) ECC, and/or > (c) mobile > > Is it one of these? All of them? Two of them? > > I would argue that (a) sounds good. When the NSA speaks, I listen. > (normally it is the other way around...) I like their Suite B and > would copy it exactly, word for word, no deviations. > > (b) sounds less good, as this involves much more work (e.g., doing it > properly) and would tempt me to say "wait for V5!" or "just listen to > the NSA, guys." > > (c) is something that should be done by the mobile guys, as Dani > pointed out, there are special things that need to be considered. > > One-size-fits-all will probably result in nobody being happy. > > iang From owner-ietf-openpgp@mail.imc.org Tue Mar 4 19:56:29 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3AB83A68AD for ; Tue, 4 Mar 2008 19:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=-0.390, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHRYqMOYJqIa for ; Tue, 4 Mar 2008 19:56:27 -0800 (PST) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 5CEC83A69DC for ; Tue, 4 Mar 2008 19:56:27 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m253f7FT018574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 20:41:07 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m253f7j7018573; Tue, 4 Mar 2008 20:41:07 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from brainhub.org (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m253f5iu018565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Mar 2008 20:41:06 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from [63.251.255.221] (63-251-255-221.pgp.com [63.251.255.221] (may be forged)) by brainhub.org (8.14.2/8.14.1) with ESMTP id m253f180009752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 19:41:02 -0800 Message-ID: <47CE1648.6050402@brainhub.org> Date: Tue, 04 Mar 2008 19:40:56 -0800 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: David Crick Subject: Re: ECC in OpenPGP proposal References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <47CC7750.7080206@brainhub.org> <117bad160803031449p1efb03bao654561db48a5dbb2@mail.gmail.com> <47CD0451.9000503@brainhub.org> <117bad160803040655x3f393c7cuda72f361fbd119a4@mail.gmail.com> In-Reply-To: <117bad160803040655x3f393c7cuda72f361fbd119a4@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Crick wrote: > On 3/4/08, Andrey Jivsov wrote: > >> David Crick wrote: >> >> We need 3DES as a fallback default to smoothly integrate ECC keys >> >> into existing installed base, as I mentioned earlier. >> >> >> > >> > then (reluctantly, but not violently against) how about: >> > >> > MAY implement ECC >> > o MUST implement SHA256 >> > o MUST implement ECC256 >> > [ o MUST implement 3DES - directly inherited from 4880, like it or not] >> > o MUST implement AES128 [or just inherit the SHOULD from 4880??] >> > >> > o SHOULD implement AES256-SHA512-521ECC >> > o MAY implement AES256-SHA384-384ECC >> > >> > o SHOULD try to match cipher strength with ECC strength, where >> > recipient key preferences allow. >> > >> > (then need to add wording in about restrictions required for if strict >> > Suite B compliance is required.) >> > >> >> >> David, I agree with this. >> >> Assuming this is consensus, I will change section 11.1 to "MUST >> implement curve with ID 1 and SHOULD implement curve with ID 3". Also in >> section 11.1, I will change to "MUST implement SHA2-256 and should >> implement SHA2-512,", dropping curve ID 2 and dropping SHA2-384 as MUST >> for OpenPGP profile. >> > > this sounds like what what we've got to so far, although I note > that this makes the [AES256-]SHA384-384ECC an *implicit* MAY > rather than *specifically* mentioning SHA384 and ECC384 as > MAYs. > > So, should we *explicitly* mention them? > My thoughts on MAY were that since this spec is MAY in relation to RFC4880, the explicit MAYs on defined or otherwise referenced algorithms are redundant. If we define a curve and don't list it as SHOULD or MUST, I assumed that it follows that it is MAY. Where do you see a benefit of explicit MAY? 384 ECC is defined in this spec, thus is MAY. SHA382 is MAY from RFC 4880 and AES256 is SHOULD in this spec. Can using MAY once create questions as to why other combinations are not MAYs? > (also, an aside regarding repetition of a point I've previous made: > the (e.g.) keywrapping text in -pre6 only talks about AES; this > needs to be made more general, referring instead to keylengths.) > You are right, there is a dependency on AES in this spec. It is currently required in AESWrap key wrapping method. I realize that you may have interpreted this differently. I prefer we fix AES with AESWrap method, and this is how the -pre6 is written. The argument about multiple recipients doesn't apply here, but relative strength does. I suppose that even embedded devices can use AES-256 as KEK for key wrapping and AES-128 for message encryption (or any other algorithm for latter) , because the performance of AESWrap is not an issue on up to 48 bytes (the availability in hardware probably is). In any case, any of 3 AES variants are allowed in current proposal for AESWrap, plus, we have AES-256 as SHOULD. For example, http://www.ellipticsemi.com/products-clp-34.php shows hardware implementation, which is hardwired to AES 128 or 256. (Just to be clear, nothing in this section applies to the choice of algorithm for symmetric message encryption key.) >> I will add a few sentences about Suite B and RFC4880 (in)compatibility. >> The problems are very very similar to the issue of FIPS mode of >> operation and RFC 4880. >> > > yes > > >> Regarding algorithm tupples, Section 12 already lists >> AES256-SHA512-521ECC and AES256-SHA384-384ECC as SHOULD combinations. >> > > the -pre6 document specifically lists P384-SHA384-AES192 > in 12 (which, as per NIST, *are* the matching strengths), with > the "MAY use stronger" in the paragraph before the table, but > with the the AES256 (as per Suite B) in 11.2.2 before. > > All these pieces *together* allow for our discussed > AES256-SHA384-384ECC combination, i.e. to support Suite B > and to "drop" AES192. > Yes. The main reason to keep 192 is interoperability. >> I think it is better to break tupples into 3 pieces and address them >> independently. >> > > Maybe it's because I haven't re-read the document as a whole > with all our changes in place, but I'm personally finding it a bit > hard to read our discussed cipher suggestions when they are > split up as they currently are. > > Do you want to try producing a -pre7 so that we can see if we > think it (a) matches our growing consensus and, (b) says it in > a clear manner? > > If it does then great, otherwise some section, paragraph and > topic re-ordering might be required. > Yes, I will update the spec based on latest feedback. >> The choice of symmetric algorithm is governed by key >> preferences of (multiple) recipients. We shouldn't disregard preference >> list and prefer AES-256 (even for ECC keys). >> > > 4880 section 13.2 says this: > > An implementation MUST NOT use a symmetric algorithm that is not in > the recipient's preference list. When encrypting to more than one > recipient, the implementation finds a suitable algorithm by taking > the intersection of the preferences of the recipients. Note that the > MUST-implement algorithm, TripleDES, ensures that the intersection is > not null. *The implementation may use any mechanism to pick an > algorithm in the intersection.* > > I suggest we *use* this freedom by (but!) tightening it in OpenPGP ECC > applications. So, our ECC document would have something like: > > Having obtained an intersection of symmetric algorithm preferences, > implementations SHOULD attempt to match symmetric algorithm size > with public key size. > I note that this issue is orthogonal to this spec, i.e. it applies to RFC 4880 as well. However, if there is a consensus, we can recommend this. One justification for "why now" is, practically speaking, ECC allows balanced strength while RFC 4880 doesn't. However, I would try to stay within RFC4880. The issue of tightening is similar to other restrictions I put in section 12: MDC: SHOULD, S2K: iterated salted, SHA-1: MUST NOT. Ian suggested MDC/S2K to be MUST. > [*Personally*, I'd like to continue: > ", favouring longer lengths where possible."] > While we should not deprive implementations the allowed method to advertise prioritized preferences, I think we there is a room for improvement in "grey areas". For example, * Two recipient keys have following ordered prefs.: {AES128, AES256} and {AES256, AES128}. * RFC 4880 allows either of these sets to be the ordered intersection. In this case we can "tighten" as you suggested. Many of these issues are in the realm of key managing software. If user is adding single AES128 preference to ECDH 521, the software can warn her. > The following table provides current equivalent recommendations > (SP800-57). Note TripleDES is considered to have 112-bit security. > > Asymmetric | Hash | Symmetric | Elliptic > key size | size | key size | curve key > (RSA + D-H) | | | size > ------------+--------+-------------------------- > 1024 160 80 160 > 2048 224 112 224 > 3072 256 128 256 > 7680 384 192 384 > 15360 512 256 521 > > [the columns should probably be in a "better" order, this was > just copied from 4800 with ECC then added on the end] > > > >> So section 11.1 tell >> MUST/SHOULD for individual algorithms and section 12 gives SHOULD >> recommendations regarding dependencies between algorithms. >> > > Subject to my "clarity" point above, then OK, yes, I can see > this is how you are conveying this at present. > > > >> After above changes to section 11.1, the only missing correction there >> is "SHOULD implement AES-256". >> > > yup. > I will integrate feedback from everybody into the next revision. Thank you. From owner-ietf-openpgp@mail.imc.org Wed Mar 5 03:06:11 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D02F13A6BD5 for ; Wed, 5 Mar 2008 03:06:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M15jdHx+Q9Yp for ; Wed, 5 Mar 2008 03:06:08 -0800 (PST) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id A77353A6BA5 for ; Wed, 5 Mar 2008 03:06:07 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m25Af6R0063003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Mar 2008 03:41:06 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m25Af6tw063002; Wed, 5 Mar 2008 03:41:06 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from goten.sonance.net (goten.sonance.net [88.198.58.135]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m25Af43Y062991 for ; Wed, 5 Mar 2008 03:41:06 -0700 (MST) (envelope-from iang@systemics.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id 55A9057B0F; Wed, 5 Mar 2008 11:41:01 +0100 (CET) Received: from goten.sonance.net ([127.0.0.1]) by localhost (goten.sonance.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsDmlkpjrfZk; Wed, 5 Mar 2008 11:41:01 +0100 (CET) Received: from zhukov.local (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id DB13A57B0B; Wed, 5 Mar 2008 11:41:00 +0100 (CET) Message-ID: <47CE78BD.3000300@systemics.com> Date: Wed, 05 Mar 2008 11:41:01 +0100 From: Ian G User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Andrey Jivsov CC: ietf-openpgp@imc.org, David Crick Subject: Re: ECC in OpenPGP proposal References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <47CC7750.7080206@brainhub.org> <117bad160803031449p1efb03bao654561db48a5dbb2@mail.gmail.com> <47CD0451.9000503@brainhub.org> <117bad160803040655x3f393c7cuda72f361fbd119a4@mail.gmail.com> <47CE1648.6050402@brainhub.org> In-Reply-To: <47CE1648.6050402@brainhub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Andrey Jivsov wrote: > My thoughts on MAY were that since this spec is MAY in relation to > RFC4880, the explicit MAYs on defined or otherwise referenced algorithms > are redundant. If we define a curve and don't list it as SHOULD or MUST, > I assumed that it follows that it is MAY. To me as an implementor I want to see what the defined sets are. Commentary or definition on curves may be all very interesting, but I would want to see the MAY set to understand what the recommendation was. I'd assume other other implementors were also thinking around those MAYs. If the question came up, I'd want the team leader to say "implement only MAYs." She doesn't want them to go beyond the clear compatibility consensus. The code implementations take on a life of their own ... any signals to reduce confusion and tie the implementations within some distance of a common goal are good. A strong MAY set is clearly something we should do if we are looking for a complete implementation. In code world, nobody much has time to do anything that doesn't lead to a clear business imperative. As a generalism, the people who implement the code know a little crypto, but not a lot. They can't see very far. They are employed for their good software skills, their ability to turn specs into live code. What to the crypto / institutional world may be elegence is simply code to these guys. What might be a delicate path through conflicting requirements is a nightmare to the coders, they just don't know what was intended, and have only each other to figure it out. (Just another reason why agility is a nice idea in the crypto tea room, but not robust in reality.) iang From owner-ietf-openpgp@mail.imc.org Wed Mar 5 03:56:53 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 759E128C34A for ; Wed, 5 Mar 2008 03:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id so4sdpC-W1Bz for ; Wed, 5 Mar 2008 03:56:51 -0800 (PST) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 390E528C7EF for ; Wed, 5 Mar 2008 03:56:10 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m25BcONT068705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Mar 2008 04:38:24 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m25BcO1J068704; Wed, 5 Mar 2008 04:38:24 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.190]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m25BcM8o068695 for ; Wed, 5 Mar 2008 04:38:24 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by gv-out-0910.google.com with SMTP id l14so997540gvf.13 for ; Wed, 05 Mar 2008 03:38:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=8W2ejrpDLC9RBpzLa1lecUZs51wFLYrTs4RHAHT4N4A=; b=iDwVOCyF1sn0uwVjn0teww/t72un0aP6pGfBPL3ZNQkl92eK2gVVGC109wAdhJJ8JxGjGr5EcYmERtnEcUFgmd4DiVqZbmd40f61xVdFSXoST4C75i4vriiN6YsBsatdpVqU0rQQMhDi7OL8JZQ5zT22Q+493nIxvhI9MmuWbF4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CgaoUmjg5eIcNAoIb0i63uq9jwymADo1stDQvHqbcsfmo9GFGQ0u/NKCr0UB3l0rW4NmeTEKU2qBLlITDCBKiSMgrkiJWNP5HXwOB2tvPCJzuXnC96xtA9g6DbTpASJNjLnm0rioZvntZDYVQDOFrJx+kEp8JIUtFCtQXtsDUhE= Received: by 10.142.143.7 with SMTP id q7mr754430wfd.3.1204717099905; Wed, 05 Mar 2008 03:38:19 -0800 (PST) Received: by 10.143.172.3 with HTTP; Wed, 5 Mar 2008 03:38:19 -0800 (PST) Message-ID: <117bad160803050338u72ea221i68b1c168ecf39035@mail.gmail.com> Date: Wed, 5 Mar 2008 11:38:19 +0000 From: "David Crick" To: "Ian G" Subject: Re: ECC in OpenPGP proposal Cc: "Andrey Jivsov" , ietf-openpgp@imc.org In-Reply-To: <47CE78BD.3000300@systemics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <47CC7750.7080206@brainhub.org> <117bad160803031449p1efb03bao654561db48a5dbb2@mail.gmail.com> <47CD0451.9000503@brainhub.org> <117bad160803040655x3f393c7cuda72f361fbd119a4@mail.gmail.com> <47CE1648.6050402@brainhub.org> <47CE78BD.3000300@systemics.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 3/5/08, Ian G wrote: > Andrey Jivsov wrote: > > My thoughts on MAY were that since this spec is MAY in relation to > > RFC4880, the explicit MAYs on defined or otherwise referenced algorithms > > are redundant. If we define a curve and don't list it as SHOULD or MUST, > > I assumed that it follows that it is MAY. > > > > To me as an implementor I want to see what the defined sets > are. Commentary or definition on curves may be all very > interesting, but I would want to see the MAY set to > understand what the recommendation was. from my querying of it, I hope it is clear that I would also like to specifically see the (e.g.) ECC384 curve stated as a MAY. And, just to justify this (and to show why 4880 is so readable): 9.1. Public-Key Algorithms Implementations MUST implement ... SHOULD implement ... * Implementations MAY implement any other algorithm.* 9.2. Symmetric-Key Algorithms Implementations MUST ... Implementations SHOULD ... ... need to ... *Implementations MAY implement any other algorithm.* 9.3. Compression Algorithms Implementations MUST ... Implementations SHOULD ... ... *Implementations MAY implement any other algorithm.* 9.4. Hash Algorithms Implementations MUST implement SHA-1. *Implementations MAY implement other algorithms.* > I'd assume other > other implementors were also thinking around those MAYs. If > the question came up, I'd want the team leader to say > "implement only MAYs." She doesn't want them to go beyond > the clear compatibility consensus. > > The code implementations take on a life of their own ... any > signals to reduce confusion and tie the implementations > within some distance of a common goal are good. A strong > MAY set is clearly something we should do if we are looking > for a complete implementation. In code world, nobody much > has time to do anything that doesn't lead to a clear > business imperative. > > As a generalism, the people who implement the code know a > little crypto, but not a lot. They can't see very far. > They are employed for their good software skills, their > ability to turn specs into live code. > > What to the crypto / institutional world may be elegence is > simply code to these guys. What might be a delicate path > through conflicting requirements is a nightmare to the > coders, they just don't know what was intended, and have > only each other to figure it out. > > (Just another reason why agility is a nice idea in the > crypto tea room, but not robust in reality.) > > iang From owner-ietf-openpgp@mail.imc.org Wed Mar 5 04:19:31 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 598C23A68FC for ; Wed, 5 Mar 2008 04:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gb8ckIfuAD6e for ; Wed, 5 Mar 2008 04:19:30 -0800 (PST) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id B0D3D3A68D9 for ; Wed, 5 Mar 2008 04:19:29 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m25BupVm070583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Mar 2008 04:56:51 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m25BupDx070582; Wed, 5 Mar 2008 04:56:51 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m25Buo77070570 for ; Wed, 5 Mar 2008 04:56:51 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by wf-out-1314.google.com with SMTP id 28so1578000wff.28 for ; Wed, 05 Mar 2008 03:56:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Et6w6OQMvW3sK9z7Y7bjlXtzp5fAAspQs3tiw5WdsF4=; b=OZOCEyyUJNMoIwcFzqylwvHQDSK8WidR+uJgSG6mcMBpEBsccEg0/MFrelCqyqZt1z4GckFDutzLtlcE8joxkL1QmhHAHRy7KKcnvMcIgbTsbRo8fcx9W5sGRcJzfEjFYkyqlbDDhRRtlV4eW+84kpIyz8H/16CfCWxUhx5f8Bs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RXeHVcbkQmtDqpgvxsGvI9IJZrnxnhWhUJRvs9HxAa0krrzTely6I1+ewKPm3fxzbuLckwoCXXQSNjMQ18TWY6UgAnbHiOXcick3WJExbTbZSOhCtuZLFmp70cfTx31jmWAvqijBr5IC4ipEFVmF7yfQyT7ziA2v6i1bbT7snWg= Received: by 10.143.162.8 with SMTP id p8mr745004wfo.63.1204718209362; Wed, 05 Mar 2008 03:56:49 -0800 (PST) Received: by 10.143.172.3 with HTTP; Wed, 5 Mar 2008 03:56:48 -0800 (PST) Message-ID: <117bad160803050356h54c755a4m2ada0ec7b53e8b0e@mail.gmail.com> Date: Wed, 5 Mar 2008 11:56:48 +0000 From: "David Crick" To: "Andrey Jivsov" Subject: Re: ECC in OpenPGP proposal Cc: ietf-openpgp@imc.org In-Reply-To: <47CE1648.6050402@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <47CC7750.7080206@brainhub.org> <117bad160803031449p1efb03bao654561db48a5dbb2@mail.gmail.com> <47CD0451.9000503@brainhub.org> <117bad160803040655x3f393c7cuda72f361fbd119a4@mail.gmail.com> <47CE1648.6050402@brainhub.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 3/5/08, Andrey Jivsov wrote: > > this sounds like what what we've got to so far, although I note > > that this makes the [AES256-]SHA384-384ECC an *implicit* MAY > > rather than *specifically* mentioning SHA384 and ECC384 as > > MAYs. > > > > So, should we *explicitly* mention them? > > Where do you see a benefit of explicit MAY? 384 ECC is defined in this > spec, thus is MAY. SHA382 is MAY from RFC 4880 and AES256 is SHOULD in > this spec. readability and understandability (of our intentions/recommendations) > Can using MAY once create questions as to why other combinations are not > MAYs? possibly, but the reverse it more true: it draws attention to the fact that *this* is something you should *consider*. > > (also, an aside regarding repetition of a point I've previous made: > > the (e.g.) keywrapping text in -pre6 only talks about AES; this > > needs to be made more general, referring instead to keylengths.) > > > > > You are right, there is a dependency on AES in this spec. It is > currently required in AESWrap key wrapping method. I realize that you > may have interpreted this differently. I prefer we fix AES with AESWrap > method, and this is how the -pre6 is written. The argument about > multiple recipients doesn't apply here, but relative strength does. I > suppose that even embedded devices can use AES-256 as KEK for key > wrapping and AES-128 for message encryption (or any other algorithm for > latter) , because the performance of AESWrap is not an issue on up to 48 > bytes (the availability in hardware probably is). In any case, any of 3 > AES variants are allowed in current proposal for AESWrap, plus, we have > AES-256 as SHOULD. > > For example, http://www.ellipticsemi.com/products-clp-34.php shows > hardware implementation, which is hardwired to AES 128 or 256. > > (Just to be clear, nothing in this section applies to the choice of > algorithm for symmetric message encryption key.) re the just to be clear, I think this is what has partly muddied the water. But / so (for my sanity ;)), could you please explain how one uses a 3DES session key with ECC D-H? > >> The choice of symmetric algorithm is governed by key > >> preferences of (multiple) recipients. We shouldn't disregard preference > >> list and prefer AES-256 (even for ECC keys). > >> > > > > 4880 section 13.2 says this: > > > > An implementation MUST NOT use a symmetric algorithm that is not in > > the recipient's preference list. When encrypting to more than one > > recipient, the implementation finds a suitable algorithm by taking > > the intersection of the preferences of the recipients. Note that the > > MUST-implement algorithm, TripleDES, ensures that the intersection is > > not null. *The implementation may use any mechanism to pick an > > algorithm in the intersection.* > > > > I suggest we *use* this freedom by (but!) tightening it in OpenPGP ECC > > applications. So, our ECC document would have something like: > > > > Having obtained an intersection of symmetric algorithm preferences, > > implementations SHOULD attempt to match symmetric algorithm size > > with public key size. > > I note that this issue is orthogonal to this spec, i.e. it applies to > RFC 4880 as well. However, if there is a consensus, we can recommend > this. One justification for "why now" is, practically speaking, ECC > allows balanced strength while RFC 4880 doesn't. However, I would try to > stay within RFC4880. > > The issue of tightening is similar to other restrictions I put in > section 12: MDC: SHOULD, S2K: iterated salted, SHA-1: MUST NOT. Ian > suggested MDC/S2K to be MUST. > > > > [*Personally*, I'd like to continue: > > ", favouring longer lengths where possible."] > > While we should not deprive implementations the allowed method to > advertise prioritized preferences, I think we there is a room for > improvement in "grey areas". For example, > > * Two recipient keys have following ordered prefs.: {AES128, AES256} and > {AES256, AES128}. > * RFC 4880 allows either of these sets to be the ordered intersection. > > In this case we can "tighten" as you suggested. great. Again, I'd like to see "clear" wording in the ECC doc to indicate this; otherwise implementers may either miss this fact or be left scratching their heads wondering how to handle it. > Many of these issues are in the realm of key managing software. If user > is adding single AES128 preference to ECDH 521, the software can warn her. > > > > The following table provides current equivalent recommendations > > (SP800-57). Note TripleDES is considered to have 112-bit security. > > > > Asymmetric | Hash | Symmetric | Elliptic > > key size | size | key size | curve key > > (RSA + D-H) | | | size > > ------------+--------+-------------------------- > > 1024 160 80 160 > > 2048 224 112 224 > > 3072 256 128 256 > > 7680 384 192 384 > > 15360 512 256 521 > > > > [the columns should probably be in a "better" order, this was > > just copied from 4800 with ECC then added on the end] just for *me* to make clear :), I was suggesting we add this table into the spec, just as 4880 does in its. As you've said, this key management issue becomes more of an issue as we now have the ability (or the requirement, with Suite B) to match lengths. Again, including this, but spelled out, makes it a lot clearer. > I will integrate feedback from everybody into the next revision. > Thank you. I think the ECC spec fits somewhere between 4880 and the Camellia draft in terms of complexity of detail that is needed to be conveyed. The Camellia draft is wonderfully short, since all it needs to say is "this is an alternative cipher you can use. in limited, certain situations using Camellia can cause interoperability issues." The ECC doc, however, has to spell out why and when using this new public key system would be beneficial, possible ways of using it, the most suitable ways of using it, and some more complex interoperability issues. I therefore feel we need to veer towards using *more* wording to justify and explain usage of OpenPGP-ECC, rather than (necessarily) aiming for the "less is more" approach that may be more preferable in general. From owner-ietf-openpgp@mail.imc.org Thu Mar 6 00:52:45 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 790B128C841 for ; Thu, 6 Mar 2008 00:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[AWL=0.689, BAYES_00=-2.599, URIBL_GREY=0.25] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymCmdgT3-SOm for ; Thu, 6 Mar 2008 00:52:44 -0800 (PST) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 54C7028C861 for ; Thu, 6 Mar 2008 00:52:44 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m268XJHt086610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Mar 2008 01:33:19 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m268XJfw086609; Thu, 6 Mar 2008 01:33:19 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m268XI4m086599 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 6 Mar 2008 01:33:19 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from localhost.localdomain (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by mail.cyberonic.com (8.12.8/8.12.8) with ESMTP id m268Zko5015118 for ; Thu, 6 Mar 2008 03:35:46 -0500 Message-ID: <47CFAC4D.60309@brainhub.org> Date: Thu, 06 Mar 2008 00:33:17 -0800 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: ECC in OpenPGP proposal: how to use ECDH X-Priority: 5 (Lowest) References: <47CFAB50.2040306@brainhub.org> In-Reply-To: <47CFAB50.2040306@brainhub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Erratum 1: nist_aes_wrap is shown in http://brainhub.googlepages.com/aeswrap-RFC3394.c.html, while the algorithm is defined in RFC 3394. From owner-ietf-openpgp@mail.imc.org Thu Mar 6 00:54:35 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F22D3A692C for ; Thu, 6 Mar 2008 00:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.775 X-Spam-Level: X-Spam-Status: No, score=-1.775 tagged_above=-999 required=5 tests=[AWL=0.574, BAYES_00=-2.599, URIBL_GREY=0.25] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vqINNdjVVGg for ; Thu, 6 Mar 2008 00:54:34 -0800 (PST) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id E479F3A696C for ; Thu, 6 Mar 2008 00:54:33 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m268T81M085866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Mar 2008 01:29:08 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m268T8K5085865; Thu, 6 Mar 2008 01:29:08 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m268T664085855 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 6 Mar 2008 01:29:08 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from localhost.localdomain (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by mail.cyberonic.com (8.12.8/8.12.8) with ESMTP id m268VYo5014243 for ; Thu, 6 Mar 2008 03:31:35 -0500 Message-ID: <47CFAB50.2040306@brainhub.org> Date: Thu, 06 Mar 2008 00:29:04 -0800 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: ECC in OpenPGP proposal: how to use ECDH Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Responding to request by David, I will describe in more details what is happening during ECDH encryption, the only encryption scheme allowed in the spec. ( Please check for errata before implementing anything from this. ) High-level overview of the steps: 1) Generate shared EC point 2) Generate KEK from it 3) use KEK with RFC3394 to encrypt symmetric key. Step 1. ECDH public key contains s*G, which is a curve point (think of it as g^s in modp notation). Step 2. Sender generates its secret v and calculates v*G. Then the point S =v*s*G is the initial shared secret. Step 3. Sender arrives at common symmetric message encryption key algorithm for the recipients. The algorithm is encoded with a byte from RFC4880, for example, for AES -128 use 7. Sender generates random string of appropriate length for the key and appends it to the algorithm ID, for example: 07 R1 R2 R3 R4 R5 R6 R7 R8 R9 Ra Rb Rc Rd Re Rf R10 where R* is a random byte. Step 4. Sender appends 16 byte checksum to this string: 07 R1 R2 R3 R4 R5 R6 R7 R8 R9 Ra Rb Rc Rd Re Rf R10 C0 C1 (This is what passed in RFC4880 to PKCS#1 padding.) Step 5. Set KDF parameter like this: Param = 01 16 01 0a 09 "AnonymousSender" F0 F1 F2 ... F14 This setting assumes recipient curve ID 1, IANA assignment of value 22=0x16 for ECDH, SHA512 for KDF (ID 10=0xa), AES-256 for AESWrap. F* is the 20 byte fingerprint of the recipient. There are always 40 bytes here. Step 6. Pass 40 byte KDF parameter from step 5 and point S from step 2 to KDF in section 6 http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-6.html#toc5 . KDF works in counter-mode-style and outputs KEK. Stop when sufficient number of bits for selected AESWrap algorithm is generated (AES-256 in our example, so we need 32 bytes). * Using KEK from step 6 and string in step 4, call nist_aes_wrap, defined in http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-6.html. nist_aes_wrap( c, kPGPCipherAlgorithm_AES256, KEK, 32, {07 R1 R2 R3 R4 R5 R6 R7 R8 R9 Ra Rb Rc Rd Re Rf R10 C0 C1}, 19, out, 32, &actual_size ); AES-128, AES-256, AES-256, SHA2-256, SHA2-384, and SHA2-512 are the only algorithms allowed with AESWrap and KDF. This restriction has no relation to message encryption symmetric key or hash used for message signing. The following is not mentioned in the spec, but I think the sender should start from the AES-256 and SHA-512 and move down to choose weaker algorithms if recipient has excluded these algorithms from its key preferences for encryption or hash list. From owner-ietf-openpgp@mail.imc.org Thu Mar 6 13:55:04 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9DB928C25D for ; Thu, 6 Mar 2008 13:55:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.929 X-Spam-Level: X-Spam-Status: No, score=-0.929 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9evX-zgt4Z3 for ; Thu, 6 Mar 2008 13:55:04 -0800 (PST) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 4413828C1B6 for ; Thu, 6 Mar 2008 13:55:03 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m26LUXYp079871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Mar 2008 14:30:33 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m26LUXU3079870; Thu, 6 Mar 2008 14:30:33 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from carter-zimmerman.suchdamage.org (dhcp-18-188-10-61.dyn.mit.edu [18.188.10.61]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m26LUWYi079863 for ; Thu, 6 Mar 2008 14:30:33 -0700 (MST) (envelope-from hartmans@mit.edu) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 21527476B; Thu, 6 Mar 2008 16:30:31 -0500 (EST) From: Sam Hartman To: ietf-openpgp@imc.org Cc: tim.polk@nist.gov, pasi.eronen@nokia.com Subject: Closing the openpgp working group Date: Thu, 06 Mar 2008 16:30:31 -0500 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, folks. Back in January Derek started a thread on a new charter. That never really came to any conclusion. I had given Derek a deadline to produce a charter that is well past. So, I'm going to close the openpgp working group. If people ever do get a concrete proposal together, please don't hesitate to contact the security ADs at the time this happens and propose a new working group. From owner-ietf-openpgp@mail.imc.org Thu Mar 6 14:15:03 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 022D93A6922 for ; Thu, 6 Mar 2008 14:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPDYXR8IE8ut for ; Thu, 6 Mar 2008 14:14:39 -0800 (PST) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id E43AA28C8E5 for ; Thu, 6 Mar 2008 14:13:42 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m26LrgYd081670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Mar 2008 14:53:42 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m26LrgWD081669; Thu, 6 Mar 2008 14:53:42 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m26LreiY081662 for ; Thu, 6 Mar 2008 14:53:41 -0700 (MST) (envelope-from buanzo@buanzo.com.ar) Received: by an-out-0708.google.com with SMTP id c23so26706anc.44 for ; Thu, 06 Mar 2008 13:53:32 -0800 (PST) Received: by 10.100.92.9 with SMTP id p9mr827996anb.22.1204840412549; Thu, 06 Mar 2008 13:53:32 -0800 (PST) Received: from ?10.10.0.4? ( [201.235.164.113]) by mx.google.com with ESMTPS id c28sm6236258anc.32.2008.03.06.13.53.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 06 Mar 2008 13:53:30 -0800 (PST) Message-ID: <47D067D4.1090907@buanzo.com.ar> Date: Thu, 06 Mar 2008 19:53:24 -0200 From: "Arturo 'Buanzo' Busleiman" Organization: GNU/Buanzo User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: Sam Hartman CC: ietf-openpgp@imc.org, tim.polk@nist.gov, pasi.eronen@nokia.com Subject: Re: Closing the openpgp working group References: In-Reply-To: X-Enigmail-Version: 0.95.6 OpenPGP: id=6857704D Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Sam Hartman wrote: | If people ever do get a concrete proposal together, please don't | hesitate to contact the security ADs at the time this happens and | propose a new working group. Ouch. Well, I guess the HTTP Working Group would be the ideal place for me to continue my involvement with the IETF regarding OpenPGP for HTTP? - -- Arturo "Buanzo" Busleiman Reliable inter-continental Mail Relay Service - Ask me! Independent Security Consultant - SANS - OISSG http://www.buanzo.com.ar/pro/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH0GfUAlpOsGhXcE0RCg5EAJ9EbztkOEhxJfvJsQt3kjg5U8t7JgCcDtvw Dy7ZhDa0xiYDqqW5ww3F9xA= =ksNA -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Thu Mar 6 14:29:45 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68F563A6AD3 for ; Thu, 6 Mar 2008 14:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zO2IKXwTZ7fe for ; Thu, 6 Mar 2008 14:29:44 -0800 (PST) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id E5DA63A6E05 for ; Thu, 6 Mar 2008 14:29:11 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m26MAH8K082895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Mar 2008 15:10:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m26MAHJT082894; Thu, 6 Mar 2008 15:10:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m26MAGiJ082872 for ; Thu, 6 Mar 2008 15:10:17 -0700 (MST) (envelope-from derek@ihtfp.com) Received: from pgpdev.ihtfp.org (c-76-109-52-251.hsd1.fl.comcast.net [76.109.52.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail.ihtfp.org (Postfix) with ESMTP id BB8FABD8588; Thu, 6 Mar 2008 17:10:10 -0500 (EST) Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.1/8.14.1/Submit) id m26MA670006033; Thu, 6 Mar 2008 17:10:06 -0500 To: Sam Hartman Cc: ietf-openpgp@imc.org, tim.polk@nist.gov, pasi.eronen@nokia.com Subject: Re: Closing the openpgp working group References: From: Derek Atkins Date: Thu, 06 Mar 2008 17:10:05 -0500 In-Reply-To: (Sam Hartman's message of "Thu\, 06 Mar 2008 16\:30\:31 -0500") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sam, Sam Hartman writes: > Hi, folks. Back in January Derek started a thread on a new charter. > That never really came to any conclusion. I had given Derek a > deadline to produce a charter that is well past. So, I'm going to > close the openpgp working group. > > If people ever do get a concrete proposal together, please don't > hesitate to contact the security ADs at the time this happens and > propose a new working group. The fact that it didn't come to conclusion is just a result of my not driving the process enough. There's clearly work that people want to get done, including active development in: ECC v5 Keys OpenPGP in TLS Indeed, we've had lots of discussion in the past couple weeks. Sam, you did give me until the end of January and it's now March. Clearly I'm just not on the ball here, but I do think there's enough work to warrant keeping the group open. Can I get one more week to come up with a proposed charter? -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From owner-ietf-openpgp@mail.imc.org Thu Mar 6 14:37:03 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C3EA3A6AAD for ; Thu, 6 Mar 2008 14:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrrZIAnDP8pu for ; Thu, 6 Mar 2008 14:37:02 -0800 (PST) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id F2AC03A6C50 for ; Thu, 6 Mar 2008 14:37:01 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m26MLY90084542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Mar 2008 15:21:35 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m26MLYgo084541; Thu, 6 Mar 2008 15:21:34 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m26MLXC7084531 for ; Thu, 6 Mar 2008 15:21:34 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.jabberwocky.com (c-75-69-177-157.hsd1.ma.comcast.net [75.69.177.157]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id m26MLVu26795 for ; Thu, 6 Mar 2008 17:21:32 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.1/8.14.1) with ESMTP id m26MLRH9007985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Mar 2008 17:21:27 -0500 Received: from grover.jabberwocky.com (localhost.localdomain [127.0.0.1]) by grover.jabberwocky.com (8.14.1/8.13.8) with ESMTP id m26MLRT9030926 for ; Thu, 6 Mar 2008 17:21:27 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.14.1/8.14.1/Submit) id m26MLQck030925 for ietf-openpgp@imc.org; Thu, 6 Mar 2008 17:21:26 -0500 Date: Thu, 6 Mar 2008 17:21:26 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Closing the openpgp working group Message-ID: <20080306222126.GA30886@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <47D067D4.1090907@buanzo.com.ar> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47D067D4.1090907@buanzo.com.ar> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.15 (2007-05-20) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 06, 2008 at 07:53:24PM -0200, Arturo 'Buanzo' Busleiman wrote: > > Sam Hartman wrote: > | If people ever do get a concrete proposal together, please don't > | hesitate to contact the security ADs at the time this happens and > | propose a new working group. > > Ouch. Well, I guess the HTTP Working Group would be the ideal place for me to continue my > involvement with the IETF regarding OpenPGP for HTTP? This doesn't mean the mailing list is going away. Just that the WG status is. If and when we are ready, we can try and charter a new group. We have three things that are being discussed right now (ECC, Camellia and Whirlpool). I'd say the Camellia draft is basically ready to go once we handle the charter. David From owner-ietf-openpgp@mail.imc.org Thu Mar 6 14:44:35 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2775D3A6F4C for ; Thu, 6 Mar 2008 14:44:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.368 X-Spam-Level: X-Spam-Status: No, score=-1.368 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfBYRIS6ADXK for ; Thu, 6 Mar 2008 14:44:34 -0800 (PST) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 8BAE33A6F95 for ; Thu, 6 Mar 2008 14:44:06 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m26MTpxh085241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Mar 2008 15:29:51 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m26MTpMU085240; Thu, 6 Mar 2008 15:29:51 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from carter-zimmerman.suchdamage.org (STRATTON-THREE-SEVENTY-NINE.MIT.EDU [18.187.6.124]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m26MTov0085233 for ; Thu, 6 Mar 2008 15:29:51 -0700 (MST) (envelope-from hartmans@mit.edu) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E69CD476B; Thu, 6 Mar 2008 17:29:49 -0500 (EST) From: Sam Hartman To: "Arturo 'Buanzo' Busleiman" Cc: ietf-openpgp@imc.org, tim.polk@nist.gov, pasi.eronen@nokia.com Subject: Re: Closing the openpgp working group References: <47D067D4.1090907@buanzo.com.ar> Date: Thu, 06 Mar 2008 17:29:49 -0500 In-Reply-To: <47D067D4.1090907@buanzo.com.ar> (Arturo Busleiman's message of "Thu, 06 Mar 2008 19:53:24 -0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >>>>> "Arturo" == Arturo 'Buanzo' Busleiman writes: Arturo> Sam Hartman wrote: Arturo> | If people ever do get a concrete proposal together, please don't Arturo> | hesitate to contact the security ADs at the time this happens and Arturo> | propose a new working group. Arturo> Ouch. Well, I guess the HTTP Working Group would be the ideal place for me to continue my Arturo> involvement with the IETF regarding OpenPGP for HTTP? OpenPGP for HTTP is out of scope in both the HTTP and OpenPGP charters as they existed before I closed the OpenPGP working group. You would need a new group either way. From owner-ietf-openpgp@mail.imc.org Thu Mar 6 14:52:45 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F5C83A6AA8 for ; Thu, 6 Mar 2008 14:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIh9XDefqqei for ; Thu, 6 Mar 2008 14:52:44 -0800 (PST) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 405B23A6A93 for ; Thu, 6 Mar 2008 14:52:44 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m26MWnCJ085441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Mar 2008 15:32:49 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m26MWnYi085440; Thu, 6 Mar 2008 15:32:49 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m26MWnOO085434 for ; Thu, 6 Mar 2008 15:32:49 -0700 (MST) (envelope-from buanzo@buanzo.com.ar) Received: by an-out-0708.google.com with SMTP id c23so35762anc.44 for ; Thu, 06 Mar 2008 14:32:49 -0800 (PST) Received: by 10.100.95.19 with SMTP id s19mr952750anb.9.1204842768594; Thu, 06 Mar 2008 14:32:48 -0800 (PST) Received: from ?10.10.0.4? ( [201.235.164.113]) by mx.google.com with ESMTPS id c2sm5492639ana.4.2008.03.06.14.32.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 06 Mar 2008 14:32:46 -0800 (PST) Message-ID: <47D07108.4090804@buanzo.com.ar> Date: Thu, 06 Mar 2008 20:32:40 -0200 From: "Arturo 'Buanzo' Busleiman" Organization: GNU/Buanzo User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: Sam Hartman CC: ietf-openpgp@imc.org, tim.polk@nist.gov, pasi.eronen@nokia.com Subject: Re: Closing the openpgp working group References: <47D067D4.1090907@buanzo.com.ar> In-Reply-To: X-Enigmail-Version: 0.95.6 OpenPGP: id=6857704D Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Sam Hartman wrote: | OpenPGP for HTTP is out of scope in both the HTTP and OpenPGP charters | as they existed before I closed the OpenPGP working group. You would | need a new group either way. Sounds like good advice. Thanks Sam. PS: Totally OFFTOPIC. I'll arrive to Las Vegas tomorrow Friday 7th, 6pm (Las V. time). Anyone attending 2600 Meeting there PLEASE contact me. Or if any of you is into security, I'll also stay in charlotte March 10-16. - -- Arturo "Buanzo" Busleiman Reliable inter-continental Mail Relay Service - Ask me! Independent Security Consultant - SANS - OISSG http://www.buanzo.com.ar/pro/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH0HEIAlpOsGhXcE0RCs0TAJ9BCjDptdefGOogHePaHrP+uWAFYACdEIFG ZPTD7ngCYpusX5tEd+cGQow= =/V0g -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Mon Mar 10 07:10:44 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3212293CC6 for ; Mon, 10 Mar 2008 07:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqbNveSnqfp2 for ; Mon, 10 Mar 2008 07:10:36 -0700 (PDT) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 3E056293E20 for ; Mon, 10 Mar 2008 06:51:38 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2ADIIa7041242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Mar 2008 06:18:18 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2ADIInT041241; Mon, 10 Mar 2008 06:18:18 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from goten.sonance.net (goten.sonance.net [88.198.58.135]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2ADIFfD041232 for ; Mon, 10 Mar 2008 06:18:17 -0700 (MST) (envelope-from iang@systemics.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id 7888D57B17; Mon, 10 Mar 2008 14:18:14 +0100 (CET) Received: from goten.sonance.net ([127.0.0.1]) by localhost (goten.sonance.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bv4hSXOCRrwU; Mon, 10 Mar 2008 14:18:14 +0100 (CET) Received: from zhukov.local (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id 1FC3D57B0F; Mon, 10 Mar 2008 14:18:14 +0100 (CET) Message-ID: <47D53515.5050201@systemics.com> Date: Mon, 10 Mar 2008 14:18:13 +0100 From: Ian G User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: Sam Hartman , tim.polk@nist.gov, pasi.eronen@nokia.com Subject: Re: Closing the openpgp working group References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sam Hartman wrote: > > Hi, folks. Back in January Derek started a thread on a new charter. > That never really came to any conclusion. I had given Derek a > deadline to produce a charter that is well past. So, I'm going to > close the openpgp working group. > > If people ever do get a concrete proposal together, please don't > hesitate to contact the security ADs at the time this happens and > propose a new working group. If this has indeed happened, I guess the next step is creating enough momentum for V5 key structure. How much enthusiasm is there for this? Enough to generate some consensus? Is there a business case for a redesign? How much are groups going to invest into OpenPGP in the future, and how much would they save if a redesign cleaned things up? If the answer is in the positive, I'd suggest putting in place a wiki somewhere. We need some way of working on the various parts in parallel. iang From owner-ietf-openpgp@mail.imc.org Mon Mar 10 10:38:40 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D70D3A6ADC for ; Mon, 10 Mar 2008 10:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OYh-RFP5zqM for ; Mon, 10 Mar 2008 10:38:39 -0700 (PDT) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 27CF03A690C for ; Mon, 10 Mar 2008 10:38:37 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2AHC9XY066291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Mar 2008 10:12:09 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2AHC8wE066290; Mon, 10 Mar 2008 10:12:08 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.179]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2AHC5ST066271 for ; Mon, 10 Mar 2008 10:12:06 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by ik-out-1112.google.com with SMTP id c29so919884ika.2 for ; Mon, 10 Mar 2008 10:12:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Dpb9oIyoLQ49bQ3DU1tfswaNLSrpiKoKv1TNqWY2PCM=; b=xzWRXY5UoDZDVIjHpvZ/PDSn+CJsqFvaQEzEPt4V7wRAYWfvrDdUsL/JZbCUSn4rewcVVwNsVh72hWP5U2Nq79ktErpQh3qZr2HN1cGfTUb0dkRBwQRO5AlKitw4om35Ljug30uNwmrLp6xYjGXTrZJzTM7/abcIFKTpTV/cAK4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=eyXzUGoZJrLXT/W/OohrFu5HMGIxHVzBYsls8dGtCwl68r6mCXMcU7n5qse0c0du0Tfn1g6ihjy4Qy+TnmPowMQ/W4gl33R3MqM8SCRrgNkAoP6UOa/Uf1Q94Z/P1sCcbGzkLmETjNTAn47rbKdR0i82ak8V5IQUoTSboNM6pqs= Received: by 10.142.128.6 with SMTP id a6mr1947712wfd.138.1205169123301; Mon, 10 Mar 2008 10:12:03 -0700 (PDT) Received: by 10.143.188.1 with HTTP; Mon, 10 Mar 2008 10:12:03 -0700 (PDT) Message-ID: <117bad160803101012m52d22fdnd9aba86fc0ea33b1@mail.gmail.com> Date: Mon, 10 Mar 2008 17:12:03 +0000 From: "David Crick" To: "Ian G" Subject: Re: Closing the openpgp working group Cc: ietf-openpgp@imc.org In-Reply-To: <47D53515.5050201@systemics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47D53515.5050201@systemics.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 3/10/08, Ian G wrote: > > Sam Hartman wrote: > > > > Hi, folks. Back in January Derek started a thread on a new charter. > > That never really came to any conclusion. I had given Derek a > > deadline to produce a charter that is well past. So, I'm going to > > close the openpgp working group. > > > > If people ever do get a concrete proposal together, please don't > > hesitate to contact the security ADs at the time this happens and > > propose a new working group. > > > If this has indeed happened, I guess the next step is > creating enough momentum for V5 key structure. > > How much enthusiasm is there for this? Enough to generate > some consensus? Is there a business case for a redesign? "doesn't use SHA1" sounds like a good V5 business case.... > How much are groups going to invest into OpenPGP in the > future, and how much would they save if a redesign cleaned > things up? > > If the answer is in the positive, I'd suggest putting in > place a wiki somewhere. We need some way of working on the > various parts in parallel. > > iang From owner-ietf-openpgp@mail.imc.org Mon Mar 10 11:44:48 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C65D73A6C7D for ; Mon, 10 Mar 2008 11:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npOtESOVpb1R for ; Mon, 10 Mar 2008 11:44:48 -0700 (PDT) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id A133528C2F1 for ; Mon, 10 Mar 2008 11:44:47 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2AIM92U074242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Mar 2008 11:22:09 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2AIM9Lv074241; Mon, 10 Mar 2008 11:22:09 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2AIM7qg074230 for ; Mon, 10 Mar 2008 11:22:09 -0700 (MST) (envelope-from derek@ihtfp.com) Received: from pgpdev.ihtfp.org (72-255-2-16.client.stsn.net [72.255.2.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail.ihtfp.org (Postfix) with ESMTP id 66A70BD8589 for ; Mon, 10 Mar 2008 14:22:06 -0400 (EDT) Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.1/8.14.1/Submit) id m2AILko4015811; Mon, 10 Mar 2008 14:21:46 -0400 To: ietf-openpgp@imc.org Subject: More on the closing of the OpenPGP WG From: Derek Atkins Date: Mon, 10 Mar 2008 14:21:46 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, I sat down with Sam, Tim, and Pasi yesterday to talk about this. Basically, it's still possible to have a "standards track" document without a working group. They still need to go through an IETF Last Call but the AD can sponsor the draft (instead of having a WG Group). So long as the drafts are not very contentious (which MOST of our proposed work is), we can just continue to drafts as individual submissions and an AD (Tim?) could sponsor that once we have rough consensus on this list. This list can (and will) remain alive. So we can continue to discuss Camillia, ECC, and Whirlpool on this list and then get documents passed through the IETF/IESG Last Call process. If it turns out that we do have some contentious work (e.g. the HTTP-PGP work), then we might need something more. Note that we do not necessarily need a BOF in order to get a new working group. It's not a requirement. So, if we DO have work that really does require a WG, then it COULD be reformed. So, a summary: 1) This List will remain open and as active as we make it. 2) We can continue to do OpenPGP work in the IETF 3) We can continue to get I-Ds and Standards-track RFCs published 4) We can get a new group constituted if we need to, but Tim assures me that based on the proposed work we probably don't need to. Please let me know how you feel about this. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From owner-ietf-openpgp@mail.imc.org Mon Mar 10 14:07:06 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A8F228C46F for ; Mon, 10 Mar 2008 14:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uon54cI+SfXV for ; Mon, 10 Mar 2008 14:07:04 -0700 (PDT) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id DCB7728C569 for ; Mon, 10 Mar 2008 14:05:32 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2AKibti089556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Mar 2008 13:44:37 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2AKiboC089555; Mon, 10 Mar 2008 13:44:37 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2AKiU5w089511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 10 Mar 2008 13:44:34 -0700 (MST) (envelope-from simon@josefsson.org) Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2AKiFvj002620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Mar 2008 21:44:16 +0100 From: Simon Josefsson To: Derek Atkins Cc: ietf-openpgp@imc.org Subject: Re: More on the closing of the OpenPGP WG References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:080310:derek@ihtfp.com::Msdb6MhYcBOVUhfu:0RWH X-Hashcash: 1:22:080310:ietf-openpgp@imc.org::9wDSGaqsr7k9TVPd:6Dd1 Date: Mon, 10 Mar 2008 21:44:15 +0100 In-Reply-To: (Derek Atkins's message of "Mon, 10 Mar 2008 14:21:46 -0400") Message-ID: <8763vue2cg.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Derek Atkins writes: > Hi, > > I sat down with Sam, Tim, and Pasi yesterday to talk about this. > Basically, it's still possible to have a "standards track" document > without a working group. They still need to go through an IETF > Last Call but the AD can sponsor the draft (instead of having a > WG Group). So long as the drafts are not very contentious (which > MOST of our proposed work is), we can just continue to drafts > as individual submissions and an AD (Tim?) could sponsor that > once we have rough consensus on this list. > > This list can (and will) remain alive. So we can continue to discuss > Camillia, ECC, and Whirlpool on this list and then get documents > passed through the IETF/IESG Last Call process. > > If it turns out that we do have some contentious work (e.g. the > HTTP-PGP work), then we might need something more. Note that > we do not necessarily need a BOF in order to get a new working > group. It's not a requirement. So, if we DO have work that really > does require a WG, then it COULD be reformed. > > So, a summary: > > 1) This List will remain open and as active as we make it. > 2) We can continue to do OpenPGP work in the IETF > 3) We can continue to get I-Ds and Standards-track RFCs published > 4) We can get a new group constituted if we need to, but Tim assures > me that based on the proposed work we probably don't need to. > > Please let me know how you feel about this. I'm curious whether we can get the OpenPGP header document published without a WG or not. A few MUAs parses the header (Gnus, enigmail, squirrelmail, if I understand correctly). /Simon From owner-ietf-openpgp@mail.imc.org Mon Mar 10 14:50:34 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D990C28C3CE for ; Mon, 10 Mar 2008 14:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJdxsE9FZGBX for ; Mon, 10 Mar 2008 14:50:34 -0700 (PDT) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 6FE5428C2EF for ; Mon, 10 Mar 2008 14:50:30 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2ALSxbg094953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Mar 2008 14:28:59 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2ALSx4q094952; Mon, 10 Mar 2008 14:28:59 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from goten.sonance.net (goten.sonance.net [88.198.58.135]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2ALSutp094933 for ; Mon, 10 Mar 2008 14:28:57 -0700 (MST) (envelope-from iang@systemics.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id D2CB357B17; Mon, 10 Mar 2008 22:28:55 +0100 (CET) Received: from goten.sonance.net ([127.0.0.1]) by localhost (goten.sonance.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tvwCq0pxEOK; Mon, 10 Mar 2008 22:28:55 +0100 (CET) Received: from zhukov.local (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id 8AB4F57AF8; Mon, 10 Mar 2008 22:28:55 +0100 (CET) Message-ID: <47D5A817.8040901@systemics.com> Date: Mon, 10 Mar 2008 22:28:55 +0100 From: Ian G User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Derek Atkins CC: ietf-openpgp@imc.org Subject: Re: More on the closing of the OpenPGP WG References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Derek Atkins wrote: > Hi, > > I sat down with Sam, Tim, and Pasi yesterday to talk about this. > Basically, it's still possible to have a "standards track" document > without a working group. They still need to go through an IETF > Last Call but the AD can sponsor the draft (instead of having a > WG Group). So long as the drafts are not very contentious (which > MOST of our proposed work is), we can just continue to drafts > as individual submissions and an AD (Tim?) could sponsor that > once we have rough consensus on this list. That sounds fine to me. Is the only reason for a WG that we have to have an open forum if there is contention? > This list can (and will) remain alive. So we can continue to discuss > Camillia, ECC, and Whirlpool on this list and then get documents > passed through the IETF/IESG Last Call process. > > If it turns out that we do have some contentious work (e.g. the > HTTP-PGP work), then we might need something more. Note that > we do not necessarily need a BOF in order to get a new working > group. It's not a requirement. So, if we DO have work that really > does require a WG, then it COULD be reformed. > > So, a summary: > > 1) This List will remain open and as active as we make it. > 2) We can continue to do OpenPGP work in the IETF > 3) We can continue to get I-Ds and Standards-track RFCs published > 4) We can get a new group constituted if we need to, but Tim assures > me that based on the proposed work we probably don't need to. > > Please let me know how you feel about this. I vote yes, let's go informal on this list. iang From owner-ietf-openpgp@mail.imc.org Mon Mar 10 15:43:06 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79D633A6A35 for ; Mon, 10 Mar 2008 15:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.562 X-Spam-Level: X-Spam-Status: No, score=-0.562 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1, URIBL_GREY=0.25] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfUPG7NXNaG7 for ; Mon, 10 Mar 2008 15:43:05 -0700 (PDT) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 61F963A69EB for ; Mon, 10 Mar 2008 15:43:05 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2AMGDBB000248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Mar 2008 15:16:13 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2AMGDxe000247; Mon, 10 Mar 2008 15:16:13 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from brainhub.org (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2AMGBS4000239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 10 Mar 2008 15:16:12 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from [63.251.255.221] (63-251-255-221.pgp.com [63.251.255.221] (may be forged)) by brainhub.org (8.14.2/8.14.1) with ESMTP id m2AMGBxc009418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 10 Mar 2008 15:16:11 -0700 Message-ID: <47D5A517.1010409@brainhub.org> Date: Mon, 10 Mar 2008 14:16:07 -0700 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: ECC in OpenPGP proposal, second revision References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <47CC7750.7080206@brainhub.org> <117bad160803031449p1efb03bao654561db48a5dbb2@mail.gmail.com> <47CD0451.9000503@brainhub.org> <117bad160803040655x3f393c7cuda72f361fbd119a4@mail.gmail.com> <47CE1648.6050402@brainhub.org> <117bad160803050356h54c755a4m2ada0ec7b53e8b0e@mail.gmail.com> In-Reply-To: <117bad160803050356h54c755a4m2ada0ec7b53e8b0e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Here is the updated revision of the proposal that incorporates most requested corrections that was possible to make without breaking or severely affecting interoperability. http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-7.txt The same document in other formats: http://brainhub.googlepages.com/pgp . Here is the partial list of changes: 1. Make curve ID 1 MUST, ID 3 SHOULD. 2. MUST SHA2-256 and SHOULD implement SHA2-512 3. Note on Suite-B / OpenPGP incompatibility 4. MUST support ECDSA and and ECDH 5. MDC MUST, MUST use Iterated and Salted S2K 6. Note on matching relative strength specified in section 12. 7. Removed open reference to hashes (removed "or its successor"). 8. SHOULD use stronger algorithm, while maintaining RFC4880 rules Thank you again for your comments. From owner-ietf-openpgp@mail.imc.org Tue Mar 11 06:13:54 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4968E28C384 for ; Tue, 11 Mar 2008 06:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, URIBL_GREY=0.25] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGnvjHYdJt0n for ; Tue, 11 Mar 2008 06:13:50 -0700 (PDT) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 7018328C427 for ; Tue, 11 Mar 2008 06:13:42 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BChqcc002171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2008 05:43:52 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2BChqDH002170; Tue, 11 Mar 2008 05:43:52 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BChn2W002161 for ; Tue, 11 Mar 2008 05:43:51 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by wf-out-1314.google.com with SMTP id 28so2270497wff.28 for ; Tue, 11 Mar 2008 05:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=IjHDbHAYnXkBqoJaHRBzBj7nIUzU8Ow6dLqS++ubGhM=; b=twMhhN8itL89rDYL7leCYBx2yLgmcTZCUJn/rZO/HcXEr9P+YfUSKyNJGBwGo1LOkBFuJguyP/q2lnPaq9aFMHwMXZnvYcX40FXo9w8iOl5wUzHV1uDaqIcLknN/5CCT/JffxyF+qojK1DbCKBk/1gK3Tkyili9SGLMBXqBKR3Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mPXbCXRcc4EPmjqYxJGMbNQFNfiElmwzkUZH8CxyLqhA5Rw5bmo+NfCJKnKTVhYzL6mNe7JOEFuiLrM8W1hy11wzhpUG8m/ssi4xZeVTXgGEiQB9KlUhiHFBisN46WiYJ+MbzgYZr0ArkS/ZLNyViJi4K1OlOC4bwl+yE07Btfs= Received: by 10.142.52.9 with SMTP id z9mr2500224wfz.134.1205239428563; Tue, 11 Mar 2008 05:43:48 -0700 (PDT) Received: by 10.143.188.1 with HTTP; Tue, 11 Mar 2008 05:43:48 -0700 (PDT) Message-ID: <117bad160803110543vf22ecd1y8fdb3ac0409912e7@mail.gmail.com> Date: Tue, 11 Mar 2008 12:43:48 +0000 From: "David Crick" To: "Andrey Jivsov" Subject: Re: ECC in OpenPGP proposal, second revision Cc: ietf-openpgp@imc.org In-Reply-To: <47D5A517.1010409@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <47CC7750.7080206@brainhub.org> <117bad160803031449p1efb03bao654561db48a5dbb2@mail.gmail.com> <47CD0451.9000503@brainhub.org> <117bad160803040655x3f393c7cuda72f361fbd119a4@mail.gmail.com> <47CE1648.6050402@brainhub.org> <117bad160803050356h54c755a4m2ada0ec7b53e8b0e@mail.gmail.com> <47D5A517.1010409@brainhub.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 11.1 I would like to see "MAY implement curve ID 2" explicitly stated (this *is* mentioned in section 12, but would like to see it here too) 11.3 says "The best remedy to this .. is to add .. AES-256" not sure about "best" - perhaps "simplest"? The reason being is that as AES128 is an ECC must, then this guarantees us *a* Suite B acceptable cipher, although - as you're trying to get at - having AES256 means that we'd cover *both* Suite B profiles. I'm not sure if I agree with the sentiment of "adding .. to .. each recipient's key" - doesn't quite sound right? (Maybe because it sounds like sender coercion, rather than a higher-level admin led policy?) 12 "It is generally advisable to list at the head of the preference list a symmetric algorithm of strength corresponding to the public key." Again, I see what you're trying to say, but as is noted elsewhere in the ECC doc, it's merely the intersection - it's up to the implementation to make its own decision thereafter (and so take advantage of any ordering information). I think section 12 also needs to explicitly deprecate AES-192, saying that it's not necessarily going to be fielded widely (bring in the fact that it is only a MAY here might help), isn't one of the Suite B ciphers, and that it's probably only suitable if for some reason you *really* need a 192-bit cipher: otherwise go for AES256 for security or -128 for performance. overall, though, I think we're getting there. On 3/10/08, Andrey Jivsov wrote: > > Here is the updated revision of the proposal that incorporates most > requested corrections that was possible to make without breaking or > severely affecting interoperability. > > http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-7.txt > > The same document in other formats: > http://brainhub.googlepages.com/pgp . > > Here is the partial list of changes: > > 1. Make curve ID 1 MUST, ID 3 SHOULD. > 2. MUST SHA2-256 and SHOULD implement SHA2-512 > 3. Note on Suite-B / OpenPGP incompatibility > 4. MUST support ECDSA and and ECDH > 5. MDC MUST, MUST use Iterated and Salted S2K > 6. Note on matching relative strength specified in section 12. > 7. Removed open reference to hashes (removed "or its successor"). > 8. SHOULD use stronger algorithm, while maintaining RFC4880 rules > > Thank you again for your comments. > > From owner-ietf-openpgp@mail.imc.org Tue Mar 11 07:22:15 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2566828C48E for ; Tue, 11 Mar 2008 07:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLrISnEsG4Sv for ; Tue, 11 Mar 2008 07:22:14 -0700 (PDT) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id EB14828C46F for ; Tue, 11 Mar 2008 07:21:48 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BE1oo6010290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2008 07:01:50 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2BE1og7010289; Tue, 11 Mar 2008 07:01:50 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BE1mXp010282 for ; Tue, 11 Mar 2008 07:01:49 -0700 (MST) (envelope-from derek@ihtfp.com) Received: from pgpdev.ihtfp.org (unknown [130.129.82.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail.ihtfp.org (Postfix) with ESMTP id 2CACABD8464; Tue, 11 Mar 2008 10:01:48 -0400 (EDT) Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.1/8.14.1/Submit) id m2BE1lHO026085; Tue, 11 Mar 2008 10:01:47 -0400 To: Simon Josefsson Cc: ietf-openpgp@imc.org Subject: Re: More on the closing of the OpenPGP WG References: <8763vue2cg.fsf@mocca.josefsson.org> From: Derek Atkins Date: Tue, 11 Mar 2008 10:01:47 -0400 In-Reply-To: <8763vue2cg.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Mon\, 10 Mar 2008 21\:44\:15 +0100") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Simon Josefsson writes: > I'm curious whether we can get the OpenPGP header document published > without a WG or not. A few MUAs parses the header (Gnus, enigmail, > squirrelmail, if I understand correctly). I don't see why not. I don't think it would be very contentious. > /Simon -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From owner-ietf-openpgp@mail.imc.org Tue Mar 11 07:30:09 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6793E28C50F for ; Tue, 11 Mar 2008 07:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jq1SIoi1eWzy for ; Tue, 11 Mar 2008 07:30:08 -0700 (PDT) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 4DD6E28C4BF for ; Tue, 11 Mar 2008 07:29:13 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BE4fYU010479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2008 07:04:41 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2BE4f0q010478; Tue, 11 Mar 2008 07:04:41 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BE4eIj010472 for ; Tue, 11 Mar 2008 07:04:40 -0700 (MST) (envelope-from derek@ihtfp.com) Received: from pgpdev.ihtfp.org (unknown [130.129.82.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail.ihtfp.org (Postfix) with ESMTP id 65B90BD8464; Tue, 11 Mar 2008 10:04:40 -0400 (EDT) Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.1/8.14.1/Submit) id m2BE4dTd026123; Tue, 11 Mar 2008 10:04:39 -0400 To: Ian G Cc: ietf-openpgp@imc.org Subject: Re: More on the closing of the OpenPGP WG References: <47D5A817.8040901@systemics.com> From: Derek Atkins Date: Tue, 11 Mar 2008 10:04:39 -0400 In-Reply-To: <47D5A817.8040901@systemics.com> (Ian G.'s message of "Mon\, 10 Mar 2008 22\:28\:55 +0100") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ian G writes: > Derek Atkins wrote: >> Hi, >> >> I sat down with Sam, Tim, and Pasi yesterday to talk about this. >> Basically, it's still possible to have a "standards track" document >> without a working group. They still need to go through an IETF >> Last Call but the AD can sponsor the draft (instead of having a >> WG Group). So long as the drafts are not very contentious (which >> MOST of our proposed work is), we can just continue to drafts >> as individual submissions and an AD (Tim?) could sponsor that >> once we have rough consensus on this list. > > > That sounds fine to me. Is the only reason for a WG that we have to > have an open forum if there is contention? I don't think that's the only reason.. It's mainly provides a means to gauge consensus before it gets to the whole IETF, and provides a means to streamline the process so it's not all on the AD's shoulders. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From owner-ietf-openpgp@mail.imc.org Tue Mar 11 11:28:46 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 418463A6810 for ; Tue, 11 Mar 2008 11:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iYjm2vVoPOh for ; Tue, 11 Mar 2008 11:28:45 -0700 (PDT) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 15A2B3A681A for ; Tue, 11 Mar 2008 11:28:44 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BI28TO034990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2008 11:02:08 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2BI28r6034989; Tue, 11 Mar 2008 11:02:08 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BI279f034983 for ; Tue, 11 Mar 2008 11:02:07 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.jabberwocky.com (c-75-69-177-157.hsd1.ma.comcast.net [75.69.177.157]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id m2BI25N02175 for ; Tue, 11 Mar 2008 13:02:05 -0500 Received: from jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.1/8.14.1) with SMTP id m2BI20su013204 for ; Tue, 11 Mar 2008 14:02:00 -0400 Date: Tue, 11 Mar 2008 14:02:00 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: More on the closing of the OpenPGP WG Message-ID: <20080311180200.GC4826@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.17 (2007-11-01) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Mar 10, 2008 at 02:21:46PM -0400, Derek Atkins wrote: > > Hi, > > I sat down with Sam, Tim, and Pasi yesterday to talk about this. > Basically, it's still possible to have a "standards track" document > without a working group. They still need to go through an IETF > Last Call but the AD can sponsor the draft (instead of having a > WG Group). So long as the drafts are not very contentious (which > MOST of our proposed work is), we can just continue to drafts > as individual submissions and an AD (Tim?) could sponsor that > once we have rough consensus on this list. [..] > Please let me know how you feel about this. I think that is just fine, and thanks for working this out. I have a minor process question though: I've done a couple of Camellia drafts as "draft-ietf-openpgp-camellia". Do I need to convert that to "draft-shaw-openpgp-camellia" (i.e. an individual submission) and re-submit? David From owner-ietf-openpgp@mail.imc.org Wed Mar 12 11:10:35 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55C413A6996 for ; Wed, 12 Mar 2008 11:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDtFFvlIU5if for ; Wed, 12 Mar 2008 11:10:34 -0700 (PDT) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id B8B6628C715 for ; Wed, 12 Mar 2008 11:10:33 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2CHTtsJ092800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Mar 2008 10:29:55 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2CHTtBD092799; Wed, 12 Mar 2008 10:29:55 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2CHTs9H092776 for ; Wed, 12 Mar 2008 10:29:54 -0700 (MST) (envelope-from derek@ihtfp.com) Received: from pgpdev.ihtfp.org (unknown [130.129.82.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail.ihtfp.org (Postfix) with ESMTP id CA92FBD858B for ; Wed, 12 Mar 2008 13:29:50 -0400 (EDT) Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.1/8.14.1/Submit) id m2CHTnMa014583; Wed, 12 Mar 2008 13:29:49 -0400 To: ietf-openpgp@imc.org Subject: Re: More on the closing of the OpenPGP WG References: <20080311180200.GC4826@jabberwocky.com> From: Derek Atkins Date: Wed, 12 Mar 2008 13:29:49 -0400 In-Reply-To: <20080311180200.GC4826@jabberwocky.com> (David Shaw's message of "Tue\, 11 Mar 2008 14\:02\:00 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Shaw writes: [snip] > I think that is just fine, and thanks for working this out. > > I have a minor process question though: I've done a couple of Camellia > drafts as "draft-ietf-openpgp-camellia". Do I need to convert that to > "draft-shaw-openpgp-camellia" (i.e. an individual submission) and > re-submit? No, it can stay as 'draft-ietf-openpgp-'. No need to rename and resubmit as an individual. > David -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From owner-ietf-openpgp@mail.imc.org Thu Mar 13 08:50:22 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECC6828C0F5 for ; Thu, 13 Mar 2008 08:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPH9oVsEO9YS for ; Thu, 13 Mar 2008 08:50:22 -0700 (PDT) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id E2CC03A6C3E for ; Thu, 13 Mar 2008 08:50:19 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DFNp9X054411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2008 08:23:51 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2DFNpfc054410; Thu, 13 Mar 2008 08:23:51 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DFNoJK054386 for ; Thu, 13 Mar 2008 08:23:51 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.jabberwocky.com (c-75-69-177-157.hsd1.ma.comcast.net [75.69.177.157]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id m2DFNlN18648 for ; Thu, 13 Mar 2008 10:23:47 -0500 Received: from jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.1/8.14.1) with SMTP id m2DFNgSO029802 for ; Thu, 13 Mar 2008 11:23:42 -0400 Date: Thu, 13 Mar 2008 11:23:41 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Ready for Camellia? (was: More on the closing of the OpenPGP WG) Message-ID: <20080313152341.GB1587@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20080311180200.GC4826@jabberwocky.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.17 (2007-11-01) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Mar 12, 2008 at 01:29:49PM -0400, Derek Atkins wrote: > > David Shaw writes: > > [snip] > > I think that is just fine, and thanks for working this out. > > > > I have a minor process question though: I've done a couple of Camellia > > drafts as "draft-ietf-openpgp-camellia". Do I need to convert that to > > "draft-shaw-openpgp-camellia" (i.e. an individual submission) and > > re-submit? > > No, it can stay as 'draft-ietf-openpgp-'. No need to rename and > resubmit as an individual. Great, thanks. I think we're ready for the final push on Camellia. All of the suggested changes have been incorporated, and if folks could give it a final read, I'd appreciate it: http://www.ietf.org/internet-drafts/draft-ietf-openpgp-camellia-01.txt I would particulary appreciate comments on the choice of 128 and 256-bit keys (that is, lacking 192). I tend to agree with Jon that 192 is neither here nor there, but I'm also a major fan of consistency. If we're going to include 192 for the ECC work, then it's odd to leave it out here. David From owner-ietf-openpgp@mail.imc.org Thu Mar 13 13:20:12 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CAB53A6EF8 for ; Thu, 13 Mar 2008 13:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfz8qW8Fz+Xs for ; Thu, 13 Mar 2008 13:20:11 -0700 (PDT) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 2A9CB3A6AC1 for ; Thu, 13 Mar 2008 13:20:10 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DJuIZ6081736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2008 12:56:18 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2DJuIUP081735; Thu, 13 Mar 2008 12:56:18 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DJuGVL081727 for ; Thu, 13 Mar 2008 12:56:17 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by wf-out-1314.google.com with SMTP id 28so3471666wff.28 for ; Thu, 13 Mar 2008 12:56:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=NlN5S8VQXf6qcT8j05xkIoPMmtrPOTnQrqZrX3jNOKQ=; b=HwAE5S13QNGVzK8JK3gIYkgGvXziYidhXD7pSosaYWJYrSq1ZQvLO4bOTQ/ywoDeODHKKvBa9MNIrjUm53iXBUs5TDceJDRPGLAUiAlCCII6876VfnV0GY9Gt/JbR7OhHw84XJBMG7mQnahPwLtJIeaO+QyykeE/U1i+qLOlyaE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qdJCmKwoTuwe9zH/YWdhoWrppztmxlrdE3PF54hcHW5A5l1YYh+YXR64LndqvSffyv24yfpUPM+AYEfIs0AzgXZTPNoIJjVMQ3/lvn3MylfUncqXF5cpNawgAdQq0d7hBMU2rnz5s+Na+llYP0vOELWLrtysZ0jEPT8CsUWNNZs= Received: by 10.143.162.8 with SMTP id p8mr4678037wfo.49.1205438175936; Thu, 13 Mar 2008 12:56:15 -0700 (PDT) Received: by 10.143.188.1 with HTTP; Thu, 13 Mar 2008 12:56:15 -0700 (PDT) Message-ID: <117bad160803131256j7137be61k69fc15080df04b6c@mail.gmail.com> Date: Thu, 13 Mar 2008 19:56:15 +0000 From: "David Crick" To: ietf-openpgp@imc.org, "David Shaw" Subject: Re: Ready for Camellia? (was: More on the closing of the OpenPGP WG) In-Reply-To: <20080313152341.GB1587@jabberwocky.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080311180200.GC4826@jabberwocky.com> <20080313152341.GB1587@jabberwocky.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I think we're ready for the final push on Camellia. All of the > suggested changes have been incorporated, and if folks could give it a > final read, I'd appreciate it: > http://www.ietf.org/internet-drafts/draft-ietf-openpgp-camellia-01.txt I had a look over this (-01) when you first posted it, and couldn't find fault. > I would particulary appreciate comments on the choice of 128 and > 256-bit keys (that is, lacking 192). I tend to agree with Jon that > 192 is neither here nor there, but I'm also a major fan of > consistency. If we're going to include 192 for the ECC work, then > it's odd to leave it out here. I suggested in my comments on the most recent (-07) ECC draft that we should explicitly deprecate AES-192 in ECC; I'd be tempted to say the same about Camellia-192, but I equally see the point of having an alternative to *each* of the three AES cipher lengths. So I think I'm abstaining on Camellia-192 - I'm not going to speicifically ask/vote for it to be included, but at the same time I won't protest if others wanted it in. From owner-ietf-openpgp@mail.imc.org Thu Mar 13 14:04:26 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9DA03A6A30 for ; Thu, 13 Mar 2008 14:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.494 X-Spam-Level: X-Spam-Status: No, score=-1.494 tagged_above=-999 required=5 tests=[AWL=0.755, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRcd2k792S2Z for ; Thu, 13 Mar 2008 14:04:25 -0700 (PDT) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id F35C83A6803 for ; Thu, 13 Mar 2008 14:04:18 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DKTslN083903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2008 13:29:54 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2DKTsKI083902; Thu, 13 Mar 2008 13:29:54 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DKTqbX083869 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 13 Mar 2008 13:29:54 -0700 (MST) (envelope-from fw@deneb.enyo.de) Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1JZu0X-00060e-J8; Thu, 13 Mar 2008 21:26:33 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1JZu0W-0003gd-VQ; Thu, 13 Mar 2008 21:26:32 +0100 From: Florian Weimer To: "David Crick" Cc: "Ian G" , ietf-openpgp@imc.org Subject: Re: Closing the openpgp working group References: <47D53515.5050201@systemics.com> <117bad160803101012m52d22fdnd9aba86fc0ea33b1@mail.gmail.com> Date: Thu, 13 Mar 2008 21:26:32 +0100 In-Reply-To: <117bad160803101012m52d22fdnd9aba86fc0ea33b1@mail.gmail.com> (David Crick's message of "Mon, 10 Mar 2008 17:12:03 +0000") Message-ID: <87r6eebcav.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * David Crick: >> How much enthusiasm is there for this? Enough to generate >> some consensus? Is there a business case for a redesign? > > "doesn't use SHA1" sounds like a good V5 business case.... Yes, some of us do check-list based security, and not having to rely on SHA-1 is helpful in this area. From owner-ietf-openpgp@mail.imc.org Thu Mar 13 14:38:09 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FFCF3A6845 for ; Thu, 13 Mar 2008 14:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.01 X-Spam-Level: * X-Spam-Status: No, score=1.01 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_EQ_HU=1.245, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVpeDPpt7GZs for ; Thu, 13 Mar 2008 14:38:08 -0700 (PDT) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 5CF963A6A64 for ; Thu, 13 Mar 2008 14:38:08 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DL7cTF086995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2008 14:07:38 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2DL7cO2086994; Thu, 13 Mar 2008 14:07:38 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DL7aFT086987 for ; Thu, 13 Mar 2008 14:07:37 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 6F7CD4A84; Thu, 13 Mar 2008 22:02:57 +0100 (CET) Date: Thu, 13 Mar 2008 22:02:56 +0100 To: Florian Weimer Cc: David Crick , Ian G , ietf-openpgp@imc.org Subject: Re: Closing the openpgp working group Message-ID: <20080313210256.GC18071@epointsystem.org> References: <47D53515.5050201@systemics.com> <117bad160803101012m52d22fdnd9aba86fc0ea33b1@mail.gmail.com> <87r6eebcav.fsf@mid.deneb.enyo.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline In-Reply-To: <87r6eebcav.fsf@mid.deneb.enyo.de> User-Agent: Mutt/1.5.9i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 13, 2008 at 09:26:32PM +0100, Florian Weimer wrote: >=20 > * David Crick: >=20 > >> How much enthusiasm is there for this? Enough to generate > >> some consensus? Is there a business case for a redesign? > > > > "doesn't use SHA1" sounds like a good V5 business case.... >=20 > Yes, some of us do check-list based security, and not having to rely on > SHA-1 is helpful in this area. And while we are at it, I would suggest to express V5 fingerprints (as well as key IDs) either in octal or in decimal. This is not a cryptography issue (*), but a usability issue on (typically mobile) devices with numeric-only keypads. As an added benefit, it would make the keyID ~ telephone number metaphor more sustainable. For such a decision, OpenPGP could earn the ethernal gratitude of the entire telecom industry. --=20 Daniel (*) But it certainly IS a security issue: usability is a crucial part of security, because security measures that are not usable are not going to be used. --vtzGhvizbBRQ85DL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iQDVAwUBR9mWgNlNfsjr6fBFAQI3TAX/fZTrQcX1WmS0TAE1+jYijJ/RyE5dplvd 6CbrkPm2HGX13JZw4xl2bEs0bsZtG84wb03LVBHWqGboJtABa+JfgqxBrZjEfyF1 jYaj+jH6fKQnMZvsx9u5rx9WDHKalrJ9Y/2I14jIgH8m7WAxpdJuCqb1M6vc9N12 rucrN5UBRqLTOo7TBYCvc+tUEihC2qljAsXM9p5RdRntC9eHO01HxXnsWYEIy+jn q10SBKET6yW4HV7OhA7XZe/j/KQwNiIT =CspB -----END PGP SIGNATURE----- --vtzGhvizbBRQ85DL-- From owner-ietf-openpgp@mail.imc.org Fri Mar 14 07:39:18 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D67733A6E19 for ; Fri, 14 Mar 2008 07:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjEiOFZL9rRH for ; Fri, 14 Mar 2008 07:39:18 -0700 (PDT) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 9B7FC3A6EE6 for ; Fri, 14 Mar 2008 07:39:17 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EE4Mus093601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Mar 2008 07:04:22 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2EE4MfF093600; Fri, 14 Mar 2008 07:04:22 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from skaro.afraid.org (skaro.afraid.org [212.169.1.61]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EE4LWL093593 for ; Fri, 14 Mar 2008 07:04:22 -0700 (MST) (envelope-from iang@systemics.com) Received: from zhukov.local (localhost.cthulhu.dircon.co.uk [127.0.0.1]) by skaro.afraid.org (Postfix) with ESMTP id 94D1D5D23 for ; Fri, 14 Mar 2008 14:04:13 +0000 (GMT/BST) Message-ID: <47DA85DD.8000500@systemics.com> Date: Fri, 14 Mar 2008 15:04:13 +0100 From: Ian G User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Ready for Camellia? References: <20080311180200.GC4826@jabberwocky.com> <20080313152341.GB1587@jabberwocky.com> In-Reply-To: <20080313152341.GB1587@jabberwocky.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Shaw wrote: > On Wed, Mar 12, 2008 at 01:29:49PM -0400, Derek Atkins wrote: >> David Shaw writes: >> >> [snip] >>> I think that is just fine, and thanks for working this out. >>> >>> I have a minor process question though: I've done a couple of Camellia >>> drafts as "draft-ietf-openpgp-camellia". Do I need to convert that to >>> "draft-shaw-openpgp-camellia" (i.e. an individual submission) and >>> re-submit? >> No, it can stay as 'draft-ietf-openpgp-'. No need to rename and >> resubmit as an individual. > > Great, thanks. > > I think we're ready for the final push on Camellia. All of the > suggested changes have been incorporated, and if folks could give it a > final read, I'd appreciate it: > http://www.ietf.org/internet-drafts/draft-ietf-openpgp-camellia-01.txt I just skimmed it. I am confused about one language difference between Camellia doc and ECC doc. In Camellia, there are MAYs. In ECC, there are MUSTs, SHOULDs, MAYs. The way I interpret it, Camellia is *incorporated within* RFC4880 and adds MAY algorithms. But ECC is *appended as a MAY* ... the entire appendix is a MAY, within which there are choices guided by RFC2119. Maybe I'm wrong about my interpretation, and if so, stop reading here. It would be nice if we could agree on a more unified way of treating this. Personally I prefer the ECC style, as it allows for some richness within. However, there should be a line at the top of the document describing the relationship to the mother document. Something like: This document is an optional appendix to [RFC4880] which makes the entire Camellia addition a MAY. If you do add Camellia then you must follow the recommendations below using the normal language of [RFC2119]. OK, that's really crappy language but I hope you get the idea. > I would particulary appreciate comments on the choice of 128 and > 256-bit keys (that is, lacking 192). I tend to agree with Jon that > 192 is neither here nor there, but I'm also a major fan of > consistency. If we're going to include 192 for the ECC work, then > it's odd to leave it out here. I agree with dropping 192. I see no consistency argument here, the notion of having consistent sets across algorithms seems esthetic only. Real users won't understand these notions of esthetics. The sensible reason for including 192 in ECC was outlined by Jon. There are checkboxes that big corps and big TLAs follow when buying this stuff. They do not understand what they are doing, they simply tick boxes (by definition, as if they knew what they were doing, they wouldn't have boxes to tick). In that world, you need to have the checkboxes. However, no case has been made that Camellia is in that world. Camellia is not on Suite B, it isn't going to win any USG sales. So it doesn't need the checkbox, and we can revert back to our own judgement. The rough consensus in this group today (that I see) is that we are aiming at two markets at once, being the "small/mobile" and the "big/secure" sectors. Which means the biggest and the smallest: 128 + 256. iang PS: That rough consensus is what *I* see here today. Others might view it differently! From owner-ietf-openpgp@mail.imc.org Fri Mar 14 07:46:35 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA9BC28C244 for ; Fri, 14 Mar 2008 07:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktW8g-1FgCNJ for ; Fri, 14 Mar 2008 07:46:34 -0700 (PDT) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 855133A6CAA for ; Fri, 14 Mar 2008 07:46:34 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EEFShd095022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Mar 2008 07:15:29 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2EEFSEi095021; Fri, 14 Mar 2008 07:15:28 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from skaro.afraid.org (skaro.afraid.org [212.169.1.61]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EEFRL2095010 for ; Fri, 14 Mar 2008 07:15:28 -0700 (MST) (envelope-from iang@systemics.com) Received: from zhukov.local (localhost.cthulhu.dircon.co.uk [127.0.0.1]) by skaro.afraid.org (Postfix) with ESMTP id E76225D23; Fri, 14 Mar 2008 14:15:24 +0000 (GMT/BST) Message-ID: <47DA887C.9080505@systemics.com> Date: Fri, 14 Mar 2008 15:15:24 +0100 From: Ian G User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: "Daniel A. Nagy" Cc: ietf-openpgp@imc.org Subject: Re: Closing the openpgp working group References: <47D53515.5050201@systemics.com> <117bad160803101012m52d22fdnd9aba86fc0ea33b1@mail.gmail.com> <87r6eebcav.fsf@mid.deneb.enyo.de> <20080313210256.GC18071@epointsystem.org> In-Reply-To: <20080313210256.GC18071@epointsystem.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel A. Nagy wrote: > On Thu, Mar 13, 2008 at 09:26:32PM +0100, Florian Weimer wrote: >> * David Crick: >> >>>> How much enthusiasm is there for this? Enough to generate >>>> some consensus? Is there a business case for a redesign? >>> "doesn't use SHA1" sounds like a good V5 business case.... >> Yes, some of us do check-list based security, and not having to rely on >> SHA-1 is helpful in this area. > > And while we are at it, I would suggest to express V5 fingerprints (as well > as key IDs) either in octal or in decimal. This is not a cryptography issue > (*), but a usability issue on (typically mobile) devices with numeric-only > keypads. As an added benefit, it would make the keyID ~ telephone number > metaphor more sustainable. > > For such a decision, OpenPGP could earn the ethernal gratitude of the entire > telecom industry. I cautiously agree with this. The old idea of hex and base64 was about saving bits and aligning with the soul of the computer. Those ideas are anachronisms with modern capacities, and with modern users. (Also, in both SSH and PGP, we have seen difficulties with key identification ... with different varieties of expression being incompatible. This failure has slowed down and probably killed the ability to check public keys easily, a major tenet of opportunistic cryptography.) So it would be nice to create one unified way. Something like, all key Ids are expressed as parts of ordinary base-10 numbers of the formal SHA-512 hash of the key. The key Id is always read from the left side of the full hash. If you want more discrimination you read off more digits. The size of the number tells you the discrimination. ("something like" being a thought experiment, not a serious suggestion to start coding ;) iang From owner-ietf-openpgp@mail.imc.org Fri Mar 14 08:45:00 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E20993A6F4B for ; Fri, 14 Mar 2008 08:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3pM3lb+t7cY for ; Fri, 14 Mar 2008 08:45:00 -0700 (PDT) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 9AED13A6F01 for ; Fri, 14 Mar 2008 08:44:59 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EFGJgq001204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Mar 2008 08:16:19 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2EFGJZc001203; Fri, 14 Mar 2008 08:16:19 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EFGH6a001197 for ; Fri, 14 Mar 2008 08:16:18 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.jabberwocky.com (c-75-69-177-157.hsd1.ma.comcast.net [75.69.177.157]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id m2EFGGN26778 for ; Fri, 14 Mar 2008 10:16:16 -0500 Received: from jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.1/8.14.1) with SMTP id m2EFGBVR006487 for ; Fri, 14 Mar 2008 11:16:11 -0400 Date: Fri, 14 Mar 2008 11:16:11 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Ready for Camellia? Message-ID: <20080314151611.GA651@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20080311180200.GC4826@jabberwocky.com> <20080313152341.GB1587@jabberwocky.com> <47DA85DD.8000500@systemics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47DA85DD.8000500@systemics.com> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.17 (2007-11-01) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Mar 14, 2008 at 03:04:13PM +0100, Ian G wrote: >> I think we're ready for the final push on Camellia. All of the >> suggested changes have been incorporated, and if folks could give it a >> final read, I'd appreciate it: >> http://www.ietf.org/internet-drafts/draft-ietf-openpgp-camellia-01.txt > I am confused about one language difference between Camellia doc and ECC > doc. In Camellia, there are MAYs. In ECC, there are MUSTs, SHOULDs, MAYs. > > The way I interpret it, Camellia is *incorporated within* RFC4880 and adds > MAY algorithms. But ECC is *appended as a MAY* ... the entire appendix is > a MAY, within which there are choices guided by RFC2119. > > Maybe I'm wrong about my interpretation, and if so, stop reading here. I disagree with that interpretation. There is nothing special about Camellia here. Both Camellia and ECC are the same: new RFCs that specify new functionality. Whatever they may specify, they can only specify that in regards to themselves. > This document is an optional appendix to [RFC4880] which > makes the entire Camellia addition a MAY. If you do add > Camellia then you must follow the recommendations below > using the normal language of [RFC2119]. > > OK, that's really crappy language but I hope you get the idea. The draft more or less says that: OpenPGP applications MAY implement Camellia. If implemented, Camellia may be used in any place in OpenPGP where a symmetric cipher is usable, and is subject to the same usage requirements (such as its presence in the Preferred Symmetric Algorithms signature subpacket) as the other symmetric ciphers in OpenPGP. Note that the whole draft has only one "MAY" (and no MUSTs, SHOULDs, etc) with regards to Camellia. That is appropriate for a simple algorithm RFC. It's "you MAY implement this, but doing so doesn't get you out of the various MUSTs and other rules from 4880." > I agree with dropping 192. I see no consistency argument here, the notion > of having consistent sets across algorithms seems esthetic only. Real > users won't understand these notions of esthetics. I just thought of another reason to leave Camellia-192 out: if we leave it out and then change our minds, it's pretty easy to add it later (just write a tiny RFC and get an algorithm number for it). If we do put it in now and then change our minds, it's nearly impossible to get rid of it later. David From owner-ietf-openpgp@mail.imc.org Fri Mar 14 09:09:28 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A3F528C5C7 for ; Fri, 14 Mar 2008 09:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPsdAXxMCkdh for ; Fri, 14 Mar 2008 09:09:22 -0700 (PDT) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 598043A68CA for ; Fri, 14 Mar 2008 09:09:21 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EFfDd0003241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Mar 2008 08:41:13 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2EFfDB7003240; Fri, 14 Mar 2008 08:41:13 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EFfBQ7003233 for ; Fri, 14 Mar 2008 08:41:12 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.jabberwocky.com (c-75-69-177-157.hsd1.ma.comcast.net [75.69.177.157]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id m2EFfBN26995 for ; Fri, 14 Mar 2008 10:41:11 -0500 Received: from jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.1/8.14.1) with SMTP id m2EFf6Gd006619 for ; Fri, 14 Mar 2008 11:41:06 -0400 Date: Fri, 14 Mar 2008 11:41:05 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Non-hex key IDs (was: Closing the openpgp working group) Message-ID: <20080314154105.GB651@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <47D53515.5050201@systemics.com> <117bad160803101012m52d22fdnd9aba86fc0ea33b1@mail.gmail.com> <87r6eebcav.fsf@mid.deneb.enyo.de> <20080313210256.GC18071@epointsystem.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080313210256.GC18071@epointsystem.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.17 (2007-11-01) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 13, 2008 at 10:02:56PM +0100, Daniel A. Nagy wrote: > And while we are at it, I would suggest to express V5 fingerprints (as well > as key IDs) either in octal or in decimal. This is not a cryptography issue > (*), but a usability issue on (typically mobile) devices with numeric-only > keypads. As an added benefit, it would make the keyID ~ telephone number > metaphor more sustainable. > > For such a decision, OpenPGP could earn the ethernal gratitude of the entire > telecom industry. The current hex method is nicely dense: 8 characters gives you 32 bits, which is enough (today, anyway) to find and disambiguate keys in virtually all cases (once the key is found, of course, we have the 64-bit key ID). If you are restricted to the numbers 0-9, those 8 characters only give you a bit more than 26 bits, so there would be a greater chance of collision. You'd need to go to a 10-digit decimal key ID to cover the same space as the 8 character hex ID. 10 characters isn't too bad. It would be interesting to write a test against the keyservers to see how much of an issue this really is. It would also be interesting to see if someone (the phone companies?) has done a study on how many digits people can easily remember. As it happens, my key id is all decimals anyway... David From owner-ietf-openpgp@mail.imc.org Fri Mar 14 12:43:25 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3104C28C1AE for ; Fri, 14 Mar 2008 12:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_ADELPHIA=0.456] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-h5Kl9VlJYB for ; Fri, 14 Mar 2008 12:43:24 -0700 (PDT) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 00F1728C1D5 for ; Fri, 14 Mar 2008 12:43:23 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EJBFTB024664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Mar 2008 12:11:16 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2EJBF3Y024663; Fri, 14 Mar 2008 12:11:15 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EJBDWo024654 for ; Fri, 14 Mar 2008 12:11:15 -0700 (MST) (envelope-from JPClizbe@tx.rr.com) Received: from [127.0.0.1] (really [72.190.107.50]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20080314191112.FTIE8359.mta9.adelphia.net@[127.0.0.1]> for ; Fri, 14 Mar 2008 15:11:12 -0400 Message-ID: <47DACDCF.10103@tx.rr.com> Date: Fri, 14 Mar 2008 14:11:11 -0500 From: John Clizbe Organization: GingerBear Conspiracy Theories To Go User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 SeaMonkey/1.1.8 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Non-hex key IDs References: <47D53515.5050201@systemics.com> <117bad160803101012m52d22fdnd9aba86fc0ea33b1@mail.gmail.com> <87r6eebcav.fsf@mid.deneb.enyo.de> <20080313210256.GC18071@epointsystem.org> <20080314154105.GB651@jabberwocky.com> In-Reply-To: <20080314154105.GB651@jabberwocky.com> X-Enigmail-Version: 0.95.6 OpenPGP: X-Face: &KOqPhy&\S+}^~xEHZGEs'8mps-5a4E=`i>2c!PuesSM7lpv}^Yfn<6?y=BF@X+N!n&!L&# .m>o,xH$v%{I8Gmf/Z'.qB|U;][A5$#c;u%(rJ\S"2NotGhXF@~cM4'Q!/E\9cP{1M;J8A0e>-&xN, hQ>[CjNA{+~zDNk1'jz@|yeaCJX*M1;(Tb_7(.WCK:)}W?d.Nl<8&W{]/T-+gG?\lS) List-Unsubscribe: List-ID: David Shaw wrote: > On Thu, Mar 13, 2008 at 10:02:56PM +0100, Daniel A. Nagy wrote: >> And while we are at it, I would suggest to express V5 fingerprints (as well >> as key IDs) either in octal or in decimal. This is not a cryptography issue >> (*), but a usability issue on (typically mobile) devices with numeric-only >> keypads. As an added benefit, it would make the keyID ~ telephone number >> metaphor more sustainable. >> > It would also be interesting to see if someone (the phone companies?) has done > a study on how many digits people can easily remember. Miller, G. A. (1956). The magical number seven, plus or minus two: Some limits on our capacity for processing information. Psychological Review, 63, 81-97. http://www.musanim.com/miller1956/ 7 +/- 2 There's a Wikipedia discussion of it at http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two From owner-ietf-openpgp@mail.imc.org Fri Mar 14 13:49:17 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE3033A69D8 for ; Fri, 14 Mar 2008 13:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpVep2iBKYyO for ; Fri, 14 Mar 2008 13:49:12 -0700 (PDT) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 098703A67D8 for ; Fri, 14 Mar 2008 13:49:11 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EKHE17030945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Mar 2008 13:17:14 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2EKHEZi030944; Fri, 14 Mar 2008 13:17:14 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EKHDCJ030937 for ; Fri, 14 Mar 2008 13:17:14 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id CE6F1D83E85 for ; Fri, 14 Mar 2008 13:17:12 -0700 (PDT) Received: from titania.pgp.com ([63.251.255.205]) by keys.merrymeet.com (PGP Universal service); Fri, 14 Mar 2008 13:17:12 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 14 Mar 2008 13:17:12 -0700 Cc: ietf-openpgp@imc.org Message-Id: From: Jon Callas To: David Shaw In-Reply-To: <20080314151611.GA651@jabberwocky.com> Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: Ready for Camellia? Date: Fri, 14 Mar 2008 13:17:10 -0700 References: <20080311180200.GC4826@jabberwocky.com> <20080313152341.GB1587@jabberwocky.com> <47DA85DD.8000500@systemics.com> <20080314151611.GA651@jabberwocky.com> X-Mailer: Apple Mail (2.919.2) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > I just thought of another reason to leave Camellia-192 out: if we > leave it out and then change our minds, it's pretty easy to add it > later (just write a tiny RFC and get an algorithm number for it). If > we do put it in now and then change our minds, it's nearly impossible > to get rid of it later. As much as I think that 192-bit encryption is stupid, many people have impressed upon me reasons it exists, none of which are technical. I grit my teeth and hold my nose as I say this, but we have to have it. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFH2t1IsTedWZOD3gYRAhB2AKC/jO2WcnR61Kbi9YGxhQeLngvynwCeJFUi 94ONpVHASVBxT63b185HqoM= =ngZw -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri Mar 14 13:57:51 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 261633A697B for ; Fri, 14 Mar 2008 13:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, SARE_RMML_Stock9=0.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21sb6f1omsdQ for ; Fri, 14 Mar 2008 13:57:50 -0700 (PDT) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id E829328C2D5 for ; Fri, 14 Mar 2008 13:57:40 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EKQ7lW031399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Mar 2008 13:26:07 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2EKQ7EF031398; Fri, 14 Mar 2008 13:26:07 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EKQ4B7031359 for ; Fri, 14 Mar 2008 13:26:07 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id B90BAD83FC8 for ; Fri, 14 Mar 2008 13:26:04 -0700 (PDT) Received: from titania.pgp.com ([63.251.255.205]) by keys.merrymeet.com (PGP Universal service); Fri, 14 Mar 2008 13:26:04 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 14 Mar 2008 13:26:04 -0700 Message-Id: From: Jon Callas To: OpenPGP In-Reply-To: <20080313210256.GC18071@epointsystem.org> Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: Closing the openpgp working group Date: Fri, 14 Mar 2008 13:26:03 -0700 References: <47D53515.5050201@systemics.com> <117bad160803101012m52d22fdnd9aba86fc0ea33b1@mail.gmail.com> <87r6eebcav.fsf@mid.deneb.enyo.de> <20080313210256.GC18071@epointsystem.org> X-Mailer: Apple Mail (2.919.2) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > And while we are at it, I would suggest to express V5 fingerprints > (as well > as key IDs) either in octal or in decimal. This is not a > cryptography issue > (*), but a usability issue on (typically mobile) devices with > numeric-only > keypads. As an added benefit, it would make the keyID ~ telephone > number > metaphor more sustainable. > > For such a decision, OpenPGP could earn the ethernal gratitude of > the entire > telecom industry. I think we should not tie non SHA-1 fingerprints to V5 key ids. I like the proposal someone had at one point that you have a syntax that includes the hash number. Thus, a present fingerprint would become: 2:012356789ABCDEF... A SHA-256 version would be: 8:FEDCBA987654..... Within this, if you want a shorter version of the fingerprint, you simply truncate the right-most portion (which "fixes" the present mechanism). Once you have this mechanism, a way to do a fingerprint in decimal or octal is pretty easy. It's also easy for telephones to map the ':' to a '*' (e.g.). I leave the exact signal for a different radix as an exercise for someone to suggest. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFH2t9csTedWZOD3gYRAh/RAJ9nrAV4gIWAGII7gXBhyrxBj+PaKgCg2pCe 5f7X5YRUDDdgg+vmlDw+siU= =r0IL -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Mon Mar 17 02:56:28 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A2E93A677E for ; Mon, 17 Mar 2008 02:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, URIBL_GREY=0.25] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHsddHvcQPfW for ; Mon, 17 Mar 2008 02:56:24 -0700 (PDT) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 367213A6CF6 for ; Mon, 17 Mar 2008 02:56:02 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2H9V57k055607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 02:31:05 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2H9V5Fk055606; Mon, 17 Mar 2008 02:31:05 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2H9V3ok055600 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 17 Mar 2008 02:31:05 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from localhost.localdomain (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by mail.cyberonic.com (8.12.8/8.12.8) with ESMTP id m2HA0VEG006061; Mon, 17 Mar 2008 05:00:32 -0500 Message-ID: <47DE3A52.2090508@brainhub.org> Date: Mon, 17 Mar 2008 02:30:58 -0700 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: David Crick Subject: Re: ECC in OpenPGP proposal, second revision References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <47CC7750.7080206@brainhub.org> <117bad160803031449p1efb03bao654561db48a5dbb2@mail.gmail.com> <47CD0451.9000503@brainhub.org> <117bad160803040655x3f393c7cuda72f361fbd119a4@mail.gmail.com> <47CE1648.6050402@brainhub.org> <117bad160803050356h54c755a4m2ada0ec7b53e8b0e@mail.gmail.com> <47D5A517.1010409@brainhub.org> <117bad160803110543vf22ecd1y8fdb3ac0409912e7@mail.gmail.com> In-Reply-To: <117bad160803110543vf22ecd1y8fdb3ac0409912e7@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Crick wrote: > 11.1 I would like to see "MAY implement curve ID 2" explicitly stated > (this *is* mentioned in section 12, but would like to see it here too) > > > 11.3 says "The best remedy to this .. is to add .. AES-256" > > not sure about "best" - perhaps "simplest"? The reason being is > that as AES128 is an ECC must, then this guarantees us *a* Suite > B acceptable cipher, although - as you're trying to get at - having > AES256 means that we'd cover *both* Suite B profiles. > Corrected. > I'm not sure if I agree with the sentiment of "adding .. to .. each > recipient's key" - doesn't quite sound right? (Maybe because it > sounds like sender coercion, rather than a higher-level admin > led policy?) With the mentioned correction this is one of possible alternatives. It is one of cleanest fixes in the sense of standard correctness. I realize that it is not a practical fix for the incompatibility. I can't fix the keys at at the moment I am sending a message. That's why we should mention the importance of proper key preferences in reference to relative security. > > > 12 "It is generally advisable to list at the head of the preference list > a symmetric algorithm of strength corresponding to the public key." I watered down this statement to leave that at least the algorithm should be there. > > Again, I see what you're trying to say, but as is noted elsewhere in > the ECC doc, it's merely the intersection - it's up to the implementation > to make its own decision thereafter (and so take advantage of any > ordering information). As a side note, per RFC4880 this "is an ordered list of octets with the most preferred listed firs". If each recipient has the same set of symmetric algorithms, shouldn't the intersection remain ordered? I think "merely an intersection" is not strictly correct, although I can agree with "in practice" or "in most cases" clarification. > > I think section 12 also needs to explicitly deprecate AES-192, saying > that it's not necessarily going to be fielded widely (bring in the fact > that it is only a MAY here might help), isn't one of the Suite B ciphers, > and that it's probably only suitable if for some reason you *really* > need a 192-bit cipher: otherwise go for AES256 for security or -128 > for performance. I hope that we find a consensus in not explicitly promoting AES-192 instead. There are many reasons why mobile/weak hardware devices may wish the middle-of-the-road approach with AES-192/ECC-384. The evidence regarding performance shortcoming of AES-192 is not overwhelming. On http://www.cryptopp.com/benchmarks.html AES/ECB 192 appears even faster than 128 in key setup (a measurement aberration, perhaps). The data encoding speed is decreasing smoothly for 128/192/256 keys with a factor ~1.13. So is data encoding performance in http://www.linux.com/feature/114024 for AES 128/192/256 with CBC for both 16 bytes and 8192 bytes. The throughput is reduced by a factor ~1.15 as we go to stronger AES. GnuPG shows gradual slowdown for AES 128/192/256 http://www.nchelp.org/committees/cl-elec-exch/msg00734.html. The factor is ~1.03. If we were to discourage AES-192, we will need convincing references to data that support and explain our choice. > > > overall, though, I think we're getting there. > ... The latest version is: http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-8.txt The same version in other formats: http://brainhub.googlepages.com/pgp From owner-ietf-openpgp@mail.imc.org Mon Mar 17 06:49:10 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 374163A6BD9 for ; Mon, 17 Mar 2008 06:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dPg6-GZGQHL for ; Mon, 17 Mar 2008 06:49:08 -0700 (PDT) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 693F33A6D4A for ; Mon, 17 Mar 2008 06:49:08 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HDAxJA084191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 06:10:59 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2HDAxiL084190; Mon, 17 Mar 2008 06:10:59 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.186]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HDAwcN084181 for ; Mon, 17 Mar 2008 06:10:59 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by gv-out-0910.google.com with SMTP id l14so851571gvf.13 for ; Mon, 17 Mar 2008 06:10:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=fI2B4hAtPrB9lysJdx5dJfm8g3hGxMxJaSagRMs6Vmw=; b=iP5kS7Os+Z7QlyCEDdWI7JvR+pvXIni53RzpqRARzb24ZMO3a6A9/XjrUrgKSBEoFzjb0FRpeE8N76/RglG/iKVwxF0vrsXQuP/0xQhW+gCOjHwIIe++eYH6B5NDuxxEUDno+fFwISgCIxNmUf2qE7/zucoOfjKWxvNxUHE0wMI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=i2c1ERHFAKhz30nk1NnTO2m5pFNzgpq0rR1ssIIDRA7cCACNyhvOiDIUiMgGbqdrPrcYQ9HcxpJ7JIQzryRyxEoEVEzKVfyHgEk3+1qfbvxQVVqe4PaKNU5uwJilo822Oe383mAkw9ojQpz9qEFjVC6BrQCmLrjMqyrRIvBu+5U= Received: by 10.142.158.17 with SMTP id g17mr39936wfe.127.1205759455298; Mon, 17 Mar 2008 06:10:55 -0700 (PDT) Received: by 10.143.188.1 with HTTP; Mon, 17 Mar 2008 06:10:55 -0700 (PDT) Message-ID: <117bad160803170610p3457d87eke44dc587d0d68a6a@mail.gmail.com> Date: Mon, 17 Mar 2008 13:10:55 +0000 From: "David Crick" To: "Andrey Jivsov" Subject: Re: ECC in OpenPGP proposal, second revision Cc: ietf-openpgp@imc.org In-Reply-To: <47DE3A52.2090508@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47CC7750.7080206@brainhub.org> <117bad160803031449p1efb03bao654561db48a5dbb2@mail.gmail.com> <47CD0451.9000503@brainhub.org> <117bad160803040655x3f393c7cuda72f361fbd119a4@mail.gmail.com> <47CE1648.6050402@brainhub.org> <117bad160803050356h54c755a4m2ada0ec7b53e8b0e@mail.gmail.com> <47D5A517.1010409@brainhub.org> <117bad160803110543vf22ecd1y8fdb3ac0409912e7@mail.gmail.com> <47DE3A52.2090508@brainhub.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Mar 17, 2008 at 9:30 AM, Andrey Jivsov wrote: > David Crick wrote: > > 11.1 I would like to see "MAY implement curve ID 2" explicitly stated > > (this *is* mentioned in section 12, but would like to see it here too) are you not going to add "MAY .. curve 2" into 11.1? both Ian and I have requested this, and I have previously pointed out that for *all* algos (asym, sym, hash) 4880 adds a "MAY implement any other" to the end of each section (where for ours, there IS only one other, so may as well be mentioned specifically, i.e. MAY curve 2) > > 11.3 says "The best remedy to this .. is to add .. AES-256" > > > > not sure about "best" - perhaps "simplest"? The reason being is > > that as AES128 is an ECC must, then this guarantees us *a* Suite > > B acceptable cipher, although - as you're trying to get at - having > > AES256 means that we'd cover *both* Suite B profiles. > > > > Corrected. great, this is now better. > > 12 "It is generally advisable to list at the head of the preference list > > a symmetric algorithm of strength corresponding to the public key." > > I watered down this statement to leave that at least the algorithm > should be there. I *preferred* the original version ("at the head")! .... > > Again, I see what you're trying to say, but as is noted elsewhere in > > the ECC doc, it's merely the intersection - it's up to the implementation > > to make its own decision thereafter (and so take advantage of any > > ordering information). > > As a side note, per RFC4880 this "is an ordered list of octets with the > most preferred listed firs". If each recipient has the same set of > symmetric algorithms, shouldn't the intersection remain ordered? I think > "merely an intersection" is not strictly correct, although I can agree > with "in practice" or "in most cases" clarification. ... I was referring to THIS bit in 4880 (13.2): "The implementation may use any mechanism to pick an algorithm in the intersection." Thus, while the section you quote (5.2.3.7) is *also* correct, what 13.2 is saying is "well, there's information you COULD use, but it's really up to you [the implementation] to pick an algorithm." Therefore, I was *happy* with your original wording (and would prefer to see it re-instatad!), but was just pointing out that it was only part of the (i.e. [4880] rfc) story. > > I think section 12 also needs to explicitly deprecate AES-192, saying > > that it's not necessarily going to be fielded widely (bring in the fact > > that it is only a MAY here might help), isn't one of the Suite B ciphers, > > and that it's probably only suitable if for some reason you *really* > > need a 192-bit cipher: otherwise go for AES256 for security or -128 > > for performance. > > I hope that we find a consensus in not explicitly promoting AES-192 > instead. There are many reasons why mobile/weak hardware devices may > wish the middle-of-the-road approach with AES-192/ECC-384. For SSL it was decided to just go with AES128 and AES256: "The AES supports key lengths of 128, 192 and 256 bits. However, this document only defines ciphersuites for 128- and 256-bit keys. *This is to avoid unnecessary proliferation of ciphersuites.*" (rfc3268) (Similarly, with Camellia added to SSL again only the 128 and 256 length keys were added (rfc4132), again mentioning that just the 128+256 are being done, despite 192 exisiting.) With Suite B, NSA have chosen to also just go with 128 and 256, despite the other elements of the larger algo set being 192-equivelent in size. From their footnote 1: "CNSSP-15 correctly states that 192-bit AES keys are sufficient for protecting even TOPSECRET information. However, Suite B uses only 256-bit keys *to enhance interoperability*." Our MUST is AES-128, our SHOULD is AES-256. I think we should be following the trend in promoting just 128 and 256 bit ciphers, and by deprecating AES-192 - which we NEED to do with the stronger Suite B set (perhaps possible the "only" reason to implement Curve 2, give our MUST on C1 and SHOULD on C3). From owner-ietf-openpgp@mail.imc.org Mon Mar 17 08:43:34 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 983C23A6CC9 for ; Mon, 17 Mar 2008 08:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POF4udlnY3+Y for ; Mon, 17 Mar 2008 08:43:33 -0700 (PDT) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 7B0FE3A6BAA for ; Mon, 17 Mar 2008 08:43:33 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HFKd1Q099539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 08:20:39 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2HFKdxF099538; Mon, 17 Mar 2008 08:20:39 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from skaro.afraid.org (skaro.afraid.org [212.169.1.61]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HFKVbY099528 for ; Mon, 17 Mar 2008 08:20:38 -0700 (MST) (envelope-from iang@systemics.com) Received: from zhukov.local (localhost.cthulhu.dircon.co.uk [127.0.0.1]) by skaro.afraid.org (Postfix) with ESMTP id 29B9C5D23; Mon, 17 Mar 2008 15:20:10 +0000 (GMT/BST) Message-ID: <47DE8C23.1030600@systemics.com> Date: Mon, 17 Mar 2008 16:20:03 +0100 From: Ian G User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Andrey Jivsov Cc: ietf-openpgp@imc.org, David Crick Subject: Re: ECC in OpenPGP proposal, second revision References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <47CC7750.7080206@brainhub.org> <117bad160803031449p1efb03bao654561db48a5dbb2@mail.gmail.com> <47CD0451.9000503@brainhub.org> <117bad160803040655x3f393c7cuda72f361fbd119a4@mail.gmail.com> <47CE1648.6050402@brainhub.org> <117bad160803050356h54c755a4m2ada0ec7b53e8b0e@mail.gmail.com> <47D5A517.1010409@brainhub.org> <117bad160803110543vf22ecd1y8fdb3ac0409912e7@mail.gmail.com> <47DE3A52.2090508@brainhub.org> In-Reply-To: <47DE3A52.2090508@brainhub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Andrey Jivsov wrote: >> I think section 12 also needs to explicitly deprecate AES-192, saying >> that it's not necessarily going to be fielded widely (bring in the fact >> that it is only a MAY here might help), isn't one of the Suite B ciphers, >> and that it's probably only suitable if for some reason you *really* >> need a 192-bit cipher: otherwise go for AES256 for security or -128 >> for performance. > > I hope that we find a consensus in not explicitly promoting AES-192 > instead. There are many reasons why mobile/weak hardware devices may > wish the middle-of-the-road approach with AES-192/ECC-384. I agree with David, I personally have yet to see a valid engineering reason why one would use AES-192. Jon has laid out some non-engineering reasons why it should be there, and that's a difficult area for us to argue against (maybe something Jon and I agree violently over). So I guess we are agreed that it should be possible to do AES-192 ... but that doesn't mean we should encourage it at all. AES-128+friends gives a whole lot of security, and that is probably enough for most if not every mobile application. You want more than 128? Go for the top profile (or go find a machine with the top profile). If your attacker can crunch AES-128+friends then we can't possibly recommend AES-192 because we just don't know what your attacker is up to. I like David's skepticism in words, above. RFC consumers who fancy something "a bit better than 128" should be discouraged, or understand that they are creating problems, they'd better be prepared for the consequences, and the community isn't working for them any more. Deprecated is a good scary word. > If we were to discourage AES-192, we will need convincing references to > data that support and explain our choice. I see no sweet spot in that data, so I read it as supporting the lack of value in AES-192. iang From owner-ietf-openpgp@mail.imc.org Mon Mar 17 12:57:06 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32FC83A6B59 for ; Mon, 17 Mar 2008 12:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8egT737ZKnw0 for ; Mon, 17 Mar 2008 12:57:02 -0700 (PDT) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 0CA093A6E53 for ; Mon, 17 Mar 2008 12:57:01 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HJZXXt026810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 12:35:33 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2HJZXnW026809; Mon, 17 Mar 2008 12:35:33 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HJZUX6026799 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 17 Mar 2008 12:35:32 -0700 (MST) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1JbLFR-0005lD-0a for ; Mon, 17 Mar 2008 20:43:53 +0100 Received: from wk by localhost with local (Exim 4.62 #1 (Debian)) id 1JbL2b-00022P-78 for ; Mon, 17 Mar 2008 20:30:37 +0100 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: Ready for Camellia? References: <20080311180200.GC4826@jabberwocky.com> <20080313152341.GB1587@jabberwocky.com> Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Mon, 17 Mar 2008 20:30:37 +0100 In-Reply-To: <20080313152341.GB1587@jabberwocky.com> (David Shaw's message of "Thu, 13 Mar 2008 11:23:41 -0400") Message-ID: <87iqzl4082.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.110007 (No Gnus v0.7) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 13 Mar 2008 16:23, dshaw@jabberwocky.com said: > I would particulary appreciate comments on the choice of 128 and > 256-bit keys (that is, lacking 192). I tend to agree with Jon that Drop Camellia-192. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From owner-ietf-openpgp@mail.imc.org Mon Mar 17 14:24:18 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A04B53A6ABB for ; Mon, 17 Mar 2008 14:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zglnKePNUaPj for ; Mon, 17 Mar 2008 14:24:17 -0700 (PDT) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 8C7053A69E5 for ; Mon, 17 Mar 2008 14:24:17 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HL41xr034747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 14:04:01 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2HL41pf034746; Mon, 17 Mar 2008 14:04:01 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HL40x5034739 for ; Mon, 17 Mar 2008 14:04:00 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.jabberwocky.com (c-75-69-177-157.hsd1.ma.comcast.net [75.69.177.157]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id m2HL3wP19767 for ; Mon, 17 Mar 2008 16:03:58 -0500 Received: from jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.1/8.14.1) with SMTP id m2HL3rRT028506 for ; Mon, 17 Mar 2008 17:03:54 -0400 Date: Mon, 17 Mar 2008 17:03:53 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Ready for Camellia? Message-ID: <20080317210353.GJ22491@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20080311180200.GC4826@jabberwocky.com> <20080313152341.GB1587@jabberwocky.com> <47DA85DD.8000500@systemics.com> <20080314151611.GA651@jabberwocky.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.17 (2007-11-01) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Mar 14, 2008 at 01:17:10PM -0700, Jon Callas wrote: > > > > > I just thought of another reason to leave Camellia-192 out: if we > > leave it out and then change our minds, it's pretty easy to add it > > later (just write a tiny RFC and get an algorithm number for it). If > > we do put it in now and then change our minds, it's nearly impossible > > to get rid of it later. > > > As much as I think that 192-bit encryption is stupid, many people have > impressed upon me reasons it exists, none of which are technical. > > I grit my teeth and hold my nose as I say this, but we have to have it. Ok, it's a mild ugliness, but it isn't actually harming anything. I'll rev the draft and add it. David From owner-ietf-openpgp@mail.imc.org Mon Mar 17 17:18:16 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C11753A6A64 for ; Mon, 17 Mar 2008 17:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, URIBL_GREY=0.25] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqSP4BzF4nAT for ; Mon, 17 Mar 2008 17:18:15 -0700 (PDT) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 452F43A6803 for ; Mon, 17 Mar 2008 17:18:15 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HNv836050708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 16:57:08 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2HNv8OX050706; Mon, 17 Mar 2008 16:57:08 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HNv40L050699 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 17 Mar 2008 16:57:07 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from localhost.localdomain (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by mail.cyberonic.com (8.12.8/8.12.8) with ESMTP id m2I0QjEG021711; Mon, 17 Mar 2008 19:26:46 -0500 Message-ID: <47DF054C.5090300@brainhub.org> Date: Mon, 17 Mar 2008 16:57:00 -0700 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: David Crick , Ian G Subject: ECC in OpenPGP proposal, forth revision References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47CC7750.7080206@brainhub.org> <117bad160803031449p1efb03bao654561db48a5dbb2@mail.gmail.com> <47CD0451.9000503@brainhub.org> <117bad160803040655x3f393c7cuda72f361fbd119a4@mail.gmail.com> <47CE1648.6050402@brainhub.org> <117bad160803050356h54c755a4m2ada0ec7b53e8b0e@mail.gmail.com> <47D5A517.1010409@brainhub.org> <117bad160803110543vf22ecd1y8fdb3ac0409912e7@mail.gmail.com> <47DE3A52.2090508@brainhub.org> <117bad160803170610p3457d87eke44dc587d0d68a6a@mail.gmail.com> In-Reply-To: <117bad160803170610p3457d87eke44dc587d0d68a6a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Crick wrote: > On Mon, Mar 17, 2008 at 9:30 AM, Andrey Jivsov wrote: >> David Crick wrote: >> > 11.1 I would like to see "MAY implement curve ID 2" explicitly stated >> > (this *is* mentioned in section 12, but would like to see it here too) > > are you not going to add "MAY .. curve 2" into 11.1? > > both Ian and I have requested this, and I have previously > pointed out that for *all* algos (asym, sym, hash) 4880 > adds a "MAY implement any other" to the end of each > section (where for ours, there IS only one other, so may > as well be mentioned specifically, i.e. MAY curve 2) Done. > > ... > >> > 12 "It is generally advisable to list at the head of the preference list >> > a symmetric algorithm of strength corresponding to the public key." >> >> I watered down this statement to leave that at least the algorithm >> should be there. > > I *preferred* the original version ("at the head")! .... Reversed. (Can I be more overzealous in consensus building?). > > >> > Again, I see what you're trying to say, but as is noted elsewhere in >> > the ECC doc, it's merely the intersection - it's up to the implementation >> > to make its own decision thereafter (and so take advantage of any >> > ordering information). >> >> As a side note, per RFC4880 this "is an ordered list of octets with the >> most preferred listed firs". If each recipient has the same set of >> symmetric algorithms, shouldn't the intersection remain ordered? I think >> "merely an intersection" is not strictly correct, although I can agree >> with "in practice" or "in most cases" clarification. > > ... I was referring to THIS bit in 4880 (13.2): > > "The implementation may use any mechanism to pick an > algorithm in the intersection." > > Thus, while the section you quote (5.2.3.7) is *also* correct, > what 13.2 is saying is "well, there's information you COULD > use, but it's really up to you [the implementation] to pick an > algorithm." > > > Therefore, I was *happy* with your original wording (and would > prefer to see it re-instatad!), but was just pointing out that it > was only part of the (i.e. [4880] rfc) story. OK, the above clears this one. > > >> > I think section 12 also needs to explicitly deprecate AES-192, saying >> > that it's not necessarily going to be fielded widely (bring in the fact >> > that it is only a MAY here might help), isn't one of the Suite B ciphers, >> > and that it's probably only suitable if for some reason you *really* >> > need a 192-bit cipher: otherwise go for AES256 for security or -128 >> > for performance. >> >> I hope that we find a consensus in not explicitly promoting AES-192 >> instead. There are many reasons why mobile/weak hardware devices may >> wish the middle-of-the-road approach with AES-192/ECC-384. > > For SSL it was decided to just go with AES128 and AES256: > > "The AES supports key lengths of 128, 192 and 256 bits. > However, this document only defines ciphersuites for 128- > and 256-bit keys. *This is to avoid unnecessary proliferation > of ciphersuites.*" (rfc3268) > > (Similarly, with Camellia added to SSL again only the 128 and > 256 length keys were added (rfc4132), again mentioning > that just the 128+256 are being done, despite 192 exisiting.) > TLS does have a problem of explosion of ciphersuites, something that OpenPGP doesn't. I recall that one of main technical reasons of preferring one Open PGP auth. spec to another in the past was this issue. > With Suite B, NSA have chosen to also just go with 128 and > 256, despite the other elements of the larger algo set being > 192-equivelent in size. From their footnote 1: > > "CNSSP-15 correctly states that 192-bit AES keys are sufficient > for protecting even TOPSECRET information. However, Suite B > uses only 256-bit keys *to enhance interoperability*." > At the same time, NSA employees submit other curves outside of Suite-B: http://www.faqs.org/rfcs/rfc4753.html Plus, a controversial decision to use weaker ECC curve with AES-256... > > Our MUST is AES-128, our SHOULD is AES-256. I think we should > be following the trend in promoting just 128 and 256 bit ciphers, > and by deprecating AES-192 - which we NEED to do with the > stronger Suite B set (perhaps possible the "only" reason to > implement Curve 2, give our MUST on C1 and SHOULD on C3). I essentially added what you've asked regarding AES-192. Not outright, but with a premise that you and Ian are using, which is, if we see the world as divided into "weak" and "strong" systems, "strong" systems SHOULD use AES-256. Thank you. The latest version is: http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-9.txt The same version in other formats: http://brainhub.googlepages.com/pgp From owner-ietf-openpgp@mail.imc.org Tue Mar 18 06:27:16 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DFEA3A6837 for ; Tue, 18 Mar 2008 06:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rThGAjxKZnt2 for ; Tue, 18 Mar 2008 06:27:12 -0700 (PDT) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 41F9528C4BE for ; Tue, 18 Mar 2008 06:27:12 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2ID1UbZ047555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 06:01:30 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2ID1UJt047554; Tue, 18 Mar 2008 06:01:30 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from skaro.afraid.org (skaro.afraid.org [212.169.1.61]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2ID0tKp047473 for ; Tue, 18 Mar 2008 06:00:57 -0700 (MST) (envelope-from iang@systemics.com) Received: from zhukov.local (localhost.cthulhu.dircon.co.uk [127.0.0.1]) by skaro.afraid.org (Postfix) with ESMTP id B525C5D23; Tue, 18 Mar 2008 13:00:43 +0000 (GMT/BST) Message-ID: <47DFBCFA.3090604@systemics.com> Date: Tue, 18 Mar 2008 14:00:42 +0100 From: Ian G User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Jon Callas Cc: David Shaw , ietf-openpgp@imc.org Subject: Re: Ready for Camellia? References: <20080311180200.GC4826@jabberwocky.com> <20080313152341.GB1587@jabberwocky.com> <47DA85DD.8000500@systemics.com> <20080314151611.GA651@jabberwocky.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > >> I just thought of another reason to leave Camellia-192 out: if we >> leave it out and then change our minds, it's pretty easy to add it >> later (just write a tiny RFC and get an algorithm number for it). If >> we do put it in now and then change our minds, it's nearly impossible >> to get rid of it later. > > > As much as I think that 192-bit encryption is stupid, many people have > impressed upon me reasons it exists, none of which are technical. > > I grit my teeth and hold my nose as I say this, but we have to have it. I can understand this for Suite B because there is a defined and controlled market for it, so the non-technical domain does rule. But for Camellia? As far as I can see this is a boutique algorithm that someone is adding for the love of it. Well, ok, so if it is in, how does it go in? Is it possible to put 192-bit encryption in under some sort of "COMPLIANCE-ONLY" label that means that you should only implement this is if you've moved out of the technical domain? E.g., something below MUST, SHOULD, MAY, that suggests there are issues here which are well outside the spec. iang From owner-ietf-openpgp@mail.imc.org Tue Mar 18 06:39:40 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29F233A6EED for ; Tue, 18 Mar 2008 06:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZufKR5f-nYoj for ; Tue, 18 Mar 2008 06:39:32 -0700 (PDT) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 0D41B28C2F2 for ; Tue, 18 Mar 2008 06:39:31 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IDBZii048494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 06:11:35 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IDBZ46048493; Tue, 18 Mar 2008 06:11:35 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IDBYPS048485 for ; Tue, 18 Mar 2008 06:11:35 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.jabberwocky.com (c-75-69-177-157.hsd1.ma.comcast.net [75.69.177.157]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id m2IDBVP24092; Tue, 18 Mar 2008 08:11:31 -0500 Received: from [172.24.84.28] (grover.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.1/8.14.1) with ESMTP id m2IDBQI7001368; Tue, 18 Mar 2008 09:11:26 -0400 Cc: Jon Callas , ietf-openpgp@imc.org Message-Id: <0EFBD07E-1A44-4D8E-8894-C39E09B0C78B@jabberwocky.com> From: David Shaw To: Ian G In-Reply-To: <47DFBCFA.3090604@systemics.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: Ready for Camellia? Date: Tue, 18 Mar 2008 09:11:11 -0400 References: <20080311180200.GC4826@jabberwocky.com> <20080313152341.GB1587@jabberwocky.com> <47DA85DD.8000500@systemics.com> <20080314151611.GA651@jabberwocky.com> <47DFBCFA.3090604@systemics.com> X-Mailer: Apple Mail (2.919.2) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mar 18, 2008, at 9:00 AM, Ian G wrote: > Jon Callas wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >>> I just thought of another reason to leave Camellia-192 out: if we >>> leave it out and then change our minds, it's pretty easy to add it >>> later (just write a tiny RFC and get an algorithm number for it). >>> If >>> we do put it in now and then change our minds, it's nearly >>> impossible >>> to get rid of it later. >> As much as I think that 192-bit encryption is stupid, many people >> have impressed upon me reasons it exists, none of which are >> technical. >> I grit my teeth and hold my nose as I say this, but we have to have >> it. > > > I can understand this for Suite B because there is a defined and > controlled market for it, so the non-technical domain does rule. > > But for Camellia? As far as I can see this is a boutique algorithm > that someone is adding for the love of it. > > Well, ok, so if it is in, how does it go in? > > Is it possible to put 192-bit encryption in under some sort of > "COMPLIANCE-ONLY" label that means that you should only implement > this is if you've moved out of the technical domain? > > E.g., something below MUST, SHOULD, MAY, that suggests there are > issues here which are well outside the spec. That overloads additional semantics into the simple and elegant RFC keyword system. We already have a concept of "You don't have to do this. The spec doesn't require it. If you do choose do to it, however, do it like this." That's MAY. We don't need another way to say the same thing. David From owner-ietf-openpgp@mail.imc.org Tue Mar 18 12:10:22 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E8553A6F09 for ; Tue, 18 Mar 2008 12:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CmoQe1xqras for ; Tue, 18 Mar 2008 12:10:11 -0700 (PDT) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 8ED843A6E6C for ; Tue, 18 Mar 2008 12:10:10 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IIiHio087911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 11:44:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IIiHZM087910; Tue, 18 Mar 2008 11:44:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IIiExg087899 for ; Tue, 18 Mar 2008 11:44:16 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by ug-out-1314.google.com with SMTP id z38so979015ugc.16 for ; Tue, 18 Mar 2008 11:44:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=hdHpUKtb75NWB3Euim+1uDExOntlRJ2HN2HhQhlFHd0=; b=HpfK2nD+Vyji5fXMZPP7d58biI4cXd/S1U5rKFpOkKLdAXzYghWwPk/4uzdqw1sG2QyvN83oKQnwQIdEAkASFtlVMBhUIjADMCt1IiZUwVXxGvhZsfJZ7CEikODFl+vUSRmiqWDeXYWYn+4h9oVbmKEfe9TLJ30IbEPPur9gC2M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ACV0lZFgvQwPJ/vkFAX3Bd7KDxi69YPAw/RxZ3c0zufYV//U7ytIexi1X8MnKjAxkDlqyKLLqWSO9+X08uDb097LcPUyhIZqgkZnuuVIezsYMWXf0mCUavV+0u3nI6tuqlLpDgAT6zcjkut9/owOgdpyH0YZesHN62RKdxVRFW4= Received: by 10.78.81.20 with SMTP id e20mr2814160hub.1.1205865849296; Tue, 18 Mar 2008 11:44:09 -0700 (PDT) Received: by 10.78.46.2 with HTTP; Tue, 18 Mar 2008 11:44:09 -0700 (PDT) Message-ID: <117bad160803181144p6cee7c57tdd3ede8fc3e5a636@mail.gmail.com> Date: Tue, 18 Mar 2008 18:44:09 +0000 From: "David Crick" To: "Andrey Jivsov" Subject: Re: ECC in OpenPGP proposal, forth revision Cc: ietf-openpgp@imc.org, "Ian G" In-Reply-To: <47DF054C.5090300@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47CD0451.9000503@brainhub.org> <117bad160803040655x3f393c7cuda72f361fbd119a4@mail.gmail.com> <47CE1648.6050402@brainhub.org> <117bad160803050356h54c755a4m2ada0ec7b53e8b0e@mail.gmail.com> <47D5A517.1010409@brainhub.org> <117bad160803110543vf22ecd1y8fdb3ac0409912e7@mail.gmail.com> <47DE3A52.2090508@brainhub.org> <117bad160803170610p3457d87eke44dc587d0d68a6a@mail.gmail.com> <47DF054C.5090300@brainhub.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Mar 17, 2008 at 11:57 PM, Andrey Jivsov wrote: > >> David Crick wrote: > > are you not going to add "MAY .. curve 2" into 11.1? > > > > both Ian and I have requested this ... > > Done. thank you. > >> > 12 "It is generally advisable to list at the head of the preference list > >> > a symmetric algorithm of strength corresponding to the public key." > >> > >> I watered down this statement to leave that at least the algorithm > >> should be there. > > > > I *preferred* the original version ("at the head")! .... > > Reversed. again, thanks. > >> > I think section 12 also needs to explicitly deprecate AES-192, > >> > >> I hope that we find a consensus in not explicitly promoting AES-192 > >> instead. > > > > For SSL it was decided to just go with AES128 and AES256: > > > > "The AES supports key lengths of 128, 192 and 256 bits. > > However, this document only defines ciphersuites for 128- > > and 256-bit keys. *This is to avoid unnecessary proliferation > > of ciphersuites.*" (rfc3268) > > > > (Similarly, with Camellia added to SSL again only the 128 and > > 256 length keys were added (rfc4132), again mentioning > > that just the 128+256 are being done, despite 192 exisiting.) > > > > TLS does have a problem of explosion of ciphersuites, something that > OpenPGP doesn't. I beg to differ! We currently have 8 (including patent-encumbered IDEA, and counting each of the AESes separately) ciphers, and look like we will be adding a further three Camellias too. I think that rfc3268's sentiments that I quoted above are highly admiral, and the decision to add only 128- and 256- bit Camellia further, and correctly, continues this policy. > At the same time, NSA employees submit other curves outside of Suite-B: > > http://www.faqs.org/rfcs/rfc4753.html we've *got* three NIST-approved ECC curves for each of the AES size keys, two of which are Suite B / NSA approved. Until there is either a market demand - *or* technical or security considerations - that would warrant looking at those other curves, then they're not even on my radar. > Plus, a controversial decision to use weaker ECC curve with AES-256... You've got this *completely* the wrong way around!! The flow was: 1. NIST blesses AES for sensitive information 2. NSA says AES128 is OK for SECRET, and 192 *and* 256 good enough for TOPSECRET. 3. NSA reveals Suite B, including suitable suites for SECRET and TOPSECRET use, the TOPSECRET cipher being AES256, the other components being the lower of *two valid* possible sets for TOPSECRET. Now, NSA give "interoperability" as their reasoning for excluding AES192; we can only guess what that means. But anyway, what they've done is chose *a* TOPSECRET strength for the public key and hash, and *a* TOPSECRET cipher. And this is for *Their* use, so it's damned well gotta be strong enough. The *fact* is that the cipher is *stronger* - *not* that they've "picked" a weaker hash/public key curve. (And in fact up until now in PGP we've generally had higher strength ciphers compared to public keys (2.6 with 128 IDEA and 2K max, PGP5+ with 4K max and 256-bit AES/Twofish).) So I don't think your argument holds, and if anything actually *supports* AES256 over AES192. But anyway... > I essentially added what you've asked regarding AES-192. Not outright, > but with a premise that you and Ian are using, which is, if we see the > world as divided into "weak" and "strong" systems, "strong" systems > SHOULD use AES-256. I'm not quite happy with the wording - I think it needs to be more "against" - plus, by having a single, clear sentence or two that simply states: "please note, use of AES192 is deprecated. You should only consider using it if you have very specific requirements." would actually cut out a *lot* of our current "advisory verbiage." *But*, having at least got *some* sort of wording into the draft about AES192, I'm *somewhat* "placated" - even if I'd (still) prefer it stated more strongly (*and* simply!). But anyway (again)... > Thank you. And again my thanks to you too - for helping us to bring ECC to PGP. I just want to try and do it in the best way possible! I *still* think that some of the "security recommendations" should be liberally sprinkled directly into each of the specific algorithm sections. This would make each section more readable in its own right, and would enable us to convert section 12 into a more general guidance section, rather than how it is now, with guidance *and* specific recommendations. However, it's your document!, and you've already stated that you feel that it would be better the way you've structured it. I really do think we've pretty much got the technical/application level stuff fairly well hammered out now, and that's it's near to the consensus [conflicting opinions ;) ] that we're aired. So from my point of view I think it's just honing the language and structure of the document that remains - seeing if we can more clearly and concisely put it across. 4880 is a highly readable RFC; I'd like to think we can make the ECC document just as consumable. From owner-ietf-openpgp@mail.imc.org Thu Mar 20 00:18:08 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C5DB28C331 for ; Thu, 20 Mar 2008 00:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.641 X-Spam-Level: X-Spam-Status: No, score=-1.641 tagged_above=-999 required=5 tests=[AWL=-0.708, BAYES_00=-2.599, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bY3OQLLKCPY1 for ; Thu, 20 Mar 2008 00:18:07 -0700 (PDT) Received: from balder-227.proper.com (cl-240.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:ef::2]) by core3.amsl.com (Postfix) with ESMTP id 9837828C264 for ; Thu, 20 Mar 2008 00:18:02 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2K6qA04031086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Mar 2008 23:52:10 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2K6qAPW031085; Wed, 19 Mar 2008 23:52:10 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2K6q8Rg031071 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 19 Mar 2008 23:52:09 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from localhost.localdomain (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by mail.cyberonic.com (8.12.8/8.12.8) with ESMTP id m2K7MWEG009188; Thu, 20 Mar 2008 02:22:33 -0500 Message-ID: <47E20993.6030908@brainhub.org> Date: Wed, 19 Mar 2008 23:52:03 -0700 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: David Crick , Ian G Subject: Re: ECC in OpenPGP proposal, forth revision References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47CD0451.9000503@brainhub.org> <117bad160803040655x3f393c7cuda72f361fbd119a4@mail.gmail.com> <47CE1648.6050402@brainhub.org> <117bad160803050356h54c755a4m2ada0ec7b53e8b0e@mail.gmail.com> <47D5A517.1010409@brainhub.org> <117bad160803110543vf22ecd1y8fdb3ac0409912e7@mail.gmail.com> <47DE3A52.2090508@brainhub.org> <117bad160803170610p3457d87eke44dc587d0d68a6a@mail.gmail.com> <47DF054C.5090300@brainhub.org> <117bad160803181144p6cee7c57tdd3ede8fc3e5a636@mail.gmail.com> In-Reply-To: <117bad160803181144p6cee7c57tdd3ede8fc3e5a636@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Crick wrote: ... > >> >> > I think section 12 also needs to explicitly deprecate AES-192, >> >> >> >> I hope that we find a consensus in not explicitly promoting AES-192 >> >> instead. >> > >> > For SSL it was decided to just go with AES128 and AES256: >> > >> > "The AES supports key lengths of 128, 192 and 256 bits. >> > However, this document only defines ciphersuites for 128- >> > and 256-bit keys. *This is to avoid unnecessary proliferation >> > of ciphersuites.*" (rfc3268) >> > >> > (Similarly, with Camellia added to SSL again only the 128 and >> > 256 length keys were added (rfc4132), again mentioning >> > that just the 128+256 are being done, despite 192 exisiting.) >> > >> >> TLS does have a problem of explosion of ciphersuites, something that >> OpenPGP doesn't. I meant the space exhaustion. 4 dimensions DH/public alg/symm.alg/hash alg got some people worry about depletion of 16K space. There is no comparable problem faced by OpenPGP. > > I beg to differ! > > We currently have 8 (including patent-encumbered IDEA, > and counting each of the AESes separately) ciphers, and > look like we will be adding a further three Camellias too. > > I think that rfc3268's sentiments that I quoted above are > highly admiral, and the decision to add only 128- and 256- > bit Camellia further, and correctly, continues this policy. I never disagreed with benefits of eliminating as many options as we can. This goal is high on my list. The performance of AES-256 is not the bottleneck for most of applications that run on PCs and servers, which are bound by IO or public key crypto in realistic applications. > > At the same time, NSA employees submit other curves outside of Suite-B: >> >> http://www.faqs.org/rfcs/rfc4753.html > > we've *got* three NIST-approved ECC curves for each > of the AES size keys, two of which are Suite B / NSA > approved. > > Until there is either a market demand - *or* technical > or security considerations - that would warrant looking > at those other curves, then they're not even on my > radar. > >> Plus, a controversial decision to use weaker ECC curve with AES-256... > > You've got this *completely* the wrong way around!! > > The flow was: > > 1. NIST blesses AES for sensitive information > 2. NSA says AES128 is OK for SECRET, and 192 *and* > 256 good enough for TOPSECRET. > 3. NSA reveals Suite B, including suitable suites for > SECRET and TOPSECRET use, the TOPSECRET > cipher being AES256, the other components being > the lower of *two valid* possible sets for TOPSECRET. > > Now, NSA give "interoperability" as their reasoning for > excluding AES192; we can only guess what that means. > > But anyway, what they've done is chose *a* TOPSECRET > strength for the public key and hash, and *a* TOPSECRET > cipher. And this is for *Their* use, so it's damned well gotta > be strong enough. > > The *fact* is that the cipher is *stronger* - *not* that > they've "picked" a weaker hash/public key curve. It's a valid view angle. That's probably how AES-192 was "upgraded". So is another one -- ECC-521 is missing from Suite-B that is needed to perfectly match Suite-B symmetric algorithm today. Going forward, it is the public key algorithms that "age" faster than symmetric algorithms as processors get faster and mathematicians smarter. My use of "weaker" was in this forward looking meaning. > > (And in fact up until now in PGP we've generally had higher > strength ciphers compared to public keys (2.6 with 128 IDEA > and 2K max, PGP5+ with 4K max and 256-bit AES/Twofish).) > > So I don't think your argument holds, and if anything > actually *supports* AES256 over AES192. > > But anyway... > > > >> I essentially added what you've asked regarding AES-192. Not outright, >> but with a premise that you and Ian are using, which is, if we see the >> world as divided into "weak" and "strong" systems, "strong" systems >> SHOULD use AES-256. > > I'm not quite happy with the wording - I think it needs to be more > "against" - plus, by having a single, clear sentence or two that > simply states: > > "please note, use of AES192 is deprecated. You should only > consider using it if you have very specific requirements." > > would actually cut out a *lot* of our current "advisory verbiage." > I wish we had mobile/smartcard people voice their opinions, since AES-192 is for them. It is hard to advocate on their behalf, because once you go down the path of less processing power, the diversity of systems increases (use diversity of smartcards as a proof). Nonetheless, for what a generic statement is worth, suppose AES-128 was X dollars (or cents?) cheaper than AES-256 to support in a given device and a vendor chose AES-128 only. If for whatever reason AES-192 or better must now be supported, the vendor's choice is to accept X/2 extra cost for AES-192 or X for AES-256. Will X/2 saving achieved with AES-192 matter for mass-produced devices like smartcards? Probably. The support for AES-192 is not an issue for this vendor, because another side is likely more capable system that implements every AES algorithm. ( I assumed above that crypto throughput scales proportionally for AES 128/192/256, as my previous email indicates, and that the cost per unit is likewise proportional ). > > *But*, having at least got *some* sort of wording into the draft > about AES192, I'm *somewhat* "placated" - even if I'd (still) > prefer it stated more strongly (*and* simply!). That's a great relief, David. I will continue to think about how to make it closer to what everybody has requested. > > But anyway (again)... > > >> Thank you. > > And again my thanks to you too - for helping us to bring ECC > to PGP. I just want to try and do it in the best way possible! I appreciate your comments, as well as anyone else's. That's not the last time I say thank you, of course. > > I *still* think that some of the "security recommendations" > should be liberally sprinkled directly into each of the specific > algorithm sections. This would make each section more > readable in its own right, and would enable us to convert > section 12 into a more general guidance section, rather than > how it is now, with guidance *and* specific recommendations. > > However, it's your document!, and you've already stated that > you feel that it would be better the way you've structured it. > > > I really do think we've pretty much got the technical/application > level stuff fairly well hammered out now, and that's it's near to > the consensus [conflicting opinions ;) ] that we're aired. > > So from my point of view I think it's just honing the language > and structure of the document that remains - seeing if we can > more clearly and concisely put it across. I put more weight on succinctness. This often goes against clarity. I do have preference against redundancy. In any case, I would appreciate suggestions on how to improve readability. > > 4880 is a highly readable RFC; I'd like to think we can make > the ECC document just as consumable. Assuming we agree on technical details/options, is there interest in test vectors? Some methods, such as those used with ECDH, are parameterized uniquely, leaving implementers will no reference to check their code. Test vectors will help mitigate the concern of the multitude of options; this will increase the speed of adoption and reduce bugs. It may delay the progress of the document and put more burden on author(s). Alternatively, test vectors can be posted elsewhere. What does the group think about the value/route in this respect? Thank you. From paans039@planet.nl Wed Mar 26 17:07:08 2008 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B4073A6DCA; Wed, 26 Mar 2008 17:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.535 X-Spam-Level: *** X-Spam-Status: No, score=3.535 tagged_above=-999 required=5 tests=[AWL=-0.357, BAYES_05=-1.11, HTML_MESSAGE=0.001, MILLION_USD=1.528, MIME_QP_LONG_LINE=1.396, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4MMnwsKvuCT; Wed, 26 Mar 2008 17:07:07 -0700 (PDT) Received: from cpsmtpo-eml03.kpnxchange.com (cpsmtpo-eml03.kpnxchange.com [213.75.38.152]) by core3.amsl.com (Postfix) with ESMTP id 66E553A68F8; Wed, 26 Mar 2008 17:06:45 -0700 (PDT) Received: from hpsmtp-eml31.kpnxchange.com ([213.75.38.86]) by cpsmtpo-eml03.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Mar 2008 01:04:22 +0100 Received: from cpbrm-eml06.kpnsp.local ([195.121.247.250]) by hpsmtp-eml31.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Mar 2008 01:03:57 +0100 Received: from hpsmtp-eml32.kpnxchange.com ([10.94.53.250]) by cpbrm-eml06.kpnsp.local with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Mar 2008 01:03:56 +0100 Received: from localhost ([10.94.53.250]) by hpsmtp-eml32.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Mar 2008 01:03:55 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C88F9E.08C37DFC" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: CONTACT MR. BRENT Date: Thu, 27 Mar 2008 01:03:49 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CONTACT MR. BRENT thread-index: AciPngav8eB/r9XOSZm766AHDkmlhg== From: X-OriginalArrivalTime: 27 Mar 2008 00:03:55.0507 (UTC) FILETIME=[0C5CC430:01C88F9E] To: undisclosed-recipients:; This is a multi-part message in MIME format. ------_=_NextPart_001_01C88F9E.08C37DFC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 I have a business proposal of USD$8Million and 50% (USD$4Million) of = this sum is at stake for you, if you indulge in this transaction. For = more details, send me an email through my personal email address = [mr.andersonbrent1@live.com] and please include your full name and phone = number, so that i can contact you immediately. Cheers! Mr. Anderson M. Brent +44 7045708770 ------_=_NextPart_001_01C88F9E.08C37DFC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
=0A=
 
=0A=
 
=0A=
=0A=
=0A=

I have a business = proposal of USD$8Million and 50% (USD$4Million) of this sum is at stake = for you, if you indulge in this transaction. For more details, send me = an email through my personal email address [mr.andersonbrent1@live.com] = and please include your full name and phone number, so that i can = contact you immediately. Cheers!
Mr. Anderson M. Brent
+44 = 7045708770
------_=_NextPart_001_01C88F9E.08C37DFC-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2K6qA04031086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Mar 2008 23:52:10 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2K6qAPW031085; Wed, 19 Mar 2008 23:52:10 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2K6q8Rg031071 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 19 Mar 2008 23:52:09 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from localhost.localdomain (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by mail.cyberonic.com (8.12.8/8.12.8) with ESMTP id m2K7MWEG009188; Thu, 20 Mar 2008 02:22:33 -0500 Message-ID: <47E20993.6030908@brainhub.org> Date: Wed, 19 Mar 2008 23:52:03 -0700 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: David Crick , Ian G Subject: Re: ECC in OpenPGP proposal, forth revision References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47CD0451.9000503@brainhub.org> <117bad160803040655x3f393c7cuda72f361fbd119a4@mail.gmail.com> <47CE1648.6050402@brainhub.org> <117bad160803050356h54c755a4m2ada0ec7b53e8b0e@mail.gmail.com> <47D5A517.1010409@brainhub.org> <117bad160803110543vf22ecd1y8fdb3ac0409912e7@mail.gmail.com> <47DE3A52.2090508@brainhub.org> <117bad160803170610p3457d87eke44dc587d0d68a6a@mail.gmail.com> <47DF054C.5090300@brainhub.org> <117bad160803181144p6cee7c57tdd3ede8fc3e5a636@mail.gmail.com> In-Reply-To: <117bad160803181144p6cee7c57tdd3ede8fc3e5a636@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Crick wrote: ... > >> >> > I think section 12 also needs to explicitly deprecate AES-192, >> >> >> >> I hope that we find a consensus in not explicitly promoting AES-192 >> >> instead. >> > >> > For SSL it was decided to just go with AES128 and AES256: >> > >> > "The AES supports key lengths of 128, 192 and 256 bits. >> > However, this document only defines ciphersuites for 128- >> > and 256-bit keys. *This is to avoid unnecessary proliferation >> > of ciphersuites.*" (rfc3268) >> > >> > (Similarly, with Camellia added to SSL again only the 128 and >> > 256 length keys were added (rfc4132), again mentioning >> > that just the 128+256 are being done, despite 192 exisiting.) >> > >> >> TLS does have a problem of explosion of ciphersuites, something that >> OpenPGP doesn't. I meant the space exhaustion. 4 dimensions DH/public alg/symm.alg/hash alg got some people worry about depletion of 16K space. There is no comparable problem faced by OpenPGP. > > I beg to differ! > > We currently have 8 (including patent-encumbered IDEA, > and counting each of the AESes separately) ciphers, and > look like we will be adding a further three Camellias too. > > I think that rfc3268's sentiments that I quoted above are > highly admiral, and the decision to add only 128- and 256- > bit Camellia further, and correctly, continues this policy. I never disagreed with benefits of eliminating as many options as we can. This goal is high on my list. The performance of AES-256 is not the bottleneck for most of applications that run on PCs and servers, which are bound by IO or public key crypto in realistic applications. > > At the same time, NSA employees submit other curves outside of Suite-B: >> >> http://www.faqs.org/rfcs/rfc4753.html > > we've *got* three NIST-approved ECC curves for each > of the AES size keys, two of which are Suite B / NSA > approved. > > Until there is either a market demand - *or* technical > or security considerations - that would warrant looking > at those other curves, then they're not even on my > radar. > >> Plus, a controversial decision to use weaker ECC curve with AES-256... > > You've got this *completely* the wrong way around!! > > The flow was: > > 1. NIST blesses AES for sensitive information > 2. NSA says AES128 is OK for SECRET, and 192 *and* > 256 good enough for TOPSECRET. > 3. NSA reveals Suite B, including suitable suites for > SECRET and TOPSECRET use, the TOPSECRET > cipher being AES256, the other components being > the lower of *two valid* possible sets for TOPSECRET. > > Now, NSA give "interoperability" as their reasoning for > excluding AES192; we can only guess what that means. > > But anyway, what they've done is chose *a* TOPSECRET > strength for the public key and hash, and *a* TOPSECRET > cipher. And this is for *Their* use, so it's damned well gotta > be strong enough. > > The *fact* is that the cipher is *stronger* - *not* that > they've "picked" a weaker hash/public key curve. It's a valid view angle. That's probably how AES-192 was "upgraded". So is another one -- ECC-521 is missing from Suite-B that is needed to perfectly match Suite-B symmetric algorithm today. Going forward, it is the public key algorithms that "age" faster than symmetric algorithms as processors get faster and mathematicians smarter. My use of "weaker" was in this forward looking meaning. > > (And in fact up until now in PGP we've generally had higher > strength ciphers compared to public keys (2.6 with 128 IDEA > and 2K max, PGP5+ with 4K max and 256-bit AES/Twofish).) > > So I don't think your argument holds, and if anything > actually *supports* AES256 over AES192. > > But anyway... > > > >> I essentially added what you've asked regarding AES-192. Not outright, >> but with a premise that you and Ian are using, which is, if we see the >> world as divided into "weak" and "strong" systems, "strong" systems >> SHOULD use AES-256. > > I'm not quite happy with the wording - I think it needs to be more > "against" - plus, by having a single, clear sentence or two that > simply states: > > "please note, use of AES192 is deprecated. You should only > consider using it if you have very specific requirements." > > would actually cut out a *lot* of our current "advisory verbiage." > I wish we had mobile/smartcard people voice their opinions, since AES-192 is for them. It is hard to advocate on their behalf, because once you go down the path of less processing power, the diversity of systems increases (use diversity of smartcards as a proof). Nonetheless, for what a generic statement is worth, suppose AES-128 was X dollars (or cents?) cheaper than AES-256 to support in a given device and a vendor chose AES-128 only. If for whatever reason AES-192 or better must now be supported, the vendor's choice is to accept X/2 extra cost for AES-192 or X for AES-256. Will X/2 saving achieved with AES-192 matter for mass-produced devices like smartcards? Probably. The support for AES-192 is not an issue for this vendor, because another side is likely more capable system that implements every AES algorithm. ( I assumed above that crypto throughput scales proportionally for AES 128/192/256, as my previous email indicates, and that the cost per unit is likewise proportional ). > > *But*, having at least got *some* sort of wording into the draft > about AES192, I'm *somewhat* "placated" - even if I'd (still) > prefer it stated more strongly (*and* simply!). That's a great relief, David. I will continue to think about how to make it closer to what everybody has requested. > > But anyway (again)... > > >> Thank you. > > And again my thanks to you too - for helping us to bring ECC > to PGP. I just want to try and do it in the best way possible! I appreciate your comments, as well as anyone else's. That's not the last time I say thank you, of course. > > I *still* think that some of the "security recommendations" > should be liberally sprinkled directly into each of the specific > algorithm sections. This would make each section more > readable in its own right, and would enable us to convert > section 12 into a more general guidance section, rather than > how it is now, with guidance *and* specific recommendations. > > However, it's your document!, and you've already stated that > you feel that it would be better the way you've structured it. > > > I really do think we've pretty much got the technical/application > level stuff fairly well hammered out now, and that's it's near to > the consensus [conflicting opinions ;) ] that we're aired. > > So from my point of view I think it's just honing the language > and structure of the document that remains - seeing if we can > more clearly and concisely put it across. I put more weight on succinctness. This often goes against clarity. I do have preference against redundancy. In any case, I would appreciate suggestions on how to improve readability. > > 4880 is a highly readable RFC; I'd like to think we can make > the ECC document just as consumable. Assuming we agree on technical details/options, is there interest in test vectors? Some methods, such as those used with ECDH, are parameterized uniquely, leaving implementers will no reference to check their code. Test vectors will help mitigate the concern of the multitude of options; this will increase the speed of adoption and reduce bugs. It may delay the progress of the document and put more burden on author(s). Alternatively, test vectors can be posted elsewhere. What does the group think about the value/route in this respect? Thank you. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IIiHio087911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 11:44:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IIiHZM087910; Tue, 18 Mar 2008 11:44:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IIiExg087899 for ; Tue, 18 Mar 2008 11:44:16 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by ug-out-1314.google.com with SMTP id z38so979015ugc.16 for ; Tue, 18 Mar 2008 11:44:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=hdHpUKtb75NWB3Euim+1uDExOntlRJ2HN2HhQhlFHd0=; b=HpfK2nD+Vyji5fXMZPP7d58biI4cXd/S1U5rKFpOkKLdAXzYghWwPk/4uzdqw1sG2QyvN83oKQnwQIdEAkASFtlVMBhUIjADMCt1IiZUwVXxGvhZsfJZ7CEikODFl+vUSRmiqWDeXYWYn+4h9oVbmKEfe9TLJ30IbEPPur9gC2M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ACV0lZFgvQwPJ/vkFAX3Bd7KDxi69YPAw/RxZ3c0zufYV//U7ytIexi1X8MnKjAxkDlqyKLLqWSO9+X08uDb097LcPUyhIZqgkZnuuVIezsYMWXf0mCUavV+0u3nI6tuqlLpDgAT6zcjkut9/owOgdpyH0YZesHN62RKdxVRFW4= Received: by 10.78.81.20 with SMTP id e20mr2814160hub.1.1205865849296; Tue, 18 Mar 2008 11:44:09 -0700 (PDT) Received: by 10.78.46.2 with HTTP; Tue, 18 Mar 2008 11:44:09 -0700 (PDT) Message-ID: <117bad160803181144p6cee7c57tdd3ede8fc3e5a636@mail.gmail.com> Date: Tue, 18 Mar 2008 18:44:09 +0000 From: "David Crick" To: "Andrey Jivsov" Subject: Re: ECC in OpenPGP proposal, forth revision Cc: ietf-openpgp@imc.org, "Ian G" In-Reply-To: <47DF054C.5090300@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47CD0451.9000503@brainhub.org> <117bad160803040655x3f393c7cuda72f361fbd119a4@mail.gmail.com> <47CE1648.6050402@brainhub.org> <117bad160803050356h54c755a4m2ada0ec7b53e8b0e@mail.gmail.com> <47D5A517.1010409@brainhub.org> <117bad160803110543vf22ecd1y8fdb3ac0409912e7@mail.gmail.com> <47DE3A52.2090508@brainhub.org> <117bad160803170610p3457d87eke44dc587d0d68a6a@mail.gmail.com> <47DF054C.5090300@brainhub.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Mar 17, 2008 at 11:57 PM, Andrey Jivsov wrote: > >> David Crick wrote: > > are you not going to add "MAY .. curve 2" into 11.1? > > > > both Ian and I have requested this ... > > Done. thank you. > >> > 12 "It is generally advisable to list at the head of the preference list > >> > a symmetric algorithm of strength corresponding to the public key." > >> > >> I watered down this statement to leave that at least the algorithm > >> should be there. > > > > I *preferred* the original version ("at the head")! .... > > Reversed. again, thanks. > >> > I think section 12 also needs to explicitly deprecate AES-192, > >> > >> I hope that we find a consensus in not explicitly promoting AES-192 > >> instead. > > > > For SSL it was decided to just go with AES128 and AES256: > > > > "The AES supports key lengths of 128, 192 and 256 bits. > > However, this document only defines ciphersuites for 128- > > and 256-bit keys. *This is to avoid unnecessary proliferation > > of ciphersuites.*" (rfc3268) > > > > (Similarly, with Camellia added to SSL again only the 128 and > > 256 length keys were added (rfc4132), again mentioning > > that just the 128+256 are being done, despite 192 exisiting.) > > > > TLS does have a problem of explosion of ciphersuites, something that > OpenPGP doesn't. I beg to differ! We currently have 8 (including patent-encumbered IDEA, and counting each of the AESes separately) ciphers, and look like we will be adding a further three Camellias too. I think that rfc3268's sentiments that I quoted above are highly admiral, and the decision to add only 128- and 256- bit Camellia further, and correctly, continues this policy. > At the same time, NSA employees submit other curves outside of Suite-B: > > http://www.faqs.org/rfcs/rfc4753.html we've *got* three NIST-approved ECC curves for each of the AES size keys, two of which are Suite B / NSA approved. Until there is either a market demand - *or* technical or security considerations - that would warrant looking at those other curves, then they're not even on my radar. > Plus, a controversial decision to use weaker ECC curve with AES-256... You've got this *completely* the wrong way around!! The flow was: 1. NIST blesses AES for sensitive information 2. NSA says AES128 is OK for SECRET, and 192 *and* 256 good enough for TOPSECRET. 3. NSA reveals Suite B, including suitable suites for SECRET and TOPSECRET use, the TOPSECRET cipher being AES256, the other components being the lower of *two valid* possible sets for TOPSECRET. Now, NSA give "interoperability" as their reasoning for excluding AES192; we can only guess what that means. But anyway, what they've done is chose *a* TOPSECRET strength for the public key and hash, and *a* TOPSECRET cipher. And this is for *Their* use, so it's damned well gotta be strong enough. The *fact* is that the cipher is *stronger* - *not* that they've "picked" a weaker hash/public key curve. (And in fact up until now in PGP we've generally had higher strength ciphers compared to public keys (2.6 with 128 IDEA and 2K max, PGP5+ with 4K max and 256-bit AES/Twofish).) So I don't think your argument holds, and if anything actually *supports* AES256 over AES192. But anyway... > I essentially added what you've asked regarding AES-192. Not outright, > but with a premise that you and Ian are using, which is, if we see the > world as divided into "weak" and "strong" systems, "strong" systems > SHOULD use AES-256. I'm not quite happy with the wording - I think it needs to be more "against" - plus, by having a single, clear sentence or two that simply states: "please note, use of AES192 is deprecated. You should only consider using it if you have very specific requirements." would actually cut out a *lot* of our current "advisory verbiage." *But*, having at least got *some* sort of wording into the draft about AES192, I'm *somewhat* "placated" - even if I'd (still) prefer it stated more strongly (*and* simply!). But anyway (again)... > Thank you. And again my thanks to you too - for helping us to bring ECC to PGP. I just want to try and do it in the best way possible! I *still* think that some of the "security recommendations" should be liberally sprinkled directly into each of the specific algorithm sections. This would make each section more readable in its own right, and would enable us to convert section 12 into a more general guidance section, rather than how it is now, with guidance *and* specific recommendations. However, it's your document!, and you've already stated that you feel that it would be better the way you've structured it. I really do think we've pretty much got the technical/application level stuff fairly well hammered out now, and that's it's near to the consensus [conflicting opinions ;) ] that we're aired. So from my point of view I think it's just honing the language and structure of the document that remains - seeing if we can more clearly and concisely put it across. 4880 is a highly readable RFC; I'd like to think we can make the ECC document just as consumable. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IDBZii048494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 06:11:35 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IDBZ46048493; Tue, 18 Mar 2008 06:11:35 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IDBYPS048485 for ; Tue, 18 Mar 2008 06:11:35 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.jabberwocky.com (c-75-69-177-157.hsd1.ma.comcast.net [75.69.177.157]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id m2IDBVP24092; Tue, 18 Mar 2008 08:11:31 -0500 Received: from [172.24.84.28] (grover.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.1/8.14.1) with ESMTP id m2IDBQI7001368; Tue, 18 Mar 2008 09:11:26 -0400 Cc: Jon Callas , ietf-openpgp@imc.org Message-Id: <0EFBD07E-1A44-4D8E-8894-C39E09B0C78B@jabberwocky.com> From: David Shaw To: Ian G In-Reply-To: <47DFBCFA.3090604@systemics.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: Ready for Camellia? Date: Tue, 18 Mar 2008 09:11:11 -0400 References: <20080311180200.GC4826@jabberwocky.com> <20080313152341.GB1587@jabberwocky.com> <47DA85DD.8000500@systemics.com> <20080314151611.GA651@jabberwocky.com> <47DFBCFA.3090604@systemics.com> X-Mailer: Apple Mail (2.919.2) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mar 18, 2008, at 9:00 AM, Ian G wrote: > Jon Callas wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >>> I just thought of another reason to leave Camellia-192 out: if we >>> leave it out and then change our minds, it's pretty easy to add it >>> later (just write a tiny RFC and get an algorithm number for it). >>> If >>> we do put it in now and then change our minds, it's nearly >>> impossible >>> to get rid of it later. >> As much as I think that 192-bit encryption is stupid, many people >> have impressed upon me reasons it exists, none of which are >> technical. >> I grit my teeth and hold my nose as I say this, but we have to have >> it. > > > I can understand this for Suite B because there is a defined and > controlled market for it, so the non-technical domain does rule. > > But for Camellia? As far as I can see this is a boutique algorithm > that someone is adding for the love of it. > > Well, ok, so if it is in, how does it go in? > > Is it possible to put 192-bit encryption in under some sort of > "COMPLIANCE-ONLY" label that means that you should only implement > this is if you've moved out of the technical domain? > > E.g., something below MUST, SHOULD, MAY, that suggests there are > issues here which are well outside the spec. That overloads additional semantics into the simple and elegant RFC keyword system. We already have a concept of "You don't have to do this. The spec doesn't require it. If you do choose do to it, however, do it like this." That's MAY. We don't need another way to say the same thing. David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2ID1UbZ047555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 06:01:30 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2ID1UJt047554; Tue, 18 Mar 2008 06:01:30 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from skaro.afraid.org (skaro.afraid.org [212.169.1.61]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2ID0tKp047473 for ; Tue, 18 Mar 2008 06:00:57 -0700 (MST) (envelope-from iang@systemics.com) Received: from zhukov.local (localhost.cthulhu.dircon.co.uk [127.0.0.1]) by skaro.afraid.org (Postfix) with ESMTP id B525C5D23; Tue, 18 Mar 2008 13:00:43 +0000 (GMT/BST) Message-ID: <47DFBCFA.3090604@systemics.com> Date: Tue, 18 Mar 2008 14:00:42 +0100 From: Ian G User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Jon Callas Cc: David Shaw , ietf-openpgp@imc.org Subject: Re: Ready for Camellia? References: <20080311180200.GC4826@jabberwocky.com> <20080313152341.GB1587@jabberwocky.com> <47DA85DD.8000500@systemics.com> <20080314151611.GA651@jabberwocky.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > >> I just thought of another reason to leave Camellia-192 out: if we >> leave it out and then change our minds, it's pretty easy to add it >> later (just write a tiny RFC and get an algorithm number for it). If >> we do put it in now and then change our minds, it's nearly impossible >> to get rid of it later. > > > As much as I think that 192-bit encryption is stupid, many people have > impressed upon me reasons it exists, none of which are technical. > > I grit my teeth and hold my nose as I say this, but we have to have it. I can understand this for Suite B because there is a defined and controlled market for it, so the non-technical domain does rule. But for Camellia? As far as I can see this is a boutique algorithm that someone is adding for the love of it. Well, ok, so if it is in, how does it go in? Is it possible to put 192-bit encryption in under some sort of "COMPLIANCE-ONLY" label that means that you should only implement this is if you've moved out of the technical domain? E.g., something below MUST, SHOULD, MAY, that suggests there are issues here which are well outside the spec. iang Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HNv836050708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 16:57:08 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2HNv8OX050706; Mon, 17 Mar 2008 16:57:08 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HNv40L050699 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 17 Mar 2008 16:57:07 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from localhost.localdomain (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by mail.cyberonic.com (8.12.8/8.12.8) with ESMTP id m2I0QjEG021711; Mon, 17 Mar 2008 19:26:46 -0500 Message-ID: <47DF054C.5090300@brainhub.org> Date: Mon, 17 Mar 2008 16:57:00 -0700 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: David Crick , Ian G Subject: ECC in OpenPGP proposal, forth revision References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47CC7750.7080206@brainhub.org> <117bad160803031449p1efb03bao654561db48a5dbb2@mail.gmail.com> <47CD0451.9000503@brainhub.org> <117bad160803040655x3f393c7cuda72f361fbd119a4@mail.gmail.com> <47CE1648.6050402@brainhub.org> <117bad160803050356h54c755a4m2ada0ec7b53e8b0e@mail.gmail.com> <47D5A517.1010409@brainhub.org> <117bad160803110543vf22ecd1y8fdb3ac0409912e7@mail.gmail.com> <47DE3A52.2090508@brainhub.org> <117bad160803170610p3457d87eke44dc587d0d68a6a@mail.gmail.com> In-Reply-To: <117bad160803170610p3457d87eke44dc587d0d68a6a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Crick wrote: > On Mon, Mar 17, 2008 at 9:30 AM, Andrey Jivsov wrote: >> David Crick wrote: >> > 11.1 I would like to see "MAY implement curve ID 2" explicitly stated >> > (this *is* mentioned in section 12, but would like to see it here too) > > are you not going to add "MAY .. curve 2" into 11.1? > > both Ian and I have requested this, and I have previously > pointed out that for *all* algos (asym, sym, hash) 4880 > adds a "MAY implement any other" to the end of each > section (where for ours, there IS only one other, so may > as well be mentioned specifically, i.e. MAY curve 2) Done. > > ... > >> > 12 "It is generally advisable to list at the head of the preference list >> > a symmetric algorithm of strength corresponding to the public key." >> >> I watered down this statement to leave that at least the algorithm >> should be there. > > I *preferred* the original version ("at the head")! .... Reversed. (Can I be more overzealous in consensus building?). > > >> > Again, I see what you're trying to say, but as is noted elsewhere in >> > the ECC doc, it's merely the intersection - it's up to the implementation >> > to make its own decision thereafter (and so take advantage of any >> > ordering information). >> >> As a side note, per RFC4880 this "is an ordered list of octets with the >> most preferred listed firs". If each recipient has the same set of >> symmetric algorithms, shouldn't the intersection remain ordered? I think >> "merely an intersection" is not strictly correct, although I can agree >> with "in practice" or "in most cases" clarification. > > ... I was referring to THIS bit in 4880 (13.2): > > "The implementation may use any mechanism to pick an > algorithm in the intersection." > > Thus, while the section you quote (5.2.3.7) is *also* correct, > what 13.2 is saying is "well, there's information you COULD > use, but it's really up to you [the implementation] to pick an > algorithm." > > > Therefore, I was *happy* with your original wording (and would > prefer to see it re-instatad!), but was just pointing out that it > was only part of the (i.e. [4880] rfc) story. OK, the above clears this one. > > >> > I think section 12 also needs to explicitly deprecate AES-192, saying >> > that it's not necessarily going to be fielded widely (bring in the fact >> > that it is only a MAY here might help), isn't one of the Suite B ciphers, >> > and that it's probably only suitable if for some reason you *really* >> > need a 192-bit cipher: otherwise go for AES256 for security or -128 >> > for performance. >> >> I hope that we find a consensus in not explicitly promoting AES-192 >> instead. There are many reasons why mobile/weak hardware devices may >> wish the middle-of-the-road approach with AES-192/ECC-384. > > For SSL it was decided to just go with AES128 and AES256: > > "The AES supports key lengths of 128, 192 and 256 bits. > However, this document only defines ciphersuites for 128- > and 256-bit keys. *This is to avoid unnecessary proliferation > of ciphersuites.*" (rfc3268) > > (Similarly, with Camellia added to SSL again only the 128 and > 256 length keys were added (rfc4132), again mentioning > that just the 128+256 are being done, despite 192 exisiting.) > TLS does have a problem of explosion of ciphersuites, something that OpenPGP doesn't. I recall that one of main technical reasons of preferring one Open PGP auth. spec to another in the past was this issue. > With Suite B, NSA have chosen to also just go with 128 and > 256, despite the other elements of the larger algo set being > 192-equivelent in size. From their footnote 1: > > "CNSSP-15 correctly states that 192-bit AES keys are sufficient > for protecting even TOPSECRET information. However, Suite B > uses only 256-bit keys *to enhance interoperability*." > At the same time, NSA employees submit other curves outside of Suite-B: http://www.faqs.org/rfcs/rfc4753.html Plus, a controversial decision to use weaker ECC curve with AES-256... > > Our MUST is AES-128, our SHOULD is AES-256. I think we should > be following the trend in promoting just 128 and 256 bit ciphers, > and by deprecating AES-192 - which we NEED to do with the > stronger Suite B set (perhaps possible the "only" reason to > implement Curve 2, give our MUST on C1 and SHOULD on C3). I essentially added what you've asked regarding AES-192. Not outright, but with a premise that you and Ian are using, which is, if we see the world as divided into "weak" and "strong" systems, "strong" systems SHOULD use AES-256. Thank you. The latest version is: http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-9.txt The same version in other formats: http://brainhub.googlepages.com/pgp Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HL41xr034747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 14:04:01 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2HL41pf034746; Mon, 17 Mar 2008 14:04:01 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HL40x5034739 for ; Mon, 17 Mar 2008 14:04:00 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.jabberwocky.com (c-75-69-177-157.hsd1.ma.comcast.net [75.69.177.157]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id m2HL3wP19767 for ; Mon, 17 Mar 2008 16:03:58 -0500 Received: from jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.1/8.14.1) with SMTP id m2HL3rRT028506 for ; Mon, 17 Mar 2008 17:03:54 -0400 Date: Mon, 17 Mar 2008 17:03:53 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Ready for Camellia? Message-ID: <20080317210353.GJ22491@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20080311180200.GC4826@jabberwocky.com> <20080313152341.GB1587@jabberwocky.com> <47DA85DD.8000500@systemics.com> <20080314151611.GA651@jabberwocky.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.17 (2007-11-01) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Mar 14, 2008 at 01:17:10PM -0700, Jon Callas wrote: > > > > > I just thought of another reason to leave Camellia-192 out: if we > > leave it out and then change our minds, it's pretty easy to add it > > later (just write a tiny RFC and get an algorithm number for it). If > > we do put it in now and then change our minds, it's nearly impossible > > to get rid of it later. > > > As much as I think that 192-bit encryption is stupid, many people have > impressed upon me reasons it exists, none of which are technical. > > I grit my teeth and hold my nose as I say this, but we have to have it. Ok, it's a mild ugliness, but it isn't actually harming anything. I'll rev the draft and add it. David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HJZXXt026810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 12:35:33 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2HJZXnW026809; Mon, 17 Mar 2008 12:35:33 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HJZUX6026799 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 17 Mar 2008 12:35:32 -0700 (MST) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1JbLFR-0005lD-0a for ; Mon, 17 Mar 2008 20:43:53 +0100 Received: from wk by localhost with local (Exim 4.62 #1 (Debian)) id 1JbL2b-00022P-78 for ; Mon, 17 Mar 2008 20:30:37 +0100 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: Ready for Camellia? References: <20080311180200.GC4826@jabberwocky.com> <20080313152341.GB1587@jabberwocky.com> Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Mon, 17 Mar 2008 20:30:37 +0100 In-Reply-To: <20080313152341.GB1587@jabberwocky.com> (David Shaw's message of "Thu, 13 Mar 2008 11:23:41 -0400") Message-ID: <87iqzl4082.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.110007 (No Gnus v0.7) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 13 Mar 2008 16:23, dshaw@jabberwocky.com said: > I would particulary appreciate comments on the choice of 128 and > 256-bit keys (that is, lacking 192). I tend to agree with Jon that Drop Camellia-192. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HFKd1Q099539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 08:20:39 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2HFKdxF099538; Mon, 17 Mar 2008 08:20:39 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from skaro.afraid.org (skaro.afraid.org [212.169.1.61]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HFKVbY099528 for ; Mon, 17 Mar 2008 08:20:38 -0700 (MST) (envelope-from iang@systemics.com) Received: from zhukov.local (localhost.cthulhu.dircon.co.uk [127.0.0.1]) by skaro.afraid.org (Postfix) with ESMTP id 29B9C5D23; Mon, 17 Mar 2008 15:20:10 +0000 (GMT/BST) Message-ID: <47DE8C23.1030600@systemics.com> Date: Mon, 17 Mar 2008 16:20:03 +0100 From: Ian G User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Andrey Jivsov Cc: ietf-openpgp@imc.org, David Crick Subject: Re: ECC in OpenPGP proposal, second revision References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <47CC7750.7080206@brainhub.org> <117bad160803031449p1efb03bao654561db48a5dbb2@mail.gmail.com> <47CD0451.9000503@brainhub.org> <117bad160803040655x3f393c7cuda72f361fbd119a4@mail.gmail.com> <47CE1648.6050402@brainhub.org> <117bad160803050356h54c755a4m2ada0ec7b53e8b0e@mail.gmail.com> <47D5A517.1010409@brainhub.org> <117bad160803110543vf22ecd1y8fdb3ac0409912e7@mail.gmail.com> <47DE3A52.2090508@brainhub.org> In-Reply-To: <47DE3A52.2090508@brainhub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Andrey Jivsov wrote: >> I think section 12 also needs to explicitly deprecate AES-192, saying >> that it's not necessarily going to be fielded widely (bring in the fact >> that it is only a MAY here might help), isn't one of the Suite B ciphers, >> and that it's probably only suitable if for some reason you *really* >> need a 192-bit cipher: otherwise go for AES256 for security or -128 >> for performance. > > I hope that we find a consensus in not explicitly promoting AES-192 > instead. There are many reasons why mobile/weak hardware devices may > wish the middle-of-the-road approach with AES-192/ECC-384. I agree with David, I personally have yet to see a valid engineering reason why one would use AES-192. Jon has laid out some non-engineering reasons why it should be there, and that's a difficult area for us to argue against (maybe something Jon and I agree violently over). So I guess we are agreed that it should be possible to do AES-192 ... but that doesn't mean we should encourage it at all. AES-128+friends gives a whole lot of security, and that is probably enough for most if not every mobile application. You want more than 128? Go for the top profile (or go find a machine with the top profile). If your attacker can crunch AES-128+friends then we can't possibly recommend AES-192 because we just don't know what your attacker is up to. I like David's skepticism in words, above. RFC consumers who fancy something "a bit better than 128" should be discouraged, or understand that they are creating problems, they'd better be prepared for the consequences, and the community isn't working for them any more. Deprecated is a good scary word. > If we were to discourage AES-192, we will need convincing references to > data that support and explain our choice. I see no sweet spot in that data, so I read it as supporting the lack of value in AES-192. iang Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HDAxJA084191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 06:10:59 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2HDAxiL084190; Mon, 17 Mar 2008 06:10:59 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.186]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HDAwcN084181 for ; Mon, 17 Mar 2008 06:10:59 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by gv-out-0910.google.com with SMTP id l14so851571gvf.13 for ; Mon, 17 Mar 2008 06:10:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=fI2B4hAtPrB9lysJdx5dJfm8g3hGxMxJaSagRMs6Vmw=; b=iP5kS7Os+Z7QlyCEDdWI7JvR+pvXIni53RzpqRARzb24ZMO3a6A9/XjrUrgKSBEoFzjb0FRpeE8N76/RglG/iKVwxF0vrsXQuP/0xQhW+gCOjHwIIe++eYH6B5NDuxxEUDno+fFwISgCIxNmUf2qE7/zucoOfjKWxvNxUHE0wMI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=i2c1ERHFAKhz30nk1NnTO2m5pFNzgpq0rR1ssIIDRA7cCACNyhvOiDIUiMgGbqdrPrcYQ9HcxpJ7JIQzryRyxEoEVEzKVfyHgEk3+1qfbvxQVVqe4PaKNU5uwJilo822Oe383mAkw9ojQpz9qEFjVC6BrQCmLrjMqyrRIvBu+5U= Received: by 10.142.158.17 with SMTP id g17mr39936wfe.127.1205759455298; Mon, 17 Mar 2008 06:10:55 -0700 (PDT) Received: by 10.143.188.1 with HTTP; Mon, 17 Mar 2008 06:10:55 -0700 (PDT) Message-ID: <117bad160803170610p3457d87eke44dc587d0d68a6a@mail.gmail.com> Date: Mon, 17 Mar 2008 13:10:55 +0000 From: "David Crick" To: "Andrey Jivsov" Subject: Re: ECC in OpenPGP proposal, second revision Cc: ietf-openpgp@imc.org In-Reply-To: <47DE3A52.2090508@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47CC7750.7080206@brainhub.org> <117bad160803031449p1efb03bao654561db48a5dbb2@mail.gmail.com> <47CD0451.9000503@brainhub.org> <117bad160803040655x3f393c7cuda72f361fbd119a4@mail.gmail.com> <47CE1648.6050402@brainhub.org> <117bad160803050356h54c755a4m2ada0ec7b53e8b0e@mail.gmail.com> <47D5A517.1010409@brainhub.org> <117bad160803110543vf22ecd1y8fdb3ac0409912e7@mail.gmail.com> <47DE3A52.2090508@brainhub.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Mar 17, 2008 at 9:30 AM, Andrey Jivsov wrote: > David Crick wrote: > > 11.1 I would like to see "MAY implement curve ID 2" explicitly stated > > (this *is* mentioned in section 12, but would like to see it here too) are you not going to add "MAY .. curve 2" into 11.1? both Ian and I have requested this, and I have previously pointed out that for *all* algos (asym, sym, hash) 4880 adds a "MAY implement any other" to the end of each section (where for ours, there IS only one other, so may as well be mentioned specifically, i.e. MAY curve 2) > > 11.3 says "The best remedy to this .. is to add .. AES-256" > > > > not sure about "best" - perhaps "simplest"? The reason being is > > that as AES128 is an ECC must, then this guarantees us *a* Suite > > B acceptable cipher, although - as you're trying to get at - having > > AES256 means that we'd cover *both* Suite B profiles. > > > > Corrected. great, this is now better. > > 12 "It is generally advisable to list at the head of the preference list > > a symmetric algorithm of strength corresponding to the public key." > > I watered down this statement to leave that at least the algorithm > should be there. I *preferred* the original version ("at the head")! .... > > Again, I see what you're trying to say, but as is noted elsewhere in > > the ECC doc, it's merely the intersection - it's up to the implementation > > to make its own decision thereafter (and so take advantage of any > > ordering information). > > As a side note, per RFC4880 this "is an ordered list of octets with the > most preferred listed firs". If each recipient has the same set of > symmetric algorithms, shouldn't the intersection remain ordered? I think > "merely an intersection" is not strictly correct, although I can agree > with "in practice" or "in most cases" clarification. ... I was referring to THIS bit in 4880 (13.2): "The implementation may use any mechanism to pick an algorithm in the intersection." Thus, while the section you quote (5.2.3.7) is *also* correct, what 13.2 is saying is "well, there's information you COULD use, but it's really up to you [the implementation] to pick an algorithm." Therefore, I was *happy* with your original wording (and would prefer to see it re-instatad!), but was just pointing out that it was only part of the (i.e. [4880] rfc) story. > > I think section 12 also needs to explicitly deprecate AES-192, saying > > that it's not necessarily going to be fielded widely (bring in the fact > > that it is only a MAY here might help), isn't one of the Suite B ciphers, > > and that it's probably only suitable if for some reason you *really* > > need a 192-bit cipher: otherwise go for AES256 for security or -128 > > for performance. > > I hope that we find a consensus in not explicitly promoting AES-192 > instead. There are many reasons why mobile/weak hardware devices may > wish the middle-of-the-road approach with AES-192/ECC-384. For SSL it was decided to just go with AES128 and AES256: "The AES supports key lengths of 128, 192 and 256 bits. However, this document only defines ciphersuites for 128- and 256-bit keys. *This is to avoid unnecessary proliferation of ciphersuites.*" (rfc3268) (Similarly, with Camellia added to SSL again only the 128 and 256 length keys were added (rfc4132), again mentioning that just the 128+256 are being done, despite 192 exisiting.) With Suite B, NSA have chosen to also just go with 128 and 256, despite the other elements of the larger algo set being 192-equivelent in size. From their footnote 1: "CNSSP-15 correctly states that 192-bit AES keys are sufficient for protecting even TOPSECRET information. However, Suite B uses only 256-bit keys *to enhance interoperability*." Our MUST is AES-128, our SHOULD is AES-256. I think we should be following the trend in promoting just 128 and 256 bit ciphers, and by deprecating AES-192 - which we NEED to do with the stronger Suite B set (perhaps possible the "only" reason to implement Curve 2, give our MUST on C1 and SHOULD on C3). Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2H9V57k055607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 02:31:05 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2H9V5Fk055606; Mon, 17 Mar 2008 02:31:05 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2H9V3ok055600 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 17 Mar 2008 02:31:05 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from localhost.localdomain (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by mail.cyberonic.com (8.12.8/8.12.8) with ESMTP id m2HA0VEG006061; Mon, 17 Mar 2008 05:00:32 -0500 Message-ID: <47DE3A52.2090508@brainhub.org> Date: Mon, 17 Mar 2008 02:30:58 -0700 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: David Crick Subject: Re: ECC in OpenPGP proposal, second revision References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <47CC7750.7080206@brainhub.org> <117bad160803031449p1efb03bao654561db48a5dbb2@mail.gmail.com> <47CD0451.9000503@brainhub.org> <117bad160803040655x3f393c7cuda72f361fbd119a4@mail.gmail.com> <47CE1648.6050402@brainhub.org> <117bad160803050356h54c755a4m2ada0ec7b53e8b0e@mail.gmail.com> <47D5A517.1010409@brainhub.org> <117bad160803110543vf22ecd1y8fdb3ac0409912e7@mail.gmail.com> In-Reply-To: <117bad160803110543vf22ecd1y8fdb3ac0409912e7@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Crick wrote: > 11.1 I would like to see "MAY implement curve ID 2" explicitly stated > (this *is* mentioned in section 12, but would like to see it here too) > > > 11.3 says "The best remedy to this .. is to add .. AES-256" > > not sure about "best" - perhaps "simplest"? The reason being is > that as AES128 is an ECC must, then this guarantees us *a* Suite > B acceptable cipher, although - as you're trying to get at - having > AES256 means that we'd cover *both* Suite B profiles. > Corrected. > I'm not sure if I agree with the sentiment of "adding .. to .. each > recipient's key" - doesn't quite sound right? (Maybe because it > sounds like sender coercion, rather than a higher-level admin > led policy?) With the mentioned correction this is one of possible alternatives. It is one of cleanest fixes in the sense of standard correctness. I realize that it is not a practical fix for the incompatibility. I can't fix the keys at at the moment I am sending a message. That's why we should mention the importance of proper key preferences in reference to relative security. > > > 12 "It is generally advisable to list at the head of the preference list > a symmetric algorithm of strength corresponding to the public key." I watered down this statement to leave that at least the algorithm should be there. > > Again, I see what you're trying to say, but as is noted elsewhere in > the ECC doc, it's merely the intersection - it's up to the implementation > to make its own decision thereafter (and so take advantage of any > ordering information). As a side note, per RFC4880 this "is an ordered list of octets with the most preferred listed firs". If each recipient has the same set of symmetric algorithms, shouldn't the intersection remain ordered? I think "merely an intersection" is not strictly correct, although I can agree with "in practice" or "in most cases" clarification. > > I think section 12 also needs to explicitly deprecate AES-192, saying > that it's not necessarily going to be fielded widely (bring in the fact > that it is only a MAY here might help), isn't one of the Suite B ciphers, > and that it's probably only suitable if for some reason you *really* > need a 192-bit cipher: otherwise go for AES256 for security or -128 > for performance. I hope that we find a consensus in not explicitly promoting AES-192 instead. There are many reasons why mobile/weak hardware devices may wish the middle-of-the-road approach with AES-192/ECC-384. The evidence regarding performance shortcoming of AES-192 is not overwhelming. On http://www.cryptopp.com/benchmarks.html AES/ECB 192 appears even faster than 128 in key setup (a measurement aberration, perhaps). The data encoding speed is decreasing smoothly for 128/192/256 keys with a factor ~1.13. So is data encoding performance in http://www.linux.com/feature/114024 for AES 128/192/256 with CBC for both 16 bytes and 8192 bytes. The throughput is reduced by a factor ~1.15 as we go to stronger AES. GnuPG shows gradual slowdown for AES 128/192/256 http://www.nchelp.org/committees/cl-elec-exch/msg00734.html. The factor is ~1.03. If we were to discourage AES-192, we will need convincing references to data that support and explain our choice. > > > overall, though, I think we're getting there. > ... The latest version is: http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-8.txt The same version in other formats: http://brainhub.googlepages.com/pgp Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EKQ7lW031399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Mar 2008 13:26:07 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2EKQ7EF031398; Fri, 14 Mar 2008 13:26:07 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EKQ4B7031359 for ; Fri, 14 Mar 2008 13:26:07 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id B90BAD83FC8 for ; Fri, 14 Mar 2008 13:26:04 -0700 (PDT) Received: from titania.pgp.com ([63.251.255.205]) by keys.merrymeet.com (PGP Universal service); Fri, 14 Mar 2008 13:26:04 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 14 Mar 2008 13:26:04 -0700 Message-Id: From: Jon Callas To: OpenPGP In-Reply-To: <20080313210256.GC18071@epointsystem.org> Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: Closing the openpgp working group Date: Fri, 14 Mar 2008 13:26:03 -0700 References: <47D53515.5050201@systemics.com> <117bad160803101012m52d22fdnd9aba86fc0ea33b1@mail.gmail.com> <87r6eebcav.fsf@mid.deneb.enyo.de> <20080313210256.GC18071@epointsystem.org> X-Mailer: Apple Mail (2.919.2) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > And while we are at it, I would suggest to express V5 fingerprints > (as well > as key IDs) either in octal or in decimal. This is not a > cryptography issue > (*), but a usability issue on (typically mobile) devices with > numeric-only > keypads. As an added benefit, it would make the keyID ~ telephone > number > metaphor more sustainable. > > For such a decision, OpenPGP could earn the ethernal gratitude of > the entire > telecom industry. I think we should not tie non SHA-1 fingerprints to V5 key ids. I like the proposal someone had at one point that you have a syntax that includes the hash number. Thus, a present fingerprint would become: 2:012356789ABCDEF... A SHA-256 version would be: 8:FEDCBA987654..... Within this, if you want a shorter version of the fingerprint, you simply truncate the right-most portion (which "fixes" the present mechanism). Once you have this mechanism, a way to do a fingerprint in decimal or octal is pretty easy. It's also easy for telephones to map the ':' to a '*' (e.g.). I leave the exact signal for a different radix as an exercise for someone to suggest. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFH2t9csTedWZOD3gYRAh/RAJ9nrAV4gIWAGII7gXBhyrxBj+PaKgCg2pCe 5f7X5YRUDDdgg+vmlDw+siU= =r0IL -----END PGP SIGNATURE----- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EKHE17030945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Mar 2008 13:17:14 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2EKHEZi030944; Fri, 14 Mar 2008 13:17:14 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EKHDCJ030937 for ; Fri, 14 Mar 2008 13:17:14 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id CE6F1D83E85 for ; Fri, 14 Mar 2008 13:17:12 -0700 (PDT) Received: from titania.pgp.com ([63.251.255.205]) by keys.merrymeet.com (PGP Universal service); Fri, 14 Mar 2008 13:17:12 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 14 Mar 2008 13:17:12 -0700 Cc: ietf-openpgp@imc.org Message-Id: From: Jon Callas To: David Shaw In-Reply-To: <20080314151611.GA651@jabberwocky.com> Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: Ready for Camellia? Date: Fri, 14 Mar 2008 13:17:10 -0700 References: <20080311180200.GC4826@jabberwocky.com> <20080313152341.GB1587@jabberwocky.com> <47DA85DD.8000500@systemics.com> <20080314151611.GA651@jabberwocky.com> X-Mailer: Apple Mail (2.919.2) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > I just thought of another reason to leave Camellia-192 out: if we > leave it out and then change our minds, it's pretty easy to add it > later (just write a tiny RFC and get an algorithm number for it). If > we do put it in now and then change our minds, it's nearly impossible > to get rid of it later. As much as I think that 192-bit encryption is stupid, many people have impressed upon me reasons it exists, none of which are technical. I grit my teeth and hold my nose as I say this, but we have to have it. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFH2t1IsTedWZOD3gYRAhB2AKC/jO2WcnR61Kbi9YGxhQeLngvynwCeJFUi 94ONpVHASVBxT63b185HqoM= =ngZw -----END PGP SIGNATURE----- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EJBFTB024664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Mar 2008 12:11:16 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2EJBF3Y024663; Fri, 14 Mar 2008 12:11:15 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EJBDWo024654 for ; Fri, 14 Mar 2008 12:11:15 -0700 (MST) (envelope-from JPClizbe@tx.rr.com) Received: from [127.0.0.1] (really [72.190.107.50]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20080314191112.FTIE8359.mta9.adelphia.net@[127.0.0.1]> for ; Fri, 14 Mar 2008 15:11:12 -0400 Message-ID: <47DACDCF.10103@tx.rr.com> Date: Fri, 14 Mar 2008 14:11:11 -0500 From: John Clizbe Organization: GingerBear Conspiracy Theories To Go User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 SeaMonkey/1.1.8 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Non-hex key IDs References: <47D53515.5050201@systemics.com> <117bad160803101012m52d22fdnd9aba86fc0ea33b1@mail.gmail.com> <87r6eebcav.fsf@mid.deneb.enyo.de> <20080313210256.GC18071@epointsystem.org> <20080314154105.GB651@jabberwocky.com> In-Reply-To: <20080314154105.GB651@jabberwocky.com> X-Enigmail-Version: 0.95.6 OpenPGP: X-Face: &KOqPhy&\S+}^~xEHZGEs'8mps-5a4E=`i>2c!PuesSM7lpv}^Yfn<6?y=BF@X+N!n&!L&# .m>o,xH$v%{I8Gmf/Z'.qB|U;][A5$#c;u%(rJ\S"2NotGhXF@~cM4'Q!/E\9cP{1M;J8A0e>-&xN, hQ>[CjNA{+~zDNk1'jz@|yeaCJX*M1;(Tb_7(.WCK:)}W?d.Nl<8&W{]/T-+gG?\lS) List-Unsubscribe: List-ID: David Shaw wrote: > On Thu, Mar 13, 2008 at 10:02:56PM +0100, Daniel A. Nagy wrote: >> And while we are at it, I would suggest to express V5 fingerprints (as well >> as key IDs) either in octal or in decimal. This is not a cryptography issue >> (*), but a usability issue on (typically mobile) devices with numeric-only >> keypads. As an added benefit, it would make the keyID ~ telephone number >> metaphor more sustainable. >> > It would also be interesting to see if someone (the phone companies?) has done > a study on how many digits people can easily remember. Miller, G. A. (1956). The magical number seven, plus or minus two: Some limits on our capacity for processing information. Psychological Review, 63, 81-97. http://www.musanim.com/miller1956/ 7 +/- 2 There's a Wikipedia discussion of it at http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EFfDd0003241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Mar 2008 08:41:13 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2EFfDB7003240; Fri, 14 Mar 2008 08:41:13 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EFfBQ7003233 for ; Fri, 14 Mar 2008 08:41:12 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.jabberwocky.com (c-75-69-177-157.hsd1.ma.comcast.net [75.69.177.157]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id m2EFfBN26995 for ; Fri, 14 Mar 2008 10:41:11 -0500 Received: from jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.1/8.14.1) with SMTP id m2EFf6Gd006619 for ; Fri, 14 Mar 2008 11:41:06 -0400 Date: Fri, 14 Mar 2008 11:41:05 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Non-hex key IDs (was: Closing the openpgp working group) Message-ID: <20080314154105.GB651@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <47D53515.5050201@systemics.com> <117bad160803101012m52d22fdnd9aba86fc0ea33b1@mail.gmail.com> <87r6eebcav.fsf@mid.deneb.enyo.de> <20080313210256.GC18071@epointsystem.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080313210256.GC18071@epointsystem.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.17 (2007-11-01) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 13, 2008 at 10:02:56PM +0100, Daniel A. Nagy wrote: > And while we are at it, I would suggest to express V5 fingerprints (as well > as key IDs) either in octal or in decimal. This is not a cryptography issue > (*), but a usability issue on (typically mobile) devices with numeric-only > keypads. As an added benefit, it would make the keyID ~ telephone number > metaphor more sustainable. > > For such a decision, OpenPGP could earn the ethernal gratitude of the entire > telecom industry. The current hex method is nicely dense: 8 characters gives you 32 bits, which is enough (today, anyway) to find and disambiguate keys in virtually all cases (once the key is found, of course, we have the 64-bit key ID). If you are restricted to the numbers 0-9, those 8 characters only give you a bit more than 26 bits, so there would be a greater chance of collision. You'd need to go to a 10-digit decimal key ID to cover the same space as the 8 character hex ID. 10 characters isn't too bad. It would be interesting to write a test against the keyservers to see how much of an issue this really is. It would also be interesting to see if someone (the phone companies?) has done a study on how many digits people can easily remember. As it happens, my key id is all decimals anyway... David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EFGJgq001204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Mar 2008 08:16:19 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2EFGJZc001203; Fri, 14 Mar 2008 08:16:19 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EFGH6a001197 for ; Fri, 14 Mar 2008 08:16:18 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.jabberwocky.com (c-75-69-177-157.hsd1.ma.comcast.net [75.69.177.157]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id m2EFGGN26778 for ; Fri, 14 Mar 2008 10:16:16 -0500 Received: from jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.1/8.14.1) with SMTP id m2EFGBVR006487 for ; Fri, 14 Mar 2008 11:16:11 -0400 Date: Fri, 14 Mar 2008 11:16:11 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Ready for Camellia? Message-ID: <20080314151611.GA651@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20080311180200.GC4826@jabberwocky.com> <20080313152341.GB1587@jabberwocky.com> <47DA85DD.8000500@systemics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47DA85DD.8000500@systemics.com> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.17 (2007-11-01) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Mar 14, 2008 at 03:04:13PM +0100, Ian G wrote: >> I think we're ready for the final push on Camellia. All of the >> suggested changes have been incorporated, and if folks could give it a >> final read, I'd appreciate it: >> http://www.ietf.org/internet-drafts/draft-ietf-openpgp-camellia-01.txt > I am confused about one language difference between Camellia doc and ECC > doc. In Camellia, there are MAYs. In ECC, there are MUSTs, SHOULDs, MAYs. > > The way I interpret it, Camellia is *incorporated within* RFC4880 and adds > MAY algorithms. But ECC is *appended as a MAY* ... the entire appendix is > a MAY, within which there are choices guided by RFC2119. > > Maybe I'm wrong about my interpretation, and if so, stop reading here. I disagree with that interpretation. There is nothing special about Camellia here. Both Camellia and ECC are the same: new RFCs that specify new functionality. Whatever they may specify, they can only specify that in regards to themselves. > This document is an optional appendix to [RFC4880] which > makes the entire Camellia addition a MAY. If you do add > Camellia then you must follow the recommendations below > using the normal language of [RFC2119]. > > OK, that's really crappy language but I hope you get the idea. The draft more or less says that: OpenPGP applications MAY implement Camellia. If implemented, Camellia may be used in any place in OpenPGP where a symmetric cipher is usable, and is subject to the same usage requirements (such as its presence in the Preferred Symmetric Algorithms signature subpacket) as the other symmetric ciphers in OpenPGP. Note that the whole draft has only one "MAY" (and no MUSTs, SHOULDs, etc) with regards to Camellia. That is appropriate for a simple algorithm RFC. It's "you MAY implement this, but doing so doesn't get you out of the various MUSTs and other rules from 4880." > I agree with dropping 192. I see no consistency argument here, the notion > of having consistent sets across algorithms seems esthetic only. Real > users won't understand these notions of esthetics. I just thought of another reason to leave Camellia-192 out: if we leave it out and then change our minds, it's pretty easy to add it later (just write a tiny RFC and get an algorithm number for it). If we do put it in now and then change our minds, it's nearly impossible to get rid of it later. David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EEFShd095022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Mar 2008 07:15:29 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2EEFSEi095021; Fri, 14 Mar 2008 07:15:28 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from skaro.afraid.org (skaro.afraid.org [212.169.1.61]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EEFRL2095010 for ; Fri, 14 Mar 2008 07:15:28 -0700 (MST) (envelope-from iang@systemics.com) Received: from zhukov.local (localhost.cthulhu.dircon.co.uk [127.0.0.1]) by skaro.afraid.org (Postfix) with ESMTP id E76225D23; Fri, 14 Mar 2008 14:15:24 +0000 (GMT/BST) Message-ID: <47DA887C.9080505@systemics.com> Date: Fri, 14 Mar 2008 15:15:24 +0100 From: Ian G User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: "Daniel A. Nagy" Cc: ietf-openpgp@imc.org Subject: Re: Closing the openpgp working group References: <47D53515.5050201@systemics.com> <117bad160803101012m52d22fdnd9aba86fc0ea33b1@mail.gmail.com> <87r6eebcav.fsf@mid.deneb.enyo.de> <20080313210256.GC18071@epointsystem.org> In-Reply-To: <20080313210256.GC18071@epointsystem.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel A. Nagy wrote: > On Thu, Mar 13, 2008 at 09:26:32PM +0100, Florian Weimer wrote: >> * David Crick: >> >>>> How much enthusiasm is there for this? Enough to generate >>>> some consensus? Is there a business case for a redesign? >>> "doesn't use SHA1" sounds like a good V5 business case.... >> Yes, some of us do check-list based security, and not having to rely on >> SHA-1 is helpful in this area. > > And while we are at it, I would suggest to express V5 fingerprints (as well > as key IDs) either in octal or in decimal. This is not a cryptography issue > (*), but a usability issue on (typically mobile) devices with numeric-only > keypads. As an added benefit, it would make the keyID ~ telephone number > metaphor more sustainable. > > For such a decision, OpenPGP could earn the ethernal gratitude of the entire > telecom industry. I cautiously agree with this. The old idea of hex and base64 was about saving bits and aligning with the soul of the computer. Those ideas are anachronisms with modern capacities, and with modern users. (Also, in both SSH and PGP, we have seen difficulties with key identification ... with different varieties of expression being incompatible. This failure has slowed down and probably killed the ability to check public keys easily, a major tenet of opportunistic cryptography.) So it would be nice to create one unified way. Something like, all key Ids are expressed as parts of ordinary base-10 numbers of the formal SHA-512 hash of the key. The key Id is always read from the left side of the full hash. If you want more discrimination you read off more digits. The size of the number tells you the discrimination. ("something like" being a thought experiment, not a serious suggestion to start coding ;) iang Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EE4Mus093601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Mar 2008 07:04:22 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2EE4MfF093600; Fri, 14 Mar 2008 07:04:22 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from skaro.afraid.org (skaro.afraid.org [212.169.1.61]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EE4LWL093593 for ; Fri, 14 Mar 2008 07:04:22 -0700 (MST) (envelope-from iang@systemics.com) Received: from zhukov.local (localhost.cthulhu.dircon.co.uk [127.0.0.1]) by skaro.afraid.org (Postfix) with ESMTP id 94D1D5D23 for ; Fri, 14 Mar 2008 14:04:13 +0000 (GMT/BST) Message-ID: <47DA85DD.8000500@systemics.com> Date: Fri, 14 Mar 2008 15:04:13 +0100 From: Ian G User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Ready for Camellia? References: <20080311180200.GC4826@jabberwocky.com> <20080313152341.GB1587@jabberwocky.com> In-Reply-To: <20080313152341.GB1587@jabberwocky.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Shaw wrote: > On Wed, Mar 12, 2008 at 01:29:49PM -0400, Derek Atkins wrote: >> David Shaw writes: >> >> [snip] >>> I think that is just fine, and thanks for working this out. >>> >>> I have a minor process question though: I've done a couple of Camellia >>> drafts as "draft-ietf-openpgp-camellia". Do I need to convert that to >>> "draft-shaw-openpgp-camellia" (i.e. an individual submission) and >>> re-submit? >> No, it can stay as 'draft-ietf-openpgp-'. No need to rename and >> resubmit as an individual. > > Great, thanks. > > I think we're ready for the final push on Camellia. All of the > suggested changes have been incorporated, and if folks could give it a > final read, I'd appreciate it: > http://www.ietf.org/internet-drafts/draft-ietf-openpgp-camellia-01.txt I just skimmed it. I am confused about one language difference between Camellia doc and ECC doc. In Camellia, there are MAYs. In ECC, there are MUSTs, SHOULDs, MAYs. The way I interpret it, Camellia is *incorporated within* RFC4880 and adds MAY algorithms. But ECC is *appended as a MAY* ... the entire appendix is a MAY, within which there are choices guided by RFC2119. Maybe I'm wrong about my interpretation, and if so, stop reading here. It would be nice if we could agree on a more unified way of treating this. Personally I prefer the ECC style, as it allows for some richness within. However, there should be a line at the top of the document describing the relationship to the mother document. Something like: This document is an optional appendix to [RFC4880] which makes the entire Camellia addition a MAY. If you do add Camellia then you must follow the recommendations below using the normal language of [RFC2119]. OK, that's really crappy language but I hope you get the idea. > I would particulary appreciate comments on the choice of 128 and > 256-bit keys (that is, lacking 192). I tend to agree with Jon that > 192 is neither here nor there, but I'm also a major fan of > consistency. If we're going to include 192 for the ECC work, then > it's odd to leave it out here. I agree with dropping 192. I see no consistency argument here, the notion of having consistent sets across algorithms seems esthetic only. Real users won't understand these notions of esthetics. The sensible reason for including 192 in ECC was outlined by Jon. There are checkboxes that big corps and big TLAs follow when buying this stuff. They do not understand what they are doing, they simply tick boxes (by definition, as if they knew what they were doing, they wouldn't have boxes to tick). In that world, you need to have the checkboxes. However, no case has been made that Camellia is in that world. Camellia is not on Suite B, it isn't going to win any USG sales. So it doesn't need the checkbox, and we can revert back to our own judgement. The rough consensus in this group today (that I see) is that we are aiming at two markets at once, being the "small/mobile" and the "big/secure" sectors. Which means the biggest and the smallest: 128 + 256. iang PS: That rough consensus is what *I* see here today. Others might view it differently! Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DL7cTF086995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2008 14:07:38 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2DL7cO2086994; Thu, 13 Mar 2008 14:07:38 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DL7aFT086987 for ; Thu, 13 Mar 2008 14:07:37 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 6F7CD4A84; Thu, 13 Mar 2008 22:02:57 +0100 (CET) Date: Thu, 13 Mar 2008 22:02:56 +0100 To: Florian Weimer Cc: David Crick , Ian G , ietf-openpgp@imc.org Subject: Re: Closing the openpgp working group Message-ID: <20080313210256.GC18071@epointsystem.org> References: <47D53515.5050201@systemics.com> <117bad160803101012m52d22fdnd9aba86fc0ea33b1@mail.gmail.com> <87r6eebcav.fsf@mid.deneb.enyo.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline In-Reply-To: <87r6eebcav.fsf@mid.deneb.enyo.de> User-Agent: Mutt/1.5.9i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 13, 2008 at 09:26:32PM +0100, Florian Weimer wrote: >=20 > * David Crick: >=20 > >> How much enthusiasm is there for this? Enough to generate > >> some consensus? Is there a business case for a redesign? > > > > "doesn't use SHA1" sounds like a good V5 business case.... >=20 > Yes, some of us do check-list based security, and not having to rely on > SHA-1 is helpful in this area. And while we are at it, I would suggest to express V5 fingerprints (as well as key IDs) either in octal or in decimal. This is not a cryptography issue (*), but a usability issue on (typically mobile) devices with numeric-only keypads. As an added benefit, it would make the keyID ~ telephone number metaphor more sustainable. For such a decision, OpenPGP could earn the ethernal gratitude of the entire telecom industry. --=20 Daniel (*) But it certainly IS a security issue: usability is a crucial part of security, because security measures that are not usable are not going to be used. --vtzGhvizbBRQ85DL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iQDVAwUBR9mWgNlNfsjr6fBFAQI3TAX/fZTrQcX1WmS0TAE1+jYijJ/RyE5dplvd 6CbrkPm2HGX13JZw4xl2bEs0bsZtG84wb03LVBHWqGboJtABa+JfgqxBrZjEfyF1 jYaj+jH6fKQnMZvsx9u5rx9WDHKalrJ9Y/2I14jIgH8m7WAxpdJuCqb1M6vc9N12 rucrN5UBRqLTOo7TBYCvc+tUEihC2qljAsXM9p5RdRntC9eHO01HxXnsWYEIy+jn q10SBKET6yW4HV7OhA7XZe/j/KQwNiIT =CspB -----END PGP SIGNATURE----- --vtzGhvizbBRQ85DL-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DKTslN083903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2008 13:29:54 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2DKTsKI083902; Thu, 13 Mar 2008 13:29:54 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DKTqbX083869 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 13 Mar 2008 13:29:54 -0700 (MST) (envelope-from fw@deneb.enyo.de) Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1JZu0X-00060e-J8; Thu, 13 Mar 2008 21:26:33 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1JZu0W-0003gd-VQ; Thu, 13 Mar 2008 21:26:32 +0100 From: Florian Weimer To: "David Crick" Cc: "Ian G" , ietf-openpgp@imc.org Subject: Re: Closing the openpgp working group References: <47D53515.5050201@systemics.com> <117bad160803101012m52d22fdnd9aba86fc0ea33b1@mail.gmail.com> Date: Thu, 13 Mar 2008 21:26:32 +0100 In-Reply-To: <117bad160803101012m52d22fdnd9aba86fc0ea33b1@mail.gmail.com> (David Crick's message of "Mon, 10 Mar 2008 17:12:03 +0000") Message-ID: <87r6eebcav.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * David Crick: >> How much enthusiasm is there for this? Enough to generate >> some consensus? Is there a business case for a redesign? > > "doesn't use SHA1" sounds like a good V5 business case.... Yes, some of us do check-list based security, and not having to rely on SHA-1 is helpful in this area. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DJuIZ6081736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2008 12:56:18 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2DJuIUP081735; Thu, 13 Mar 2008 12:56:18 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DJuGVL081727 for ; Thu, 13 Mar 2008 12:56:17 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by wf-out-1314.google.com with SMTP id 28so3471666wff.28 for ; Thu, 13 Mar 2008 12:56:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=NlN5S8VQXf6qcT8j05xkIoPMmtrPOTnQrqZrX3jNOKQ=; b=HwAE5S13QNGVzK8JK3gIYkgGvXziYidhXD7pSosaYWJYrSq1ZQvLO4bOTQ/ywoDeODHKKvBa9MNIrjUm53iXBUs5TDceJDRPGLAUiAlCCII6876VfnV0GY9Gt/JbR7OhHw84XJBMG7mQnahPwLtJIeaO+QyykeE/U1i+qLOlyaE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qdJCmKwoTuwe9zH/YWdhoWrppztmxlrdE3PF54hcHW5A5l1YYh+YXR64LndqvSffyv24yfpUPM+AYEfIs0AzgXZTPNoIJjVMQ3/lvn3MylfUncqXF5cpNawgAdQq0d7hBMU2rnz5s+Na+llYP0vOELWLrtysZ0jEPT8CsUWNNZs= Received: by 10.143.162.8 with SMTP id p8mr4678037wfo.49.1205438175936; Thu, 13 Mar 2008 12:56:15 -0700 (PDT) Received: by 10.143.188.1 with HTTP; Thu, 13 Mar 2008 12:56:15 -0700 (PDT) Message-ID: <117bad160803131256j7137be61k69fc15080df04b6c@mail.gmail.com> Date: Thu, 13 Mar 2008 19:56:15 +0000 From: "David Crick" To: ietf-openpgp@imc.org, "David Shaw" Subject: Re: Ready for Camellia? (was: More on the closing of the OpenPGP WG) In-Reply-To: <20080313152341.GB1587@jabberwocky.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080311180200.GC4826@jabberwocky.com> <20080313152341.GB1587@jabberwocky.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I think we're ready for the final push on Camellia. All of the > suggested changes have been incorporated, and if folks could give it a > final read, I'd appreciate it: > http://www.ietf.org/internet-drafts/draft-ietf-openpgp-camellia-01.txt I had a look over this (-01) when you first posted it, and couldn't find fault. > I would particulary appreciate comments on the choice of 128 and > 256-bit keys (that is, lacking 192). I tend to agree with Jon that > 192 is neither here nor there, but I'm also a major fan of > consistency. If we're going to include 192 for the ECC work, then > it's odd to leave it out here. I suggested in my comments on the most recent (-07) ECC draft that we should explicitly deprecate AES-192 in ECC; I'd be tempted to say the same about Camellia-192, but I equally see the point of having an alternative to *each* of the three AES cipher lengths. So I think I'm abstaining on Camellia-192 - I'm not going to speicifically ask/vote for it to be included, but at the same time I won't protest if others wanted it in. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DFNp9X054411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2008 08:23:51 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2DFNpfc054410; Thu, 13 Mar 2008 08:23:51 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DFNoJK054386 for ; Thu, 13 Mar 2008 08:23:51 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.jabberwocky.com (c-75-69-177-157.hsd1.ma.comcast.net [75.69.177.157]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id m2DFNlN18648 for ; Thu, 13 Mar 2008 10:23:47 -0500 Received: from jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.1/8.14.1) with SMTP id m2DFNgSO029802 for ; Thu, 13 Mar 2008 11:23:42 -0400 Date: Thu, 13 Mar 2008 11:23:41 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Ready for Camellia? (was: More on the closing of the OpenPGP WG) Message-ID: <20080313152341.GB1587@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20080311180200.GC4826@jabberwocky.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.17 (2007-11-01) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Mar 12, 2008 at 01:29:49PM -0400, Derek Atkins wrote: > > David Shaw writes: > > [snip] > > I think that is just fine, and thanks for working this out. > > > > I have a minor process question though: I've done a couple of Camellia > > drafts as "draft-ietf-openpgp-camellia". Do I need to convert that to > > "draft-shaw-openpgp-camellia" (i.e. an individual submission) and > > re-submit? > > No, it can stay as 'draft-ietf-openpgp-'. No need to rename and > resubmit as an individual. Great, thanks. I think we're ready for the final push on Camellia. All of the suggested changes have been incorporated, and if folks could give it a final read, I'd appreciate it: http://www.ietf.org/internet-drafts/draft-ietf-openpgp-camellia-01.txt I would particulary appreciate comments on the choice of 128 and 256-bit keys (that is, lacking 192). I tend to agree with Jon that 192 is neither here nor there, but I'm also a major fan of consistency. If we're going to include 192 for the ECC work, then it's odd to leave it out here. David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2CHTtsJ092800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Mar 2008 10:29:55 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2CHTtBD092799; Wed, 12 Mar 2008 10:29:55 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2CHTs9H092776 for ; Wed, 12 Mar 2008 10:29:54 -0700 (MST) (envelope-from derek@ihtfp.com) Received: from pgpdev.ihtfp.org (unknown [130.129.82.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail.ihtfp.org (Postfix) with ESMTP id CA92FBD858B for ; Wed, 12 Mar 2008 13:29:50 -0400 (EDT) Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.1/8.14.1/Submit) id m2CHTnMa014583; Wed, 12 Mar 2008 13:29:49 -0400 To: ietf-openpgp@imc.org Subject: Re: More on the closing of the OpenPGP WG References: <20080311180200.GC4826@jabberwocky.com> From: Derek Atkins Date: Wed, 12 Mar 2008 13:29:49 -0400 In-Reply-To: <20080311180200.GC4826@jabberwocky.com> (David Shaw's message of "Tue\, 11 Mar 2008 14\:02\:00 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Shaw writes: [snip] > I think that is just fine, and thanks for working this out. > > I have a minor process question though: I've done a couple of Camellia > drafts as "draft-ietf-openpgp-camellia". Do I need to convert that to > "draft-shaw-openpgp-camellia" (i.e. an individual submission) and > re-submit? No, it can stay as 'draft-ietf-openpgp-'. No need to rename and resubmit as an individual. > David -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BI28TO034990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2008 11:02:08 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2BI28r6034989; Tue, 11 Mar 2008 11:02:08 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BI279f034983 for ; Tue, 11 Mar 2008 11:02:07 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.jabberwocky.com (c-75-69-177-157.hsd1.ma.comcast.net [75.69.177.157]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id m2BI25N02175 for ; Tue, 11 Mar 2008 13:02:05 -0500 Received: from jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.1/8.14.1) with SMTP id m2BI20su013204 for ; Tue, 11 Mar 2008 14:02:00 -0400 Date: Tue, 11 Mar 2008 14:02:00 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: More on the closing of the OpenPGP WG Message-ID: <20080311180200.GC4826@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.17 (2007-11-01) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Mar 10, 2008 at 02:21:46PM -0400, Derek Atkins wrote: > > Hi, > > I sat down with Sam, Tim, and Pasi yesterday to talk about this. > Basically, it's still possible to have a "standards track" document > without a working group. They still need to go through an IETF > Last Call but the AD can sponsor the draft (instead of having a > WG Group). So long as the drafts are not very contentious (which > MOST of our proposed work is), we can just continue to drafts > as individual submissions and an AD (Tim?) could sponsor that > once we have rough consensus on this list. [..] > Please let me know how you feel about this. I think that is just fine, and thanks for working this out. I have a minor process question though: I've done a couple of Camellia drafts as "draft-ietf-openpgp-camellia". Do I need to convert that to "draft-shaw-openpgp-camellia" (i.e. an individual submission) and re-submit? David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BE4fYU010479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2008 07:04:41 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2BE4f0q010478; Tue, 11 Mar 2008 07:04:41 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BE4eIj010472 for ; Tue, 11 Mar 2008 07:04:40 -0700 (MST) (envelope-from derek@ihtfp.com) Received: from pgpdev.ihtfp.org (unknown [130.129.82.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail.ihtfp.org (Postfix) with ESMTP id 65B90BD8464; Tue, 11 Mar 2008 10:04:40 -0400 (EDT) Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.1/8.14.1/Submit) id m2BE4dTd026123; Tue, 11 Mar 2008 10:04:39 -0400 To: Ian G Cc: ietf-openpgp@imc.org Subject: Re: More on the closing of the OpenPGP WG References: <47D5A817.8040901@systemics.com> From: Derek Atkins Date: Tue, 11 Mar 2008 10:04:39 -0400 In-Reply-To: <47D5A817.8040901@systemics.com> (Ian G.'s message of "Mon\, 10 Mar 2008 22\:28\:55 +0100") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ian G writes: > Derek Atkins wrote: >> Hi, >> >> I sat down with Sam, Tim, and Pasi yesterday to talk about this. >> Basically, it's still possible to have a "standards track" document >> without a working group. They still need to go through an IETF >> Last Call but the AD can sponsor the draft (instead of having a >> WG Group). So long as the drafts are not very contentious (which >> MOST of our proposed work is), we can just continue to drafts >> as individual submissions and an AD (Tim?) could sponsor that >> once we have rough consensus on this list. > > > That sounds fine to me. Is the only reason for a WG that we have to > have an open forum if there is contention? I don't think that's the only reason.. It's mainly provides a means to gauge consensus before it gets to the whole IETF, and provides a means to streamline the process so it's not all on the AD's shoulders. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BE1oo6010290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2008 07:01:50 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2BE1og7010289; Tue, 11 Mar 2008 07:01:50 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BE1mXp010282 for ; Tue, 11 Mar 2008 07:01:49 -0700 (MST) (envelope-from derek@ihtfp.com) Received: from pgpdev.ihtfp.org (unknown [130.129.82.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail.ihtfp.org (Postfix) with ESMTP id 2CACABD8464; Tue, 11 Mar 2008 10:01:48 -0400 (EDT) Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.1/8.14.1/Submit) id m2BE1lHO026085; Tue, 11 Mar 2008 10:01:47 -0400 To: Simon Josefsson Cc: ietf-openpgp@imc.org Subject: Re: More on the closing of the OpenPGP WG References: <8763vue2cg.fsf@mocca.josefsson.org> From: Derek Atkins Date: Tue, 11 Mar 2008 10:01:47 -0400 In-Reply-To: <8763vue2cg.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Mon\, 10 Mar 2008 21\:44\:15 +0100") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Simon Josefsson writes: > I'm curious whether we can get the OpenPGP header document published > without a WG or not. A few MUAs parses the header (Gnus, enigmail, > squirrelmail, if I understand correctly). I don't see why not. I don't think it would be very contentious. > /Simon -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BChqcc002171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2008 05:43:52 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2BChqDH002170; Tue, 11 Mar 2008 05:43:52 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BChn2W002161 for ; Tue, 11 Mar 2008 05:43:51 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by wf-out-1314.google.com with SMTP id 28so2270497wff.28 for ; Tue, 11 Mar 2008 05:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=IjHDbHAYnXkBqoJaHRBzBj7nIUzU8Ow6dLqS++ubGhM=; b=twMhhN8itL89rDYL7leCYBx2yLgmcTZCUJn/rZO/HcXEr9P+YfUSKyNJGBwGo1LOkBFuJguyP/q2lnPaq9aFMHwMXZnvYcX40FXo9w8iOl5wUzHV1uDaqIcLknN/5CCT/JffxyF+qojK1DbCKBk/1gK3Tkyili9SGLMBXqBKR3Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mPXbCXRcc4EPmjqYxJGMbNQFNfiElmwzkUZH8CxyLqhA5Rw5bmo+NfCJKnKTVhYzL6mNe7JOEFuiLrM8W1hy11wzhpUG8m/ssi4xZeVTXgGEiQB9KlUhiHFBisN46WiYJ+MbzgYZr0ArkS/ZLNyViJi4K1OlOC4bwl+yE07Btfs= Received: by 10.142.52.9 with SMTP id z9mr2500224wfz.134.1205239428563; Tue, 11 Mar 2008 05:43:48 -0700 (PDT) Received: by 10.143.188.1 with HTTP; Tue, 11 Mar 2008 05:43:48 -0700 (PDT) Message-ID: <117bad160803110543vf22ecd1y8fdb3ac0409912e7@mail.gmail.com> Date: Tue, 11 Mar 2008 12:43:48 +0000 From: "David Crick" To: "Andrey Jivsov" Subject: Re: ECC in OpenPGP proposal, second revision Cc: ietf-openpgp@imc.org In-Reply-To: <47D5A517.1010409@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <47CC7750.7080206@brainhub.org> <117bad160803031449p1efb03bao654561db48a5dbb2@mail.gmail.com> <47CD0451.9000503@brainhub.org> <117bad160803040655x3f393c7cuda72f361fbd119a4@mail.gmail.com> <47CE1648.6050402@brainhub.org> <117bad160803050356h54c755a4m2ada0ec7b53e8b0e@mail.gmail.com> <47D5A517.1010409@brainhub.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 11.1 I would like to see "MAY implement curve ID 2" explicitly stated (this *is* mentioned in section 12, but would like to see it here too) 11.3 says "The best remedy to this .. is to add .. AES-256" not sure about "best" - perhaps "simplest"? The reason being is that as AES128 is an ECC must, then this guarantees us *a* Suite B acceptable cipher, although - as you're trying to get at - having AES256 means that we'd cover *both* Suite B profiles. I'm not sure if I agree with the sentiment of "adding .. to .. each recipient's key" - doesn't quite sound right? (Maybe because it sounds like sender coercion, rather than a higher-level admin led policy?) 12 "It is generally advisable to list at the head of the preference list a symmetric algorithm of strength corresponding to the public key." Again, I see what you're trying to say, but as is noted elsewhere in the ECC doc, it's merely the intersection - it's up to the implementation to make its own decision thereafter (and so take advantage of any ordering information). I think section 12 also needs to explicitly deprecate AES-192, saying that it's not necessarily going to be fielded widely (bring in the fact that it is only a MAY here might help), isn't one of the Suite B ciphers, and that it's probably only suitable if for some reason you *really* need a 192-bit cipher: otherwise go for AES256 for security or -128 for performance. overall, though, I think we're getting there. On 3/10/08, Andrey Jivsov wrote: > > Here is the updated revision of the proposal that incorporates most > requested corrections that was possible to make without breaking or > severely affecting interoperability. > > http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-7.txt > > The same document in other formats: > http://brainhub.googlepages.com/pgp . > > Here is the partial list of changes: > > 1. Make curve ID 1 MUST, ID 3 SHOULD. > 2. MUST SHA2-256 and SHOULD implement SHA2-512 > 3. Note on Suite-B / OpenPGP incompatibility > 4. MUST support ECDSA and and ECDH > 5. MDC MUST, MUST use Iterated and Salted S2K > 6. Note on matching relative strength specified in section 12. > 7. Removed open reference to hashes (removed "or its successor"). > 8. SHOULD use stronger algorithm, while maintaining RFC4880 rules > > Thank you again for your comments. > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2AMGDBB000248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Mar 2008 15:16:13 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2AMGDxe000247; Mon, 10 Mar 2008 15:16:13 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from brainhub.org (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2AMGBS4000239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 10 Mar 2008 15:16:12 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from [63.251.255.221] (63-251-255-221.pgp.com [63.251.255.221] (may be forged)) by brainhub.org (8.14.2/8.14.1) with ESMTP id m2AMGBxc009418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 10 Mar 2008 15:16:11 -0700 Message-ID: <47D5A517.1010409@brainhub.org> Date: Mon, 10 Mar 2008 14:16:07 -0700 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: ECC in OpenPGP proposal, second revision References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <47CC7750.7080206@brainhub.org> <117bad160803031449p1efb03bao654561db48a5dbb2@mail.gmail.com> <47CD0451.9000503@brainhub.org> <117bad160803040655x3f393c7cuda72f361fbd119a4@mail.gmail.com> <47CE1648.6050402@brainhub.org> <117bad160803050356h54c755a4m2ada0ec7b53e8b0e@mail.gmail.com> In-Reply-To: <117bad160803050356h54c755a4m2ada0ec7b53e8b0e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Here is the updated revision of the proposal that incorporates most requested corrections that was possible to make without breaking or severely affecting interoperability. http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-7.txt The same document in other formats: http://brainhub.googlepages.com/pgp . Here is the partial list of changes: 1. Make curve ID 1 MUST, ID 3 SHOULD. 2. MUST SHA2-256 and SHOULD implement SHA2-512 3. Note on Suite-B / OpenPGP incompatibility 4. MUST support ECDSA and and ECDH 5. MDC MUST, MUST use Iterated and Salted S2K 6. Note on matching relative strength specified in section 12. 7. Removed open reference to hashes (removed "or its successor"). 8. SHOULD use stronger algorithm, while maintaining RFC4880 rules Thank you again for your comments. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2ALSxbg094953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Mar 2008 14:28:59 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2ALSx4q094952; Mon, 10 Mar 2008 14:28:59 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from goten.sonance.net (goten.sonance.net [88.198.58.135]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2ALSutp094933 for ; Mon, 10 Mar 2008 14:28:57 -0700 (MST) (envelope-from iang@systemics.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id D2CB357B17; Mon, 10 Mar 2008 22:28:55 +0100 (CET) Received: from goten.sonance.net ([127.0.0.1]) by localhost (goten.sonance.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tvwCq0pxEOK; Mon, 10 Mar 2008 22:28:55 +0100 (CET) Received: from zhukov.local (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id 8AB4F57AF8; Mon, 10 Mar 2008 22:28:55 +0100 (CET) Message-ID: <47D5A817.8040901@systemics.com> Date: Mon, 10 Mar 2008 22:28:55 +0100 From: Ian G User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Derek Atkins CC: ietf-openpgp@imc.org Subject: Re: More on the closing of the OpenPGP WG References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Derek Atkins wrote: > Hi, > > I sat down with Sam, Tim, and Pasi yesterday to talk about this. > Basically, it's still possible to have a "standards track" document > without a working group. They still need to go through an IETF > Last Call but the AD can sponsor the draft (instead of having a > WG Group). So long as the drafts are not very contentious (which > MOST of our proposed work is), we can just continue to drafts > as individual submissions and an AD (Tim?) could sponsor that > once we have rough consensus on this list. That sounds fine to me. Is the only reason for a WG that we have to have an open forum if there is contention? > This list can (and will) remain alive. So we can continue to discuss > Camillia, ECC, and Whirlpool on this list and then get documents > passed through the IETF/IESG Last Call process. > > If it turns out that we do have some contentious work (e.g. the > HTTP-PGP work), then we might need something more. Note that > we do not necessarily need a BOF in order to get a new working > group. It's not a requirement. So, if we DO have work that really > does require a WG, then it COULD be reformed. > > So, a summary: > > 1) This List will remain open and as active as we make it. > 2) We can continue to do OpenPGP work in the IETF > 3) We can continue to get I-Ds and Standards-track RFCs published > 4) We can get a new group constituted if we need to, but Tim assures > me that based on the proposed work we probably don't need to. > > Please let me know how you feel about this. I vote yes, let's go informal on this list. iang Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2AKibti089556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Mar 2008 13:44:37 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2AKiboC089555; Mon, 10 Mar 2008 13:44:37 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2AKiU5w089511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 10 Mar 2008 13:44:34 -0700 (MST) (envelope-from simon@josefsson.org) Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m2AKiFvj002620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Mar 2008 21:44:16 +0100 From: Simon Josefsson To: Derek Atkins Cc: ietf-openpgp@imc.org Subject: Re: More on the closing of the OpenPGP WG References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:080310:derek@ihtfp.com::Msdb6MhYcBOVUhfu:0RWH X-Hashcash: 1:22:080310:ietf-openpgp@imc.org::9wDSGaqsr7k9TVPd:6Dd1 Date: Mon, 10 Mar 2008 21:44:15 +0100 In-Reply-To: (Derek Atkins's message of "Mon, 10 Mar 2008 14:21:46 -0400") Message-ID: <8763vue2cg.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Derek Atkins writes: > Hi, > > I sat down with Sam, Tim, and Pasi yesterday to talk about this. > Basically, it's still possible to have a "standards track" document > without a working group. They still need to go through an IETF > Last Call but the AD can sponsor the draft (instead of having a > WG Group). So long as the drafts are not very contentious (which > MOST of our proposed work is), we can just continue to drafts > as individual submissions and an AD (Tim?) could sponsor that > once we have rough consensus on this list. > > This list can (and will) remain alive. So we can continue to discuss > Camillia, ECC, and Whirlpool on this list and then get documents > passed through the IETF/IESG Last Call process. > > If it turns out that we do have some contentious work (e.g. the > HTTP-PGP work), then we might need something more. Note that > we do not necessarily need a BOF in order to get a new working > group. It's not a requirement. So, if we DO have work that really > does require a WG, then it COULD be reformed. > > So, a summary: > > 1) This List will remain open and as active as we make it. > 2) We can continue to do OpenPGP work in the IETF > 3) We can continue to get I-Ds and Standards-track RFCs published > 4) We can get a new group constituted if we need to, but Tim assures > me that based on the proposed work we probably don't need to. > > Please let me know how you feel about this. I'm curious whether we can get the OpenPGP header document published without a WG or not. A few MUAs parses the header (Gnus, enigmail, squirrelmail, if I understand correctly). /Simon Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2AIM92U074242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Mar 2008 11:22:09 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2AIM9Lv074241; Mon, 10 Mar 2008 11:22:09 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2AIM7qg074230 for ; Mon, 10 Mar 2008 11:22:09 -0700 (MST) (envelope-from derek@ihtfp.com) Received: from pgpdev.ihtfp.org (72-255-2-16.client.stsn.net [72.255.2.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail.ihtfp.org (Postfix) with ESMTP id 66A70BD8589 for ; Mon, 10 Mar 2008 14:22:06 -0400 (EDT) Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.1/8.14.1/Submit) id m2AILko4015811; Mon, 10 Mar 2008 14:21:46 -0400 To: ietf-openpgp@imc.org Subject: More on the closing of the OpenPGP WG From: Derek Atkins Date: Mon, 10 Mar 2008 14:21:46 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, I sat down with Sam, Tim, and Pasi yesterday to talk about this. Basically, it's still possible to have a "standards track" document without a working group. They still need to go through an IETF Last Call but the AD can sponsor the draft (instead of having a WG Group). So long as the drafts are not very contentious (which MOST of our proposed work is), we can just continue to drafts as individual submissions and an AD (Tim?) could sponsor that once we have rough consensus on this list. This list can (and will) remain alive. So we can continue to discuss Camillia, ECC, and Whirlpool on this list and then get documents passed through the IETF/IESG Last Call process. If it turns out that we do have some contentious work (e.g. the HTTP-PGP work), then we might need something more. Note that we do not necessarily need a BOF in order to get a new working group. It's not a requirement. So, if we DO have work that really does require a WG, then it COULD be reformed. So, a summary: 1) This List will remain open and as active as we make it. 2) We can continue to do OpenPGP work in the IETF 3) We can continue to get I-Ds and Standards-track RFCs published 4) We can get a new group constituted if we need to, but Tim assures me that based on the proposed work we probably don't need to. Please let me know how you feel about this. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2AHC9XY066291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Mar 2008 10:12:09 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2AHC8wE066290; Mon, 10 Mar 2008 10:12:08 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.179]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2AHC5ST066271 for ; Mon, 10 Mar 2008 10:12:06 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by ik-out-1112.google.com with SMTP id c29so919884ika.2 for ; Mon, 10 Mar 2008 10:12:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Dpb9oIyoLQ49bQ3DU1tfswaNLSrpiKoKv1TNqWY2PCM=; b=xzWRXY5UoDZDVIjHpvZ/PDSn+CJsqFvaQEzEPt4V7wRAYWfvrDdUsL/JZbCUSn4rewcVVwNsVh72hWP5U2Nq79ktErpQh3qZr2HN1cGfTUb0dkRBwQRO5AlKitw4om35Ljug30uNwmrLp6xYjGXTrZJzTM7/abcIFKTpTV/cAK4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=eyXzUGoZJrLXT/W/OohrFu5HMGIxHVzBYsls8dGtCwl68r6mCXMcU7n5qse0c0du0Tfn1g6ihjy4Qy+TnmPowMQ/W4gl33R3MqM8SCRrgNkAoP6UOa/Uf1Q94Z/P1sCcbGzkLmETjNTAn47rbKdR0i82ak8V5IQUoTSboNM6pqs= Received: by 10.142.128.6 with SMTP id a6mr1947712wfd.138.1205169123301; Mon, 10 Mar 2008 10:12:03 -0700 (PDT) Received: by 10.143.188.1 with HTTP; Mon, 10 Mar 2008 10:12:03 -0700 (PDT) Message-ID: <117bad160803101012m52d22fdnd9aba86fc0ea33b1@mail.gmail.com> Date: Mon, 10 Mar 2008 17:12:03 +0000 From: "David Crick" To: "Ian G" Subject: Re: Closing the openpgp working group Cc: ietf-openpgp@imc.org In-Reply-To: <47D53515.5050201@systemics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47D53515.5050201@systemics.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 3/10/08, Ian G wrote: > > Sam Hartman wrote: > > > > Hi, folks. Back in January Derek started a thread on a new charter. > > That never really came to any conclusion. I had given Derek a > > deadline to produce a charter that is well past. So, I'm going to > > close the openpgp working group. > > > > If people ever do get a concrete proposal together, please don't > > hesitate to contact the security ADs at the time this happens and > > propose a new working group. > > > If this has indeed happened, I guess the next step is > creating enough momentum for V5 key structure. > > How much enthusiasm is there for this? Enough to generate > some consensus? Is there a business case for a redesign? "doesn't use SHA1" sounds like a good V5 business case.... > How much are groups going to invest into OpenPGP in the > future, and how much would they save if a redesign cleaned > things up? > > If the answer is in the positive, I'd suggest putting in > place a wiki somewhere. We need some way of working on the > various parts in parallel. > > iang Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2ADIIa7041242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Mar 2008 06:18:18 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2ADIInT041241; Mon, 10 Mar 2008 06:18:18 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from goten.sonance.net (goten.sonance.net [88.198.58.135]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2ADIFfD041232 for ; Mon, 10 Mar 2008 06:18:17 -0700 (MST) (envelope-from iang@systemics.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id 7888D57B17; Mon, 10 Mar 2008 14:18:14 +0100 (CET) Received: from goten.sonance.net ([127.0.0.1]) by localhost (goten.sonance.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bv4hSXOCRrwU; Mon, 10 Mar 2008 14:18:14 +0100 (CET) Received: from zhukov.local (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id 1FC3D57B0F; Mon, 10 Mar 2008 14:18:14 +0100 (CET) Message-ID: <47D53515.5050201@systemics.com> Date: Mon, 10 Mar 2008 14:18:13 +0100 From: Ian G User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: Sam Hartman , tim.polk@nist.gov, pasi.eronen@nokia.com Subject: Re: Closing the openpgp working group References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sam Hartman wrote: > > Hi, folks. Back in January Derek started a thread on a new charter. > That never really came to any conclusion. I had given Derek a > deadline to produce a charter that is well past. So, I'm going to > close the openpgp working group. > > If people ever do get a concrete proposal together, please don't > hesitate to contact the security ADs at the time this happens and > propose a new working group. If this has indeed happened, I guess the next step is creating enough momentum for V5 key structure. How much enthusiasm is there for this? Enough to generate some consensus? Is there a business case for a redesign? How much are groups going to invest into OpenPGP in the future, and how much would they save if a redesign cleaned things up? If the answer is in the positive, I'd suggest putting in place a wiki somewhere. We need some way of working on the various parts in parallel. iang Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m26MWnCJ085441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Mar 2008 15:32:49 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m26MWnYi085440; Thu, 6 Mar 2008 15:32:49 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m26MWnOO085434 for ; Thu, 6 Mar 2008 15:32:49 -0700 (MST) (envelope-from buanzo@buanzo.com.ar) Received: by an-out-0708.google.com with SMTP id c23so35762anc.44 for ; Thu, 06 Mar 2008 14:32:49 -0800 (PST) Received: by 10.100.95.19 with SMTP id s19mr952750anb.9.1204842768594; Thu, 06 Mar 2008 14:32:48 -0800 (PST) Received: from ?10.10.0.4? ( [201.235.164.113]) by mx.google.com with ESMTPS id c2sm5492639ana.4.2008.03.06.14.32.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 06 Mar 2008 14:32:46 -0800 (PST) Message-ID: <47D07108.4090804@buanzo.com.ar> Date: Thu, 06 Mar 2008 20:32:40 -0200 From: "Arturo 'Buanzo' Busleiman" Organization: GNU/Buanzo User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: Sam Hartman CC: ietf-openpgp@imc.org, tim.polk@nist.gov, pasi.eronen@nokia.com Subject: Re: Closing the openpgp working group References: <47D067D4.1090907@buanzo.com.ar> In-Reply-To: X-Enigmail-Version: 0.95.6 OpenPGP: id=6857704D Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Sam Hartman wrote: | OpenPGP for HTTP is out of scope in both the HTTP and OpenPGP charters | as they existed before I closed the OpenPGP working group. You would | need a new group either way. Sounds like good advice. Thanks Sam. PS: Totally OFFTOPIC. I'll arrive to Las Vegas tomorrow Friday 7th, 6pm (Las V. time). Anyone attending 2600 Meeting there PLEASE contact me. Or if any of you is into security, I'll also stay in charlotte March 10-16. - -- Arturo "Buanzo" Busleiman Reliable inter-continental Mail Relay Service - Ask me! Independent Security Consultant - SANS - OISSG http://www.buanzo.com.ar/pro/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH0HEIAlpOsGhXcE0RCs0TAJ9BCjDptdefGOogHePaHrP+uWAFYACdEIFG ZPTD7ngCYpusX5tEd+cGQow= =/V0g -----END PGP SIGNATURE----- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m26MTpxh085241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Mar 2008 15:29:51 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m26MTpMU085240; Thu, 6 Mar 2008 15:29:51 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from carter-zimmerman.suchdamage.org (STRATTON-THREE-SEVENTY-NINE.MIT.EDU [18.187.6.124]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m26MTov0085233 for ; Thu, 6 Mar 2008 15:29:51 -0700 (MST) (envelope-from hartmans@mit.edu) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E69CD476B; Thu, 6 Mar 2008 17:29:49 -0500 (EST) From: Sam Hartman To: "Arturo 'Buanzo' Busleiman" Cc: ietf-openpgp@imc.org, tim.polk@nist.gov, pasi.eronen@nokia.com Subject: Re: Closing the openpgp working group References: <47D067D4.1090907@buanzo.com.ar> Date: Thu, 06 Mar 2008 17:29:49 -0500 In-Reply-To: <47D067D4.1090907@buanzo.com.ar> (Arturo Busleiman's message of "Thu, 06 Mar 2008 19:53:24 -0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >>>>> "Arturo" == Arturo 'Buanzo' Busleiman writes: Arturo> Sam Hartman wrote: Arturo> | If people ever do get a concrete proposal together, please don't Arturo> | hesitate to contact the security ADs at the time this happens and Arturo> | propose a new working group. Arturo> Ouch. Well, I guess the HTTP Working Group would be the ideal place for me to continue my Arturo> involvement with the IETF regarding OpenPGP for HTTP? OpenPGP for HTTP is out of scope in both the HTTP and OpenPGP charters as they existed before I closed the OpenPGP working group. You would need a new group either way. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m26MLY90084542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Mar 2008 15:21:35 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m26MLYgo084541; Thu, 6 Mar 2008 15:21:34 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m26MLXC7084531 for ; Thu, 6 Mar 2008 15:21:34 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.jabberwocky.com (c-75-69-177-157.hsd1.ma.comcast.net [75.69.177.157]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id m26MLVu26795 for ; Thu, 6 Mar 2008 17:21:32 -0500 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.1/8.14.1) with ESMTP id m26MLRH9007985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Mar 2008 17:21:27 -0500 Received: from grover.jabberwocky.com (localhost.localdomain [127.0.0.1]) by grover.jabberwocky.com (8.14.1/8.13.8) with ESMTP id m26MLRT9030926 for ; Thu, 6 Mar 2008 17:21:27 -0500 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.14.1/8.14.1/Submit) id m26MLQck030925 for ietf-openpgp@imc.org; Thu, 6 Mar 2008 17:21:26 -0500 Date: Thu, 6 Mar 2008 17:21:26 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Closing the openpgp working group Message-ID: <20080306222126.GA30886@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <47D067D4.1090907@buanzo.com.ar> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47D067D4.1090907@buanzo.com.ar> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.15 (2007-05-20) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 06, 2008 at 07:53:24PM -0200, Arturo 'Buanzo' Busleiman wrote: > > Sam Hartman wrote: > | If people ever do get a concrete proposal together, please don't > | hesitate to contact the security ADs at the time this happens and > | propose a new working group. > > Ouch. Well, I guess the HTTP Working Group would be the ideal place for me to continue my > involvement with the IETF regarding OpenPGP for HTTP? This doesn't mean the mailing list is going away. Just that the WG status is. If and when we are ready, we can try and charter a new group. We have three things that are being discussed right now (ECC, Camellia and Whirlpool). I'd say the Camellia draft is basically ready to go once we handle the charter. David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m26MAH8K082895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Mar 2008 15:10:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m26MAHJT082894; Thu, 6 Mar 2008 15:10:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m26MAGiJ082872 for ; Thu, 6 Mar 2008 15:10:17 -0700 (MST) (envelope-from derek@ihtfp.com) Received: from pgpdev.ihtfp.org (c-76-109-52-251.hsd1.fl.comcast.net [76.109.52.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail.ihtfp.org (Postfix) with ESMTP id BB8FABD8588; Thu, 6 Mar 2008 17:10:10 -0500 (EST) Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.1/8.14.1/Submit) id m26MA670006033; Thu, 6 Mar 2008 17:10:06 -0500 To: Sam Hartman Cc: ietf-openpgp@imc.org, tim.polk@nist.gov, pasi.eronen@nokia.com Subject: Re: Closing the openpgp working group References: From: Derek Atkins Date: Thu, 06 Mar 2008 17:10:05 -0500 In-Reply-To: (Sam Hartman's message of "Thu\, 06 Mar 2008 16\:30\:31 -0500") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sam, Sam Hartman writes: > Hi, folks. Back in January Derek started a thread on a new charter. > That never really came to any conclusion. I had given Derek a > deadline to produce a charter that is well past. So, I'm going to > close the openpgp working group. > > If people ever do get a concrete proposal together, please don't > hesitate to contact the security ADs at the time this happens and > propose a new working group. The fact that it didn't come to conclusion is just a result of my not driving the process enough. There's clearly work that people want to get done, including active development in: ECC v5 Keys OpenPGP in TLS Indeed, we've had lots of discussion in the past couple weeks. Sam, you did give me until the end of January and it's now March. Clearly I'm just not on the ball here, but I do think there's enough work to warrant keeping the group open. Can I get one more week to come up with a proposed charter? -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m26LrgYd081670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Mar 2008 14:53:42 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m26LrgWD081669; Thu, 6 Mar 2008 14:53:42 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m26LreiY081662 for ; Thu, 6 Mar 2008 14:53:41 -0700 (MST) (envelope-from buanzo@buanzo.com.ar) Received: by an-out-0708.google.com with SMTP id c23so26706anc.44 for ; Thu, 06 Mar 2008 13:53:32 -0800 (PST) Received: by 10.100.92.9 with SMTP id p9mr827996anb.22.1204840412549; Thu, 06 Mar 2008 13:53:32 -0800 (PST) Received: from ?10.10.0.4? ( [201.235.164.113]) by mx.google.com with ESMTPS id c28sm6236258anc.32.2008.03.06.13.53.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 06 Mar 2008 13:53:30 -0800 (PST) Message-ID: <47D067D4.1090907@buanzo.com.ar> Date: Thu, 06 Mar 2008 19:53:24 -0200 From: "Arturo 'Buanzo' Busleiman" Organization: GNU/Buanzo User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: Sam Hartman CC: ietf-openpgp@imc.org, tim.polk@nist.gov, pasi.eronen@nokia.com Subject: Re: Closing the openpgp working group References: In-Reply-To: X-Enigmail-Version: 0.95.6 OpenPGP: id=6857704D Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Sam Hartman wrote: | If people ever do get a concrete proposal together, please don't | hesitate to contact the security ADs at the time this happens and | propose a new working group. Ouch. Well, I guess the HTTP Working Group would be the ideal place for me to continue my involvement with the IETF regarding OpenPGP for HTTP? - -- Arturo "Buanzo" Busleiman Reliable inter-continental Mail Relay Service - Ask me! Independent Security Consultant - SANS - OISSG http://www.buanzo.com.ar/pro/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH0GfUAlpOsGhXcE0RCg5EAJ9EbztkOEhxJfvJsQt3kjg5U8t7JgCcDtvw Dy7ZhDa0xiYDqqW5ww3F9xA= =ksNA -----END PGP SIGNATURE----- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m26LUXYp079871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Mar 2008 14:30:33 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m26LUXU3079870; Thu, 6 Mar 2008 14:30:33 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from carter-zimmerman.suchdamage.org (dhcp-18-188-10-61.dyn.mit.edu [18.188.10.61]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m26LUWYi079863 for ; Thu, 6 Mar 2008 14:30:33 -0700 (MST) (envelope-from hartmans@mit.edu) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 21527476B; Thu, 6 Mar 2008 16:30:31 -0500 (EST) From: Sam Hartman To: ietf-openpgp@imc.org Cc: tim.polk@nist.gov, pasi.eronen@nokia.com Subject: Closing the openpgp working group Date: Thu, 06 Mar 2008 16:30:31 -0500 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, folks. Back in January Derek started a thread on a new charter. That never really came to any conclusion. I had given Derek a deadline to produce a charter that is well past. So, I'm going to close the openpgp working group. If people ever do get a concrete proposal together, please don't hesitate to contact the security ADs at the time this happens and propose a new working group. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m268XJHt086610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Mar 2008 01:33:19 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m268XJfw086609; Thu, 6 Mar 2008 01:33:19 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m268XI4m086599 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 6 Mar 2008 01:33:19 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from localhost.localdomain (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by mail.cyberonic.com (8.12.8/8.12.8) with ESMTP id m268Zko5015118 for ; Thu, 6 Mar 2008 03:35:46 -0500 Message-ID: <47CFAC4D.60309@brainhub.org> Date: Thu, 06 Mar 2008 00:33:17 -0800 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: ECC in OpenPGP proposal: how to use ECDH X-Priority: 5 (Lowest) References: <47CFAB50.2040306@brainhub.org> In-Reply-To: <47CFAB50.2040306@brainhub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Erratum 1: nist_aes_wrap is shown in http://brainhub.googlepages.com/aeswrap-RFC3394.c.html, while the algorithm is defined in RFC 3394. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m268T81M085866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Mar 2008 01:29:08 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m268T8K5085865; Thu, 6 Mar 2008 01:29:08 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m268T664085855 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 6 Mar 2008 01:29:08 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from localhost.localdomain (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by mail.cyberonic.com (8.12.8/8.12.8) with ESMTP id m268VYo5014243 for ; Thu, 6 Mar 2008 03:31:35 -0500 Message-ID: <47CFAB50.2040306@brainhub.org> Date: Thu, 06 Mar 2008 00:29:04 -0800 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: ECC in OpenPGP proposal: how to use ECDH Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Responding to request by David, I will describe in more details what is happening during ECDH encryption, the only encryption scheme allowed in the spec. ( Please check for errata before implementing anything from this. ) High-level overview of the steps: 1) Generate shared EC point 2) Generate KEK from it 3) use KEK with RFC3394 to encrypt symmetric key. Step 1. ECDH public key contains s*G, which is a curve point (think of it as g^s in modp notation). Step 2. Sender generates its secret v and calculates v*G. Then the point S =v*s*G is the initial shared secret. Step 3. Sender arrives at common symmetric message encryption key algorithm for the recipients. The algorithm is encoded with a byte from RFC4880, for example, for AES -128 use 7. Sender generates random string of appropriate length for the key and appends it to the algorithm ID, for example: 07 R1 R2 R3 R4 R5 R6 R7 R8 R9 Ra Rb Rc Rd Re Rf R10 where R* is a random byte. Step 4. Sender appends 16 byte checksum to this string: 07 R1 R2 R3 R4 R5 R6 R7 R8 R9 Ra Rb Rc Rd Re Rf R10 C0 C1 (This is what passed in RFC4880 to PKCS#1 padding.) Step 5. Set KDF parameter like this: Param = 01 16 01 0a 09 "AnonymousSender" F0 F1 F2 ... F14 This setting assumes recipient curve ID 1, IANA assignment of value 22=0x16 for ECDH, SHA512 for KDF (ID 10=0xa), AES-256 for AESWrap. F* is the 20 byte fingerprint of the recipient. There are always 40 bytes here. Step 6. Pass 40 byte KDF parameter from step 5 and point S from step 2 to KDF in section 6 http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-6.html#toc5 . KDF works in counter-mode-style and outputs KEK. Stop when sufficient number of bits for selected AESWrap algorithm is generated (AES-256 in our example, so we need 32 bytes). * Using KEK from step 6 and string in step 4, call nist_aes_wrap, defined in http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-6.html. nist_aes_wrap( c, kPGPCipherAlgorithm_AES256, KEK, 32, {07 R1 R2 R3 R4 R5 R6 R7 R8 R9 Ra Rb Rc Rd Re Rf R10 C0 C1}, 19, out, 32, &actual_size ); AES-128, AES-256, AES-256, SHA2-256, SHA2-384, and SHA2-512 are the only algorithms allowed with AESWrap and KDF. This restriction has no relation to message encryption symmetric key or hash used for message signing. The following is not mentioned in the spec, but I think the sender should start from the AES-256 and SHA-512 and move down to choose weaker algorithms if recipient has excluded these algorithms from its key preferences for encryption or hash list. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m25BupVm070583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Mar 2008 04:56:51 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m25BupDx070582; Wed, 5 Mar 2008 04:56:51 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m25Buo77070570 for ; Wed, 5 Mar 2008 04:56:51 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by wf-out-1314.google.com with SMTP id 28so1578000wff.28 for ; Wed, 05 Mar 2008 03:56:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Et6w6OQMvW3sK9z7Y7bjlXtzp5fAAspQs3tiw5WdsF4=; b=OZOCEyyUJNMoIwcFzqylwvHQDSK8WidR+uJgSG6mcMBpEBsccEg0/MFrelCqyqZt1z4GckFDutzLtlcE8joxkL1QmhHAHRy7KKcnvMcIgbTsbRo8fcx9W5sGRcJzfEjFYkyqlbDDhRRtlV4eW+84kpIyz8H/16CfCWxUhx5f8Bs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RXeHVcbkQmtDqpgvxsGvI9IJZrnxnhWhUJRvs9HxAa0krrzTely6I1+ewKPm3fxzbuLckwoCXXQSNjMQ18TWY6UgAnbHiOXcick3WJExbTbZSOhCtuZLFmp70cfTx31jmWAvqijBr5IC4ipEFVmF7yfQyT7ziA2v6i1bbT7snWg= Received: by 10.143.162.8 with SMTP id p8mr745004wfo.63.1204718209362; Wed, 05 Mar 2008 03:56:49 -0800 (PST) Received: by 10.143.172.3 with HTTP; Wed, 5 Mar 2008 03:56:48 -0800 (PST) Message-ID: <117bad160803050356h54c755a4m2ada0ec7b53e8b0e@mail.gmail.com> Date: Wed, 5 Mar 2008 11:56:48 +0000 From: "David Crick" To: "Andrey Jivsov" Subject: Re: ECC in OpenPGP proposal Cc: ietf-openpgp@imc.org In-Reply-To: <47CE1648.6050402@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <47CC7750.7080206@brainhub.org> <117bad160803031449p1efb03bao654561db48a5dbb2@mail.gmail.com> <47CD0451.9000503@brainhub.org> <117bad160803040655x3f393c7cuda72f361fbd119a4@mail.gmail.com> <47CE1648.6050402@brainhub.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 3/5/08, Andrey Jivsov wrote: > > this sounds like what what we've got to so far, although I note > > that this makes the [AES256-]SHA384-384ECC an *implicit* MAY > > rather than *specifically* mentioning SHA384 and ECC384 as > > MAYs. > > > > So, should we *explicitly* mention them? > > Where do you see a benefit of explicit MAY? 384 ECC is defined in this > spec, thus is MAY. SHA382 is MAY from RFC 4880 and AES256 is SHOULD in > this spec. readability and understandability (of our intentions/recommendations) > Can using MAY once create questions as to why other combinations are not > MAYs? possibly, but the reverse it more true: it draws attention to the fact that *this* is something you should *consider*. > > (also, an aside regarding repetition of a point I've previous made: > > the (e.g.) keywrapping text in -pre6 only talks about AES; this > > needs to be made more general, referring instead to keylengths.) > > > > > You are right, there is a dependency on AES in this spec. It is > currently required in AESWrap key wrapping method. I realize that you > may have interpreted this differently. I prefer we fix AES with AESWrap > method, and this is how the -pre6 is written. The argument about > multiple recipients doesn't apply here, but relative strength does. I > suppose that even embedded devices can use AES-256 as KEK for key > wrapping and AES-128 for message encryption (or any other algorithm for > latter) , because the performance of AESWrap is not an issue on up to 48 > bytes (the availability in hardware probably is). In any case, any of 3 > AES variants are allowed in current proposal for AESWrap, plus, we have > AES-256 as SHOULD. > > For example, http://www.ellipticsemi.com/products-clp-34.php shows > hardware implementation, which is hardwired to AES 128 or 256. > > (Just to be clear, nothing in this section applies to the choice of > algorithm for symmetric message encryption key.) re the just to be clear, I think this is what has partly muddied the water. But / so (for my sanity ;)), could you please explain how one uses a 3DES session key with ECC D-H? > >> The choice of symmetric algorithm is governed by key > >> preferences of (multiple) recipients. We shouldn't disregard preference > >> list and prefer AES-256 (even for ECC keys). > >> > > > > 4880 section 13.2 says this: > > > > An implementation MUST NOT use a symmetric algorithm that is not in > > the recipient's preference list. When encrypting to more than one > > recipient, the implementation finds a suitable algorithm by taking > > the intersection of the preferences of the recipients. Note that the > > MUST-implement algorithm, TripleDES, ensures that the intersection is > > not null. *The implementation may use any mechanism to pick an > > algorithm in the intersection.* > > > > I suggest we *use* this freedom by (but!) tightening it in OpenPGP ECC > > applications. So, our ECC document would have something like: > > > > Having obtained an intersection of symmetric algorithm preferences, > > implementations SHOULD attempt to match symmetric algorithm size > > with public key size. > > I note that this issue is orthogonal to this spec, i.e. it applies to > RFC 4880 as well. However, if there is a consensus, we can recommend > this. One justification for "why now" is, practically speaking, ECC > allows balanced strength while RFC 4880 doesn't. However, I would try to > stay within RFC4880. > > The issue of tightening is similar to other restrictions I put in > section 12: MDC: SHOULD, S2K: iterated salted, SHA-1: MUST NOT. Ian > suggested MDC/S2K to be MUST. > > > > [*Personally*, I'd like to continue: > > ", favouring longer lengths where possible."] > > While we should not deprive implementations the allowed method to > advertise prioritized preferences, I think we there is a room for > improvement in "grey areas". For example, > > * Two recipient keys have following ordered prefs.: {AES128, AES256} and > {AES256, AES128}. > * RFC 4880 allows either of these sets to be the ordered intersection. > > In this case we can "tighten" as you suggested. great. Again, I'd like to see "clear" wording in the ECC doc to indicate this; otherwise implementers may either miss this fact or be left scratching their heads wondering how to handle it. > Many of these issues are in the realm of key managing software. If user > is adding single AES128 preference to ECDH 521, the software can warn her. > > > > The following table provides current equivalent recommendations > > (SP800-57). Note TripleDES is considered to have 112-bit security. > > > > Asymmetric | Hash | Symmetric | Elliptic > > key size | size | key size | curve key > > (RSA + D-H) | | | size > > ------------+--------+-------------------------- > > 1024 160 80 160 > > 2048 224 112 224 > > 3072 256 128 256 > > 7680 384 192 384 > > 15360 512 256 521 > > > > [the columns should probably be in a "better" order, this was > > just copied from 4800 with ECC then added on the end] just for *me* to make clear :), I was suggesting we add this table into the spec, just as 4880 does in its. As you've said, this key management issue becomes more of an issue as we now have the ability (or the requirement, with Suite B) to match lengths. Again, including this, but spelled out, makes it a lot clearer. > I will integrate feedback from everybody into the next revision. > Thank you. I think the ECC spec fits somewhere between 4880 and the Camellia draft in terms of complexity of detail that is needed to be conveyed. The Camellia draft is wonderfully short, since all it needs to say is "this is an alternative cipher you can use. in limited, certain situations using Camellia can cause interoperability issues." The ECC doc, however, has to spell out why and when using this new public key system would be beneficial, possible ways of using it, the most suitable ways of using it, and some more complex interoperability issues. I therefore feel we need to veer towards using *more* wording to justify and explain usage of OpenPGP-ECC, rather than (necessarily) aiming for the "less is more" approach that may be more preferable in general. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m25BcONT068705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Mar 2008 04:38:24 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m25BcO1J068704; Wed, 5 Mar 2008 04:38:24 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.190]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m25BcM8o068695 for ; Wed, 5 Mar 2008 04:38:24 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by gv-out-0910.google.com with SMTP id l14so997540gvf.13 for ; Wed, 05 Mar 2008 03:38:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=8W2ejrpDLC9RBpzLa1lecUZs51wFLYrTs4RHAHT4N4A=; b=iDwVOCyF1sn0uwVjn0teww/t72un0aP6pGfBPL3ZNQkl92eK2gVVGC109wAdhJJ8JxGjGr5EcYmERtnEcUFgmd4DiVqZbmd40f61xVdFSXoST4C75i4vriiN6YsBsatdpVqU0rQQMhDi7OL8JZQ5zT22Q+493nIxvhI9MmuWbF4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CgaoUmjg5eIcNAoIb0i63uq9jwymADo1stDQvHqbcsfmo9GFGQ0u/NKCr0UB3l0rW4NmeTEKU2qBLlITDCBKiSMgrkiJWNP5HXwOB2tvPCJzuXnC96xtA9g6DbTpASJNjLnm0rioZvntZDYVQDOFrJx+kEp8JIUtFCtQXtsDUhE= Received: by 10.142.143.7 with SMTP id q7mr754430wfd.3.1204717099905; Wed, 05 Mar 2008 03:38:19 -0800 (PST) Received: by 10.143.172.3 with HTTP; Wed, 5 Mar 2008 03:38:19 -0800 (PST) Message-ID: <117bad160803050338u72ea221i68b1c168ecf39035@mail.gmail.com> Date: Wed, 5 Mar 2008 11:38:19 +0000 From: "David Crick" To: "Ian G" Subject: Re: ECC in OpenPGP proposal Cc: "Andrey Jivsov" , ietf-openpgp@imc.org In-Reply-To: <47CE78BD.3000300@systemics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <47CC7750.7080206@brainhub.org> <117bad160803031449p1efb03bao654561db48a5dbb2@mail.gmail.com> <47CD0451.9000503@brainhub.org> <117bad160803040655x3f393c7cuda72f361fbd119a4@mail.gmail.com> <47CE1648.6050402@brainhub.org> <47CE78BD.3000300@systemics.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 3/5/08, Ian G wrote: > Andrey Jivsov wrote: > > My thoughts on MAY were that since this spec is MAY in relation to > > RFC4880, the explicit MAYs on defined or otherwise referenced algorithms > > are redundant. If we define a curve and don't list it as SHOULD or MUST, > > I assumed that it follows that it is MAY. > > > > To me as an implementor I want to see what the defined sets > are. Commentary or definition on curves may be all very > interesting, but I would want to see the MAY set to > understand what the recommendation was. from my querying of it, I hope it is clear that I would also like to specifically see the (e.g.) ECC384 curve stated as a MAY. And, just to justify this (and to show why 4880 is so readable): 9.1. Public-Key Algorithms Implementations MUST implement ... SHOULD implement ... * Implementations MAY implement any other algorithm.* 9.2. Symmetric-Key Algorithms Implementations MUST ... Implementations SHOULD ... ... need to ... *Implementations MAY implement any other algorithm.* 9.3. Compression Algorithms Implementations MUST ... Implementations SHOULD ... ... *Implementations MAY implement any other algorithm.* 9.4. Hash Algorithms Implementations MUST implement SHA-1. *Implementations MAY implement other algorithms.* > I'd assume other > other implementors were also thinking around those MAYs. If > the question came up, I'd want the team leader to say > "implement only MAYs." She doesn't want them to go beyond > the clear compatibility consensus. > > The code implementations take on a life of their own ... any > signals to reduce confusion and tie the implementations > within some distance of a common goal are good. A strong > MAY set is clearly something we should do if we are looking > for a complete implementation. In code world, nobody much > has time to do anything that doesn't lead to a clear > business imperative. > > As a generalism, the people who implement the code know a > little crypto, but not a lot. They can't see very far. > They are employed for their good software skills, their > ability to turn specs into live code. > > What to the crypto / institutional world may be elegence is > simply code to these guys. What might be a delicate path > through conflicting requirements is a nightmare to the > coders, they just don't know what was intended, and have > only each other to figure it out. > > (Just another reason why agility is a nice idea in the > crypto tea room, but not robust in reality.) > > iang Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m25Af6R0063003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Mar 2008 03:41:06 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m25Af6tw063002; Wed, 5 Mar 2008 03:41:06 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from goten.sonance.net (goten.sonance.net [88.198.58.135]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m25Af43Y062991 for ; Wed, 5 Mar 2008 03:41:06 -0700 (MST) (envelope-from iang@systemics.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id 55A9057B0F; Wed, 5 Mar 2008 11:41:01 +0100 (CET) Received: from goten.sonance.net ([127.0.0.1]) by localhost (goten.sonance.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsDmlkpjrfZk; Wed, 5 Mar 2008 11:41:01 +0100 (CET) Received: from zhukov.local (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id DB13A57B0B; Wed, 5 Mar 2008 11:41:00 +0100 (CET) Message-ID: <47CE78BD.3000300@systemics.com> Date: Wed, 05 Mar 2008 11:41:01 +0100 From: Ian G User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Andrey Jivsov CC: ietf-openpgp@imc.org, David Crick Subject: Re: ECC in OpenPGP proposal References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <47CC7750.7080206@brainhub.org> <117bad160803031449p1efb03bao654561db48a5dbb2@mail.gmail.com> <47CD0451.9000503@brainhub.org> <117bad160803040655x3f393c7cuda72f361fbd119a4@mail.gmail.com> <47CE1648.6050402@brainhub.org> In-Reply-To: <47CE1648.6050402@brainhub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Andrey Jivsov wrote: > My thoughts on MAY were that since this spec is MAY in relation to > RFC4880, the explicit MAYs on defined or otherwise referenced algorithms > are redundant. If we define a curve and don't list it as SHOULD or MUST, > I assumed that it follows that it is MAY. To me as an implementor I want to see what the defined sets are. Commentary or definition on curves may be all very interesting, but I would want to see the MAY set to understand what the recommendation was. I'd assume other other implementors were also thinking around those MAYs. If the question came up, I'd want the team leader to say "implement only MAYs." She doesn't want them to go beyond the clear compatibility consensus. The code implementations take on a life of their own ... any signals to reduce confusion and tie the implementations within some distance of a common goal are good. A strong MAY set is clearly something we should do if we are looking for a complete implementation. In code world, nobody much has time to do anything that doesn't lead to a clear business imperative. As a generalism, the people who implement the code know a little crypto, but not a lot. They can't see very far. They are employed for their good software skills, their ability to turn specs into live code. What to the crypto / institutional world may be elegence is simply code to these guys. What might be a delicate path through conflicting requirements is a nightmare to the coders, they just don't know what was intended, and have only each other to figure it out. (Just another reason why agility is a nice idea in the crypto tea room, but not robust in reality.) iang Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m253f7FT018574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 20:41:07 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m253f7j7018573; Tue, 4 Mar 2008 20:41:07 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from brainhub.org (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m253f5iu018565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Mar 2008 20:41:06 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from [63.251.255.221] (63-251-255-221.pgp.com [63.251.255.221] (may be forged)) by brainhub.org (8.14.2/8.14.1) with ESMTP id m253f180009752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 19:41:02 -0800 Message-ID: <47CE1648.6050402@brainhub.org> Date: Tue, 04 Mar 2008 19:40:56 -0800 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: David Crick Subject: Re: ECC in OpenPGP proposal References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <47CC7750.7080206@brainhub.org> <117bad160803031449p1efb03bao654561db48a5dbb2@mail.gmail.com> <47CD0451.9000503@brainhub.org> <117bad160803040655x3f393c7cuda72f361fbd119a4@mail.gmail.com> In-Reply-To: <117bad160803040655x3f393c7cuda72f361fbd119a4@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Crick wrote: > On 3/4/08, Andrey Jivsov wrote: > >> David Crick wrote: >> >> We need 3DES as a fallback default to smoothly integrate ECC keys >> >> into existing installed base, as I mentioned earlier. >> >> >> > >> > then (reluctantly, but not violently against) how about: >> > >> > MAY implement ECC >> > o MUST implement SHA256 >> > o MUST implement ECC256 >> > [ o MUST implement 3DES - directly inherited from 4880, like it or not] >> > o MUST implement AES128 [or just inherit the SHOULD from 4880??] >> > >> > o SHOULD implement AES256-SHA512-521ECC >> > o MAY implement AES256-SHA384-384ECC >> > >> > o SHOULD try to match cipher strength with ECC strength, where >> > recipient key preferences allow. >> > >> > (then need to add wording in about restrictions required for if strict >> > Suite B compliance is required.) >> > >> >> >> David, I agree with this. >> >> Assuming this is consensus, I will change section 11.1 to "MUST >> implement curve with ID 1 and SHOULD implement curve with ID 3". Also in >> section 11.1, I will change to "MUST implement SHA2-256 and should >> implement SHA2-512,", dropping curve ID 2 and dropping SHA2-384 as MUST >> for OpenPGP profile. >> > > this sounds like what what we've got to so far, although I note > that this makes the [AES256-]SHA384-384ECC an *implicit* MAY > rather than *specifically* mentioning SHA384 and ECC384 as > MAYs. > > So, should we *explicitly* mention them? > My thoughts on MAY were that since this spec is MAY in relation to RFC4880, the explicit MAYs on defined or otherwise referenced algorithms are redundant. If we define a curve and don't list it as SHOULD or MUST, I assumed that it follows that it is MAY. Where do you see a benefit of explicit MAY? 384 ECC is defined in this spec, thus is MAY. SHA382 is MAY from RFC 4880 and AES256 is SHOULD in this spec. Can using MAY once create questions as to why other combinations are not MAYs? > (also, an aside regarding repetition of a point I've previous made: > the (e.g.) keywrapping text in -pre6 only talks about AES; this > needs to be made more general, referring instead to keylengths.) > You are right, there is a dependency on AES in this spec. It is currently required in AESWrap key wrapping method. I realize that you may have interpreted this differently. I prefer we fix AES with AESWrap method, and this is how the -pre6 is written. The argument about multiple recipients doesn't apply here, but relative strength does. I suppose that even embedded devices can use AES-256 as KEK for key wrapping and AES-128 for message encryption (or any other algorithm for latter) , because the performance of AESWrap is not an issue on up to 48 bytes (the availability in hardware probably is). In any case, any of 3 AES variants are allowed in current proposal for AESWrap, plus, we have AES-256 as SHOULD. For example, http://www.ellipticsemi.com/products-clp-34.php shows hardware implementation, which is hardwired to AES 128 or 256. (Just to be clear, nothing in this section applies to the choice of algorithm for symmetric message encryption key.) >> I will add a few sentences about Suite B and RFC4880 (in)compatibility. >> The problems are very very similar to the issue of FIPS mode of >> operation and RFC 4880. >> > > yes > > >> Regarding algorithm tupples, Section 12 already lists >> AES256-SHA512-521ECC and AES256-SHA384-384ECC as SHOULD combinations. >> > > the -pre6 document specifically lists P384-SHA384-AES192 > in 12 (which, as per NIST, *are* the matching strengths), with > the "MAY use stronger" in the paragraph before the table, but > with the the AES256 (as per Suite B) in 11.2.2 before. > > All these pieces *together* allow for our discussed > AES256-SHA384-384ECC combination, i.e. to support Suite B > and to "drop" AES192. > Yes. The main reason to keep 192 is interoperability. >> I think it is better to break tupples into 3 pieces and address them >> independently. >> > > Maybe it's because I haven't re-read the document as a whole > with all our changes in place, but I'm personally finding it a bit > hard to read our discussed cipher suggestions when they are > split up as they currently are. > > Do you want to try producing a -pre7 so that we can see if we > think it (a) matches our growing consensus and, (b) says it in > a clear manner? > > If it does then great, otherwise some section, paragraph and > topic re-ordering might be required. > Yes, I will update the spec based on latest feedback. >> The choice of symmetric algorithm is governed by key >> preferences of (multiple) recipients. We shouldn't disregard preference >> list and prefer AES-256 (even for ECC keys). >> > > 4880 section 13.2 says this: > > An implementation MUST NOT use a symmetric algorithm that is not in > the recipient's preference list. When encrypting to more than one > recipient, the implementation finds a suitable algorithm by taking > the intersection of the preferences of the recipients. Note that the > MUST-implement algorithm, TripleDES, ensures that the intersection is > not null. *The implementation may use any mechanism to pick an > algorithm in the intersection.* > > I suggest we *use* this freedom by (but!) tightening it in OpenPGP ECC > applications. So, our ECC document would have something like: > > Having obtained an intersection of symmetric algorithm preferences, > implementations SHOULD attempt to match symmetric algorithm size > with public key size. > I note that this issue is orthogonal to this spec, i.e. it applies to RFC 4880 as well. However, if there is a consensus, we can recommend this. One justification for "why now" is, practically speaking, ECC allows balanced strength while RFC 4880 doesn't. However, I would try to stay within RFC4880. The issue of tightening is similar to other restrictions I put in section 12: MDC: SHOULD, S2K: iterated salted, SHA-1: MUST NOT. Ian suggested MDC/S2K to be MUST. > [*Personally*, I'd like to continue: > ", favouring longer lengths where possible."] > While we should not deprive implementations the allowed method to advertise prioritized preferences, I think we there is a room for improvement in "grey areas". For example, * Two recipient keys have following ordered prefs.: {AES128, AES256} and {AES256, AES128}. * RFC 4880 allows either of these sets to be the ordered intersection. In this case we can "tighten" as you suggested. Many of these issues are in the realm of key managing software. If user is adding single AES128 preference to ECDH 521, the software can warn her. > The following table provides current equivalent recommendations > (SP800-57). Note TripleDES is considered to have 112-bit security. > > Asymmetric | Hash | Symmetric | Elliptic > key size | size | key size | curve key > (RSA + D-H) | | | size > ------------+--------+-------------------------- > 1024 160 80 160 > 2048 224 112 224 > 3072 256 128 256 > 7680 384 192 384 > 15360 512 256 521 > > [the columns should probably be in a "better" order, this was > just copied from 4800 with ECC then added on the end] > > > >> So section 11.1 tell >> MUST/SHOULD for individual algorithms and section 12 gives SHOULD >> recommendations regarding dependencies between algorithms. >> > > Subject to my "clarity" point above, then OK, yes, I can see > this is how you are conveying this at present. > > > >> After above changes to section 11.1, the only missing correction there >> is "SHOULD implement AES-256". >> > > yup. > I will integrate feedback from everybody into the next revision. Thank you. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m24Ktdeq017285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 13:55:39 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m24Ktd38017284; Tue, 4 Mar 2008 13:55:39 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from brainhub.org (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m24Ktbf1017277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Mar 2008 13:55:38 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from [63.251.255.221] (63-251-255-221.pgp.com [63.251.255.221] (may be forged)) by brainhub.org (8.14.2/8.14.1) with ESMTP id m24KtNfb006353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 12:55:27 -0800 Message-ID: <47CDB736.5030100@brainhub.org> Date: Tue, 04 Mar 2008 12:55:18 -0800 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Ian G CC: David Crick , Len Sassaman , ietf-openpgp@imc.org, "Daniel A. Nagy" Subject: Re: ECC in OpenPGP proposal References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <117bad160803040915h556db896ma53ad69a4a5feb50@mail.gmail.com> <117bad160803040917g75814d55oc63250a0591017bd@mail.gmail.com> <117bad160803041112h5e187096vcc698d071a2e4251@mail.gmail.com> <47CDAD1E.5030605@systemics.com> In-Reply-To: <47CDAD1E.5030605@systemics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Once again, this proposal is for each 3 of 1) ECC with OpenPGP within RFC 4880, 2) Suite B and 3) mobile. This is a pragmatic proposal to extend RFC4880 to get benefits in each of 3 areas. This may not be perfect, for example, for PC folks and for mobile folks if they only focus on their hardware, but I believe it can be agreed upon if interested parties forgo some features in the interest of interoperability. This promotes the idea of a single key. Instead of having a SuiteB key, why not have an RFC 4880 ECC key that can be used for SuiteB or OpenPGP, PCs, PDAs, smartcards, HSMs, depending on software configuration? Regarding V5, I don't see justification for it. I would view ECC DSA is a variant of DSA. Granted, it as a change in public key algorithm, but we have a mechanism to add new public key algorithm to RFC 4880. Ian G wrote: > Lots of questions! For me, the confusion is swirling around these > questions: > > The proposal in question is: > > (a) Suite B > (b) ECC, and/or > (c) mobile > > Is it one of these? All of them? Two of them? > > I would argue that (a) sounds good. When the NSA speaks, I listen. > (normally it is the other way around...) I like their Suite B and > would copy it exactly, word for word, no deviations. > > (b) sounds less good, as this involves much more work (e.g., doing it > properly) and would tempt me to say "wait for V5!" or "just listen to > the NSA, guys." > > (c) is something that should be done by the mobile guys, as Dani > pointed out, there are special things that need to be considered. > > One-size-fits-all will probably result in nobody being happy. > > iang Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m24KXLZf015613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 13:33:21 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m24KXLC9015612; Tue, 4 Mar 2008 13:33:21 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m24KXJv7015605 for ; Tue, 4 Mar 2008 13:33:20 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by wf-out-1314.google.com with SMTP id 28so1133067wff.28 for ; Tue, 04 Mar 2008 12:33:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=9Audti9sF4YVUr9NPSNRbyImIy5xxGIqHcRHsj1qvNI=; b=TzH9UELllirmE7uxiinh17973LiR/XI5zYox4qivOx2c7vHkWGBzn/qH96FeBbZdUjHNDMEGrC/JpcKmnT1qe42bxve6O7K0fqgziGLJiVNam0oHLTjLtJ3QwE4DX3/xZhOjKKwZVgDsBmWTFiSpvySHgVv1TDjk8cjx4dS+qY4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hHdHzrKcaBfPDKHXORLUhHHdCMQcY2cd8uwqPzDcAB3nC6rKpqXOLDPT9PpkFTuoi9Wqn8PgFVPQBVlAsMQiqn9FwisLgLqiOcAqYpraPtzoOLFiQi1xo6u8qKcrNCtgEz6WK7Tipwtal44wEgl3JNbhU8TIVRFFfanLvX5QTD0= Received: by 10.142.178.13 with SMTP id a13mr605688wff.129.1204662799575; Tue, 04 Mar 2008 12:33:19 -0800 (PST) Received: by 10.143.172.3 with HTTP; Tue, 4 Mar 2008 12:33:19 -0800 (PST) Message-ID: <117bad160803041233l56ee9d22ge585c5533c280c1d@mail.gmail.com> Date: Tue, 4 Mar 2008 20:33:19 +0000 From: "David Crick" To: "Ian G" Subject: Re: ECC in OpenPGP proposal Cc: "Len Sassaman" , ietf-openpgp@imc.org, "Andrey Jivsov" , "Daniel A. Nagy" In-Reply-To: <47CDAD1E.5030605@systemics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <117bad160803040915h556db896ma53ad69a4a5feb50@mail.gmail.com> <117bad160803040917g75814d55oc63250a0591017bd@mail.gmail.com> <117bad160803041112h5e187096vcc698d071a2e4251@mail.gmail.com> <47CDAD1E.5030605@systemics.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 3/4/08, Ian G wrote: > Lots of questions! For me, the confusion is swirling around > these questions: > > The proposal in question is: > > (a) Suite B > (b) ECC, and/or > (c) mobile the *original* document basically suggested (a), *BUT* with the unsaid (but since spelled out) point that 3DES is implicitly *also* allowed *if* we are extending 4880 / interoperating with 4880. > Is it one of these? All of them? Two of them? was have since shifted to (b), with the (c) bit as the MUST. > I would argue that (a) sounds good. When the NSA speaks, I > listen. It's the biggest endorsement (particularly after Suite B) that [a subset of] our OpenPGP algorithms could possibly have. > (normally it is the other way around...) LOL > I like > their Suite B and would copy it exactly, word for word, no > deviations. ideally, yes, I'd say this too (extra ideally, I'd just go for their bigger suite, the SHA384-AES256-ECC384_DH_DSA). > (b) sounds less good, as this involves much more work (e.g., > doing it properly) and would tempt me to say "wait for V5!" > or "just listen to the NSA, guys." agree with you on all your points here > (c) is something that should be done by the mobile guys, as > Dani pointed out, there are special things that need to be > considered. I think it was Dani that said that AES128 was too slow on the Nokia (and so he was using RC4)? In any case, I agree that just justifying the smaller algorithms "*because of* mobiles" isn't in itself necessarily right. (However, choosing the smaller algorithms "because of mobiles *and* because they're secure enough generally *and* because they're a Suite B subset *is* closer to what we're saying) > One-size-fits-all will probably result in nobody being happy. > > iang How unhappy would *you* (personally; this is also open to other people!) be with (each stage being possible points of objection): 1) AES128-SHA256-ECC256 as the MUST (still talking V4 btw) 2) with 3DES as an implicit MUST for 4880 interoperability 2a) wording to encourage (SHOULD) matching algo. sizes 2b) wording to point out additional restrictions for Suite B 3) Future V5 keys to possibly make further restrictions Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m24KM27O014895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 13:22:02 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m24KM2T7014894; Tue, 4 Mar 2008 13:22:02 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from brainhub.org (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m24KM017014885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Mar 2008 13:22:01 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from [63.251.255.221] (63-251-255-221.pgp.com [63.251.255.221] (may be forged)) by brainhub.org (8.14.2/8.14.1) with ESMTP id m24KLqSd006119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 12:21:53 -0800 Message-ID: <47CDAF5B.9050105@brainhub.org> Date: Tue, 04 Mar 2008 12:21:47 -0800 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Ian G , ietf-openpgp@imc.org CC: "Daniel A. Nagy" , David Crick Subject: Re: ECC in OpenPGP proposal References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C7FDEA.5070103@systemics.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <47CD6DAE.9010409@systemics.com> In-Reply-To: <47CD6DAE.9010409@systemics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I respectfully remind you that the target of this proposal is 1) to better match AES key strength with OpenPGP by extending RFC 4880, 2) to meet Suite-B, 3) to offer more usable alternative for mobile/embedded systems. Suite B is limited to section 11.2. Suite B will have limited interoperability with RFC 4880, just like currently FIPS certification is incompatible with RFC 4880. Most of your comments in this e-mail apply to small section 11.2. The discussion earlier was mostly about OpenPGP ECC keys that are compatible with RFC 4880. Ian G wrote: > OK, I think I found it. Sorry for not keeping up! > > > > Daniel A. Nagy wrote: >> I think, Andrey makes a very important point here. The option to use >> 3DES >> symmetric encryption, SHA1 digest and ZLIB compression must remain >> open until >> a formal process of phasing them out is initiated, with a clear road >> map. >> Right now, excluding these algorithms would break interoperability in >> a very >> bad way, as described by Andrey. > > > I disagree, below :) > > >> Of course, SHA1 and 3DES are not without problems, but for most >> security-critical applications they are still perfectly adequate. > > > Right. The question is not about the security of the algorithms > (which are more or less Pareto-secure-ish). Instead, it is about the > business aspects of delivering the most security to the most people. > > >> On Fri, Feb 29, 2008 at 09:36:11PM -0800, Andrey Jivsov wrote: >>> David Crick wrote: >>> ... >>>> The ecc-pre-6.txt's section 2 pretty much says "this is how to >>>> do ECC with AES," and we've said that this proposal is a "MAY." >>>> In a sense this is therefore some kind of a fork (sub-superset?) >>>> of 4880, so we're not concerned with 3DES (or CAST), and - as >>>> with DSA - we can make specific restrictions in order to meet >>>> compliance. > > Yes. This is a natural fork. It is for people who want Suite B. > Which means the various USG organisations. Which before have not in > the past been that impressed with OpenPGP. Actually, not impressed > with anything in the open world, I'd say. We are really in new > territory now that the NSA/NIST people have opened their hearts and > declared Suite B. > > Which isn't to say that we shouldn't consider compatibility, but to > say that this is a good, natural fork. We should also think about > taking it... > > (I would. I remember the pain that was PGP 5.) > > >>> I think we need to be careful here. Let's examine a use case. >>> >>> I am a user of some RFC 4880 OpenPGP application. All algorithms are >>> available to me, e.g. I am not a government employee. >>> >>> * I use the application to encrypt mail to 5 recipients, my friends. >>> They use RSA/DSA/ElGamal keys. >>> >>> * I upgraded the application to the next version that happened to >>> implement "ECC in OpenPGP". >>> >>> I assume that we agree that if I encrypt to exactly the same 5 >>> people with new version, as far as algorithm selection is concerned, >>> the result is identical to the previous version. >>> >>> * I added 6th recipient to the list, which uses ECDH key. > > > OK I see that. If... > >>> I hope we will agree that it must be possible to send single e-mail >>> to 6 recipients. RFC 4880 specifies that the default encryption >>> algorithm is 3DES, thus, there is always a match. Why shouldn't >>> single e-mail be sent to 6 recipients with 3DES symmetric key? > > > Sorry, I don't agree. The RFC4880 specification is only for > applications that apply (more or less) to RFC4880! > > Applications that implement both RFC4880 *and* OpenPGP/ECC/Suite B are > given no guarantee that this is likely to be seamless and joyful and > without any degradation in their promised user experience. > > Just like S/MIME and RFC4880. > > To imagine otherwise would be to say that RFC4880's promise is that > *all future work* is also compatible. That's hopeless. How far do we > want to take that promise? OpenPGP quantum key exchange? What > happens if the Russkies decide they want an OpenPGP GOST and they > decide it is incompatible by definition with OpenPGP ECC? Or, we can > retitle S/MIME as OpenPGP/S/Mime and insist on compatibility :) > > My point: It is *not* a given that people using OpenPGP Suite B can > talk to people using RFC4880. Desirable, sure, but not a given. > > (I'd bet the NSA would prefer this *not* to be the case ;) > > Example: Consider properly written small-device platforms using the > ECC stuff: They will likely implement the AES128-ECC-SHA "small" > profile, and not include 3DES at all. The last thing anyone in the > smart card / mobile world wants is incompatibility forced by vestigial > circumstances. They want all *their* people talking, and that means > one system, one algorithm. Talking to other people is a distant > second in most business plans, and a controversial one at that. > > >>> If the application is operating in Suite-B mode, or FIPS more, etc, >>> then the situation is different. > > > Yes, there are security ramifications. Are we really implementing > Suite B if the application can leak info by sending out emails > encrypted in Suite B (strong) and in 3DES to some 512 RSA key (not so > strong)? > > iang Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m24KCItq014189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 13:12:18 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m24KCIdr014188; Tue, 4 Mar 2008 13:12:18 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from goten.sonance.net (goten.sonance.net [88.198.58.135]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m24KCG1K014175 for ; Tue, 4 Mar 2008 13:12:17 -0700 (MST) (envelope-from iang@systemics.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id 4D68B57B0B; Tue, 4 Mar 2008 21:12:16 +0100 (CET) Received: from goten.sonance.net ([127.0.0.1]) by localhost (goten.sonance.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HS7wFTaCjfW5; Tue, 4 Mar 2008 21:12:16 +0100 (CET) Received: from zhukov.local (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id C840857AF8; Tue, 4 Mar 2008 21:12:15 +0100 (CET) Message-ID: <47CDAD1E.5030605@systemics.com> Date: Tue, 04 Mar 2008 21:12:14 +0100 From: Ian G User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: David Crick CC: Len Sassaman , ietf-openpgp@imc.org, Andrey Jivsov , "Daniel A. Nagy" Subject: Re: ECC in OpenPGP proposal References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <117bad160803040915h556db896ma53ad69a4a5feb50@mail.gmail.com> <117bad160803040917g75814d55oc63250a0591017bd@mail.gmail.com> <117bad160803041112h5e187096vcc698d071a2e4251@mail.gmail.com> In-Reply-To: <117bad160803041112h5e187096vcc698d071a2e4251@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Lots of questions! For me, the confusion is swirling around these questions: The proposal in question is: (a) Suite B (b) ECC, and/or (c) mobile Is it one of these? All of them? Two of them? I would argue that (a) sounds good. When the NSA speaks, I listen. (normally it is the other way around...) I like their Suite B and would copy it exactly, word for word, no deviations. (b) sounds less good, as this involves much more work (e.g., doing it properly) and would tempt me to say "wait for V5!" or "just listen to the NSA, guys." (c) is something that should be done by the mobile guys, as Dani pointed out, there are special things that need to be considered. One-size-fits-all will probably result in nobody being happy. iang Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24JCqh1003527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 12:12:52 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m24JCqx3003526; Tue, 4 Mar 2008 12:12:52 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.188]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24JCoXS003515 for ; Tue, 4 Mar 2008 12:12:51 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by rv-out-0910.google.com with SMTP id c27so464948rvf.34 for ; Tue, 04 Mar 2008 11:12:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=HWNFPayjaKS9M7r2OGfJZdXM293rO7rgnPoU1LnaOmY=; b=tJY1/C8G436KLiAsCBbCkSX8E3XcCNKuhD5Hhdbq8sIn3omzBFKbi9RWVeCSDmcnzw4Ngfu7w64H30GjmFJCBglV7qu9PRFQK2P30gPMFEpe9SyTAVr1+m3eWGKmMEEPDM04a6GOJWbbwpKvkjOjx0ZnDf9/QIPK0Bmeyft2X5Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=xyP2i+qpkhLFFRuDX8JGezjen1mRPd3SaqAgqrR3KfOpR3PVXbV4P1p1wbIfO/pkio+WkzBon/4KM+dCiQTd8Xw+06rENKZbGLWk7cqT7PCI7T/+/u+eKmrDJ3Q11jlCdn9CV1Xifmp5KGEGj953N62waerLAgX7ZEea1qFmKTE= Received: by 10.141.164.13 with SMTP id r13mr909924rvo.65.1204657969678; Tue, 04 Mar 2008 11:12:49 -0800 (PST) Received: by 10.141.201.6 with HTTP; Tue, 4 Mar 2008 11:12:49 -0800 (PST) Message-ID: <117bad160803041112h5e187096vcc698d071a2e4251@mail.gmail.com> Date: Tue, 4 Mar 2008 19:12:49 +0000 From: "David Crick" To: "Len Sassaman" Subject: Re: ECC in OpenPGP proposal Cc: ietf-openpgp@imc.org, "Andrey Jivsov" , "Daniel A. Nagy" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <117bad160803040915h556db896ma53ad69a4a5feb50@mail.gmail.com> <117bad160803040917g75814d55oc63250a0591017bd@mail.gmail.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 3/4/08, Len Sassaman wrote: > On Tue, 4 Mar 2008, David Crick wrote: > > > I really would *ideally* like to see just one cipher suite, which I see > > could see would be: SHA384-AES256-ECC384_DH_DSA. > > > I'm with you on the one cipher suite. I think good protocols must have > methods by which new ciphers can be added (and implementors might actually > want to have them in the code and tested and ready should they need to > enable them), but the more options we add to a cipher suite, the more that > can go wrong. > > (This is also my argument for why we should be using Whirlpool with AES, > but the counter argument of popularity/support for the second-gen SHAs > probably out-weighs it.) > > Ian G. has written about this a lot, and he and I don't always agree on > everything, on this point, we do. OpenPGP already wants to do what I want > it to do; except the current notion is that if a cipher is broken, > everyone will disable support for it. That might have been a reasonable > assumption when only cypherpunks were using it, but it is naive now. If > you give the user a way to break their security, they will -- especially > if "not doing something" means breaking their security. > > (As for which ciphers should go in, I'm going to remain agnostic. I would > pick differently than you did, but we all have our pet favorites. What > matters is that we limit the avenues of attack -- it's not about putting > all our eggs in one basket, as some confused people think; rather, it's > about limiting the possible crypto-level attacks on has available to them > when trying to break the system.) > > > > --Len. > hey, you quoted my One Cipher choice without my corresponding relevant justification! :) But yeah, I agree that others will disagree. I think we *all* agree that we'd like to see ECC in OpenPGP (and for those that don't, the current proposal appears to supplement, not obsolete, 4880, so they can continue in their non-ECC world). ECC will: 1) bring equiv. of 3K pub key to small devices 2) bring equiv. of 7 to 15K pub key to larger devices 3) allow OpenPGP to compete in the ECC marketplace 4) bring Suite B support (this is subset of some of the previous) Now, we're currently fixating on the general topic of reducing algorithms. AES192 seems to be departing without too much protest, but 3DES (and the wider topic of 4880 compatibility) seems to be the current "issue." With V5 keys I think we're envisaging some form of incompatibility? For instance, Daniel's recently posted "Thoughts and suggestions on V5 key format" suggests using SHA512 for the fingerprint (which I'd agree with given present specified 4880 hashes). Clearly that would make SHA512 a MUST for V5 key applications - but it's not even widely implemented/deployed yet (e.g. the last time I checked, PGP9 wouldn't recognise SHA512 as a cert-digest-algo). * So for me I think the whole ECC current point in question appears to be: _when_ do we want to introduce ECC? Do we want to have it as an alternative V4 choice (in which case we seem to, e.g., by default allow 3DES with ECC), or do we wait until V5 (when we then might be able to say: only AES with ECC) ? * Now, let's say our user installs PGP 10 and is allowed to generate a V4 ECC key. Several years later ;) with PGP 12 they are prompted to generate a different (V5) ECC key as the default. They are left wondering: "didn't I already switch to the "new" ECC keys a few years ago???" I think we want/need ECC in OpenPGP *soon*; I also think we need to move away from SHA1/1024 bit IFP/DLP *soon* as well (where for me, given various national and security bodies' recommendations, "soon" = "by/before 2010"). So, do we try and do both together, or do we try and get ECC done as a V4 alternative *now*, and think about V5 keys afterwards? Thinking about is as I'm typing, I would favour ECC *first* and then V5 after, the reason being that we're (hopefully!) likely to get ECC consensus in a relatively short time, whereas V5 may take longer and might/should also take into account the result of the SHA3 contest, which isn't scheduled to finish until 2012. (We could probably (??!) flesh out V5 before then, just leaving a gap for the details on SHA3.) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24HnS1v089235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 10:49:28 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m24HnSPZ089234; Tue, 4 Mar 2008 10:49:28 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24HnQML089226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 4 Mar 2008 10:49:27 -0700 (MST) (envelope-from rabbi@abditum.com) Received: by thetis.deor.org (Postfix, from userid 500) id 3522445228; Tue, 4 Mar 2008 09:49:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by thetis.deor.org (Postfix) with ESMTP id 21DC948053; Tue, 4 Mar 2008 09:49:26 -0800 (PST) Date: Tue, 4 Mar 2008 09:49:26 -0800 (PST) From: Len Sassaman X-X-Sender: rabbi@thetis.deor.org To: David Crick Cc: ietf-openpgp@imc.org, Andrey Jivsov , "Daniel A. Nagy" Subject: Re: ECC in OpenPGP proposal In-Reply-To: <117bad160803040917g75814d55oc63250a0591017bd@mail.gmail.com> Message-ID: References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <117bad160803040915h556db896ma53ad69a4a5feb50@mail.gmail.com> <117bad160803040917g75814d55oc63250a0591017bd@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 4 Mar 2008, David Crick wrote: > I really would *ideally* like to see just one cipher suite, which I see > could see would be: SHA384-AES256-ECC384_DH_DSA. I'm with you on the one cipher suite. I think good protocols must have methods by which new ciphers can be added (and implementors might actually want to have them in the code and tested and ready should they need to enable them), but the more options we add to a cipher suite, the more that can go wrong. (This is also my argument for why we should be using Whirlpool with AES, but the counter argument of popularity/support for the second-gen SHAs probably out-weighs it.) Ian G. has written about this a lot, and he and I don't always agree on everything, on this point, we do. OpenPGP already wants to do what I want it to do; except the current notion is that if a cipher is broken, everyone will disable support for it. That might have been a reasonable assumption when only cypherpunks were using it, but it is naive now. If you give the user a way to break their security, they will -- especially if "not doing something" means breaking their security. (As for which ciphers should go in, I'm going to remain agnostic. I would pick differently than you did, but we all have our pet favorites. What matters is that we limit the avenues of attack -- it's not about putting all our eggs in one basket, as some confused people think; rather, it's about limiting the possible crypto-level attacks on has available to them when trying to break the system.) --Len. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24HHPTj086204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 10:17:25 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m24HHPv1086203; Tue, 4 Mar 2008 10:17:25 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24HHOhs086197 for ; Tue, 4 Mar 2008 10:17:25 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by el-out-1112.google.com with SMTP id o28so1237538ele.3 for ; Tue, 04 Mar 2008 09:17:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=OdBgBOXgEIOO+XM0zotZiXfpiSVcZjGiwZGjvI6X/D8=; b=e/V+nj8yErx5bqqhQswkoMA9NamM8sYKfy7j9ynRbeLXr4KFzN6B5njPkY3hGkjdwaZfq3rlq6I4IuV1FadcKAau6RSbNzFen64Pkpg8/3gWQBa73bczAHynFqJbNCpUBVrqixsfV0zQqQlHvwE4WHbXjKlaEUy/W1s5JITimZs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VkITaGfsqkRsgaPnVKk1xOiT7YFuf1JAyR32PpvtQg1oD44G7PF9VRVHTsHy5wprBw9nSzo6Z3oIJZSRJj3e3qPGFHb9Y7gR+U1B697xgAb5ctKPB3r2sudyZFbKhFaGwcHAX0brirWOtwlidCOlSJQyE4wxCDvfmbe1NXEkS6M= Received: by 10.140.82.40 with SMTP id f40mr800633rvb.16.1204651043326; Tue, 04 Mar 2008 09:17:23 -0800 (PST) Received: by 10.141.201.6 with HTTP; Tue, 4 Mar 2008 09:17:23 -0800 (PST) Message-ID: <117bad160803040917g75814d55oc63250a0591017bd@mail.gmail.com> Date: Tue, 4 Mar 2008 17:17:23 +0000 From: "David Crick" To: ietf-openpgp@imc.org, "Andrey Jivsov" , "Daniel A. Nagy" , "Len Sassaman" Subject: ECC in OpenPGP proposal In-Reply-To: <117bad160803040915h556db896ma53ad69a4a5feb50@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <117bad160803040915h556db896ma53ad69a4a5feb50@mail.gmail.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: sorry, I once again did reply to sender rather than reply to all - my reply was meant for everyone and not just Len. Hey, it's a *good* security habit to have! :) ---------- Forwarded message ---------- From: David Crick Date: Mar 4, 2008 5:15 PM Subject: Re: ECC in OpenPGP proposal To: Len Sassaman On 3/4/08, Len Sassaman wrote: > On Sat, 1 Mar 2008, David Crick wrote: > > > > > On 3/1/08, Daniel A. Nagy wrote: > > > I think, Andrey makes a very important point here. The option to use 3DES > > > symmetric encryption, SHA1 digest and ZLIB compression must remain open until > > > a formal process of phasing them out is initiated, with a clear road map. > > > Right now, excluding these algorithms would break interoperability in a very > > > bad way, as described by Andrey. > > > > as someone said about alternative V5 key routes - let's absolutely > > make sure we break it! > > > That was more than one person, I think, but I was one of them. thanks for clarifying this. > Breaking compatibility on the protocol level doesn't mean breaking it on > the actually application level. In a different thread, there as discussion > of people using "regular" DSA/EG keys and then adding a recipient who uses > ECC. So what? The application can encrypt twice, and send the properly > encrypted messages to the appropriate people. I think I've also pointed this out (either that or I've thought it but not explicitly said it!) > Backwards compatibility on the protocol level means forward compatibility > on protocol level attacks. Let's not do that, eh? > > [Obviously we don't want to be breaking compatility all the time, but for > something as big as v5, that we've been talking about for almost a decade, > I think it's reasonable to both get it right, and cut the last decade+'s > legacy of cruft loose, and leave the application to support v4 and v5 if > the designer so desires. A lot of the things done in OpenPGP are, in > hindsight, missteps. Hindsight is cheap. Let's make use of it when it is > appropriate.] I really would *ideally* like to see just one cipher suite, which I see could see would be: SHA384-AES256-ECC384_DH_DSA. This uses our largest respective algorithms while being Suite B compliant. As Ian pointed out, we really are into new territory with Suite B - PGP (2) used to say "military strength" when listing larger key sizes; now we can legitimately say "TOP SECRET strength"! [Yes, as an aside, I know that the latter would actually require restricted key generations, physical security measures, tamper evident seals, blah, blah, blah.] I'm actually more concerned that web sites are still using 1024 bit (well, 1120 Bits it says for gmail for me) SSL public keys and SHA1, rather than the fact that somebody might use 3DES as a cipher when sending a message to my 521-bit ECC key. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24Gq7cS083668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 09:52:07 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m24Gq7ao083667; Tue, 4 Mar 2008 09:52:07 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24Gq56A083655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 4 Mar 2008 09:52:06 -0700 (MST) (envelope-from rabbi@abditum.com) Received: by thetis.deor.org (Postfix, from userid 500) id 1F1F0452B3; Tue, 4 Mar 2008 08:52:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by thetis.deor.org (Postfix) with ESMTP id 0AFA548052; Tue, 4 Mar 2008 08:52:05 -0800 (PST) Date: Tue, 4 Mar 2008 08:52:04 -0800 (PST) From: Len Sassaman X-X-Sender: rabbi@thetis.deor.org To: David Crick Cc: ietf-openpgp@imc.org, Andrey Jivsov , "Daniel A. Nagy" Subject: Re: ECC in OpenPGP proposal In-Reply-To: <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> Message-ID: References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C7FDEA.5070103@systemics.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, 1 Mar 2008, David Crick wrote: > > On 3/1/08, Daniel A. Nagy wrote: > > I think, Andrey makes a very important point here. The option to use 3DES > > symmetric encryption, SHA1 digest and ZLIB compression must remain open until > > a formal process of phasing them out is initiated, with a clear road map. > > Right now, excluding these algorithms would break interoperability in a very > > bad way, as described by Andrey. > > as someone said about alternative V5 key routes - let's absolutely > make sure we break it! That was more than one person, I think, but I was one of them. Breaking compatibility on the protocol level doesn't mean breaking it on the actually application level. In a different thread, there as discussion of people using "regular" DSA/EG keys and then adding a recipient who uses ECC. So what? The application can encrypt twice, and send the properly encrypted messages to the appropriate people. Backwards compatibility on the protocol level means forward compatibility on protocol level attacks. Let's not do that, eh? [Obviously we don't want to be breaking compatility all the time, but for something as big as v5, that we've been talking about for almost a decade, I think it's reasonable to both get it right, and cut the last decade+'s legacy of cruft loose, and leave the application to support v4 and v5 if the designer so desires. A lot of the things done in OpenPGP are, in hindsight, missteps. Hindsight is cheap. Let's make use of it when it is appropriate.] --Len. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24Gmftw083190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 09:48:41 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m24Gmf1S083189; Tue, 4 Mar 2008 09:48:41 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.184]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24GmeHb083178 for ; Tue, 4 Mar 2008 09:48:40 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by rv-out-0910.google.com with SMTP id c27so425263rvf.34 for ; Tue, 04 Mar 2008 08:48:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=OT3CIu/nMO5CGBldw/0dNT2SE62+5TYQMqVSjeOTWps=; b=b8gbqbuPZM8bEIe8Dg48KSmIAu26tBjP230V+6dsLrMpa13lQJfkJHnV0ZKsOZWCMD3TubQzuXjw8eqf6RT+hvsvpCCPNJjEoz7jXvpNxPcGWaTi4zs+fR3sHCnfOpt6pt5Remc2egTqKvx8Ui8RDfRt37g/KXMPRovrqihoww4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YHX36wEOSZqn3GUVCEBSukkknROapo4rljOLk0+Sbwkx04u8gAulUvi9gPH93f4VCMGJVNkdi1lq8JOtEFd6X0gpjq59im0n7QeylAl2iQsj0C7n89NuGqRorBgfcR/SEJykE0DaK3BZEUtssl8lqrP6tY8/O3aiRSXrgwMfaD0= Received: by 10.141.83.15 with SMTP id k15mr749276rvl.120.1204649319522; Tue, 04 Mar 2008 08:48:39 -0800 (PST) Received: by 10.141.201.6 with HTTP; Tue, 4 Mar 2008 08:48:39 -0800 (PST) Message-ID: <117bad160803040848v74533155t8dac4db74c0458f3@mail.gmail.com> Date: Tue, 4 Mar 2008 16:48:39 +0000 From: "David Crick" To: "Ian G" Subject: Re: ECC in OpenPGP proposal Cc: ietf-openpgp@imc.org, "Daniel A. Nagy" , "Andrey Jivsov" In-Reply-To: <117bad160803040836w62c31febmd08825ad552324e8@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <47CD6DAE.9010409@systemics.com> <117bad160803040836w62c31febmd08825ad552324e8@mail.gmail.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Yes, there are security ramifications. Are we really > > implementing Suite B if the application can leak info by > > sending out emails encrypted in Suite B (strong) and in 3DES > > to some 512 RSA key (not so strong)? > > > Going forward we need to re-establish what is considered > minimally secure. I should have also have added that in our OpenPGP-ECC doc we are pointing out equivalent strengths and further stating that for Suite B compliance there are further restrictions. I can see quite easily a PGP option checkbox or Gnupg flag that says --strict-SuiteB-ECC. This could *refuse* to encrypt to multiple keys using a smaller cipher. We have the same situation today. There's no point me changing my GnuPG source to allow me to generate a 7K RSA encryption key, because unless all my correspondents *also* use the same/equivalent/stronger lengths, then the session key is at the mercy of the smallest public key size. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24GaNaI081815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 09:36:24 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m24GaNsd081814; Tue, 4 Mar 2008 09:36:23 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.182]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24GaKf7081798 for ; Tue, 4 Mar 2008 09:36:23 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by el-out-1112.google.com with SMTP id o28so1201426ele.3 for ; Tue, 04 Mar 2008 08:36:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=OdvgzS3v055+X2j46PFtClxCgLfNL3JUJAdF3FCFJ+s=; b=ryrjcH/HICn5ZMKhBwqgBDrZw/HItiAp/V1drZzYryFiA71z6FcHaMgG9w7b0sr6BNDshcD4jJXZ6F26p0zttmyBLsI1rD5fBzkkyFkKPi6J4yvkWIn1ubT+rl5Jq2SIqzcQxNEevx2PZg10+NqPQUX4enDWOPJFxCAIO9W3998= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=vhmoXZjRMLa9dpyUT7Q34nyRMnr8T+3gSFHRs8UzKosb/ITewAjKWG7lSeVXtwMUhIi7M2nrmIuSKTQgedbpIT0yIq9HMUoH2CnalKTrAx3Rr0dthyueKSq6OPI38H7xPKft2h0yU1B16BWv4o4F2sX+izvkpnKj+ZxdYQ4EdxM= Received: by 10.141.113.6 with SMTP id q6mr750297rvm.36.1204648579369; Tue, 04 Mar 2008 08:36:19 -0800 (PST) Received: by 10.141.201.6 with HTTP; Tue, 4 Mar 2008 08:36:19 -0800 (PST) Message-ID: <117bad160803040836w62c31febmd08825ad552324e8@mail.gmail.com> Date: Tue, 4 Mar 2008 16:36:19 +0000 From: "David Crick" To: "Ian G" Subject: Re: ECC in OpenPGP proposal Cc: ietf-openpgp@imc.org, "Daniel A. Nagy" , "Andrey Jivsov" In-Reply-To: <47CD6DAE.9010409@systemics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C7FDEA.5070103@systemics.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <47CD6DAE.9010409@systemics.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 3/4/08, Ian G wrote: > OK, I think I found it. Sorry for not keeping up! no problem. Also, note that yours and my emails have overlapped in our composing/sending, and that I unintentionally sent me last email to just you rather than the list. Hopefully everyone can now re-follow the discussion! > Daniel A. Nagy wrote: > > I think, Andrey makes a very important point here. The option to use 3DES > > symmetric encryption, SHA1 digest and ZLIB compression must remain open until > > a formal process of phasing them out is initiated, with a clear road map. > > Right now, excluding these algorithms would break interoperability in a very > > bad way, as described by Andrey. > > > > I disagree, below :) yes, I have also disagreed - and still do "in principle". *However,* I can (now) accept that as a "way forward" compromise we can have both ECC and some interoperability with current OpenPGP. I'm attempting to (subtly ;) ) try and implement wording for us that similarly "encourages" use of AES over 3DES by having an "implementations SHOULD try and match sym & pk key lengths" bit, together if possible (help me here Ian ;) ) with a further "longer lengths should be preferred". Maybe we should even add an example: If Alice has a 1024 bit RSA key and Bob a 521-bit ECC key, and both Alice and Bob have AES256 as one of their possible cipher preferences, then implementations SHOULD choose this stronger cipher. This is a hack on 4880's "implementations may choose any method of selecting from the intersection of preferences" - i.e., for ECC we are saying how implementations SHOULD (but, note, not any stronger than SHOULD). I feel this is both within the spirit of 4880 *as well as* our best intentions to encourage AES. > > > > > Of course, SHA1 and 3DES are not without problems, but for most > > security-critical applications they are still perfectly adequate. > > > > Right. The question is not about the security of the > algorithms (which are more or less Pareto-secure-ish). > Instead, it is about the business aspects of delivering the > most security to the most people. > > > > > On Fri, Feb 29, 2008 at 09:36:11PM -0800, Andrey Jivsov wrote: > >> David Crick wrote: > >> ... > >>> The ecc-pre-6.txt's section 2 pretty much says "this is how to > >>> do ECC with AES," and we've said that this proposal is a "MAY." > >>> In a sense this is therefore some kind of a fork (sub-superset?) > >>> of 4880, so we're not concerned with 3DES (or CAST), and - as > >>> with DSA - we can make specific restrictions in order to meet > >>> compliance. > > > Yes. This is a natural fork. But it has been pointed out that we can still keep 4880 compliance by inheriting its 3DES (and then "encouraging" AES when used with Ecc). > It is for people who want > Suite B. I think there are "people who want *ECC*" and *also* people who want Suite B. Personally, I'd like to *only* see Suite B ECC, but consider people thinking "hey, OpenPGP only has 384-bit ECC, but has 521-bit. OpenPGP sucks!" > Which means the various USG organisations. > Which before have not in the past been that impressed with > OpenPGP. Actually, not impressed with anything in the open > world, I'd say. We are really in new territory now that the > NSA/NIST people have opened their hearts and declared Suite B. yes, we certainly are. > Which isn't to say that we shouldn't consider compatibility, > but to say that this is a good, natural fork. We should > also think about taking it... > > (I would. I remember the pain that was PGP 5.) We could "force" a split, *or*, we could orchestrate a slow migration, through adding ECC ("hey, cool, PGP has a new public key algorithm. It must be better!"), and then perhaps with V5 keys. > >> I think we need to be careful here. Let's examine a use case. > >> > >> I am a user of some RFC 4880 OpenPGP application. All algorithms are > >> available to me, e.g. I am not a government employee. > >> > >> * I use the application to encrypt mail to 5 recipients, my friends. > >> They use RSA/DSA/ElGamal keys. > >> > >> * I upgraded the application to the next version that happened to > >> implement "ECC in OpenPGP". > >> > >> I assume that we agree that if I encrypt to exactly the same 5 people > >> with new version, as far as algorithm selection is concerned, the result > >> is identical to the previous version. > >> > >> * I added 6th recipient to the list, which uses ECDH key. > > > > OK I see that. If... > > > >> I hope we will agree that it must be possible to send single e-mail to 6 > >> recipients. RFC 4880 specifies that the default encryption algorithm is > >> 3DES, thus, there is always a match. Why shouldn't single e-mail be sent > >> to 6 recipients with 3DES symmetric key? > > > > Sorry, I don't agree. The RFC4880 specification is only for > applications that apply (more or less) to RFC4880! > > Applications that implement both RFC4880 *and* > OpenPGP/ECC/Suite B are given no guarantee that this is > likely to be seamless and joyful and without any degradation > in their promised user experience. we're now saying there's a way. > > Just like S/MIME and RFC4880. > > To imagine otherwise would be to say that RFC4880's promise > is that *all future work* is also compatible. That's > hopeless. How far do we want to take that promise? OpenPGP > quantum key exchange? What happens if the Russkies decide > they want an OpenPGP GOST and they decide it is incompatible > by definition with OpenPGP ECC? Or, we can retitle S/MIME > as OpenPGP/S/Mime and insist on compatibility :) > > My point: It is *not* a given that people using OpenPGP > Suite B can talk to people using RFC4880. Desirable, sure, > but not a given. > > (I'd bet the NSA would prefer this *not* to be the case ;) > > Example: Consider properly written small-device platforms > using the ECC stuff: They will likely implement the > AES128-ECC-SHA "small" profile, and not include 3DES at all. Then they're not OpenPGP/4880 compliant/compatible/ > The last thing anyone in the smart card / mobile world > wants is incompatibility forced by vestigial circumstances. > They want all *their* people talking, and that means one > system, one algorithm. Talking to other people is a distant > second in most business plans, and a controversial one at that. That one algorithm *at present* is 3DES. > >> If the application is operating in Suite-B mode, or FIPS more, etc, then > >> the situation is different. > > > > Yes, there are security ramifications. Are we really > implementing Suite B if the application can leak info by > sending out emails encrypted in Suite B (strong) and in 3DES > to some 512 RSA key (not so strong)? Going forward we need to re-establish what is considered minimally secure. With ECC we're effectively closing off SHA1 (as a hash; it'll still be there for, e.g., the fingerprint, at least as I understand it). With V5 keys we could vape SHA1 entirely, and set 2048 (IF/DLP) / 256 (ECC) public keys as the minimum lengths. 2030 is our next "target" - that will likely mark the point when we need to shift from 3DES, SHA224 and 2048IFDLP/224ECC to (for the lowest strength) SHA256-AES128-3072IFDLP/256ECC. > > iang > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24GDG5U079455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 09:13:16 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m24GDGNF079454; Tue, 4 Mar 2008 09:13:16 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24GDFgP079448 for ; Tue, 4 Mar 2008 09:13:15 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by wr-out-0506.google.com with SMTP id 76so1236878wra.10 for ; Tue, 04 Mar 2008 08:13:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=9hUbHy1oLYxGM5ioyvI0jpOllXN9Hzj2bnjMwf7w8zc=; b=J2TzRx9bq7buoHi71o/6wN2EtEJ+rhTnqFtM8A2gr21UTKgI08MgO6RYWOv20nOxzwyhpxiuXCe2J0MSRmF1wo4tZ3B7UPtgOh2DDL2EcXyN5Ytqx5goJSkNrMFuJvZLqqDCFJGNjWMJlWGr4IpsrnzbWYCaBnjvBhHC3QZHsUY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FXh7dwd0bYkIdlnbxFtogH3WfeZHXhf6sxH/PUBRZwdqGhXbPw3Xso1MIHv1SOROu6Bk8Jt3WDVZcudzMpltoslvgjhHhG1fetP1fJNzA3YWp6UFPz41c+U2JYYJBD4yCHM6LrXpdt9nCBLmLZSgcV41T+u7MvlL2JBWiPezKVg= Received: by 10.141.210.21 with SMTP id m21mr728220rvq.33.1204647193959; Tue, 04 Mar 2008 08:13:13 -0800 (PST) Received: by 10.141.201.6 with HTTP; Tue, 4 Mar 2008 08:13:13 -0800 (PST) Message-ID: <117bad160803040813q3129b0d1le46c26920c5be771@mail.gmail.com> Date: Tue, 4 Mar 2008 16:13:13 +0000 From: "David Crick" To: ietf-openpgp@imc.org, "Ian G" , "Andrey Jivsov" , "Daniel A. Nagy" Subject: Fwd: ECC in OpenPGP proposal In-Reply-To: <117bad160803040807n5ee9f31fsd69857e14ca24756@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <47CC7750.7080206@brainhub.org> <47CD648E.10705@systemics.com> <117bad160803040807n5ee9f31fsd69857e14ca24756@mail.gmail.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: sorry, I did "reply to Ian" rather than reply to all (including the list), which I meant to do. ---------- Forwarded message ---------- From: David Crick Date: Mar 4, 2008 4:07 PM Subject: Re: ECC in OpenPGP proposal To: Ian G On 3/4/08, Ian G wrote: > Andrey Jivsov wrote: > > > > Let me explain my choices in this respect in the ECC proposal. > > > > We need 3DES as a fallback default to smoothly integrate ECC keys into > > existing installed base, as I mentioned earlier. > > Can you say more about this? I do not see any reason to > specify 3DES with ECC. > > (Yes, I know it is in RFC4880. I just don't know what that > has to do with a separate ECC proposal.) The argument has been that if we are to "add" ECC *onto* OpenPGP (which for the WG means "RFC4880") then we "MUST" implement 3DES. If we wanted to create an ECC-*only* standard or application then no 3DES would be fine, but it wouldn't be compliant with 4880 or (necessarily) interoperable with an OpenPGP application (which might only understand 3DES) or respectful of a user's [existing] key preferences. > We all know that 3DES should be retired in favour of AES. > This means, in principle, not to write it into any new > proposals, and smooth the way forward to let the > implementors phase it out. NIST have handled it this way: FIPS46-3 has been withdrawn. FIPS187 is the standard, which you are *encouraged* to use. 3DES has been taken out of FIPS46-3 and issued as a (lesser) "special recommendation". 3DES lifetime is until 2030. Therefore, NIST say 3DES is OK but that AES is the preferred choice. *We* (4880) say that 3DES is a MUST and that AES128 (and CAST5, which CSE are also OK with) are SHOULDs. *NSA*, meanwhile, say that for *classified* stuff you may use any of the AESes, but that for TOP SECRET you must use one of the larger. Further, they specify PK strengths, which at these lengths are ECC rather than absurdly big IFP/DLP RSA/DH ones. So, now that we are coming to implement ECC in OpenPGP, we naturally want to base things on the NIST/NSA guidelines, as well as considering implementation limitations and market requirements. We also have our OpenPGP history to take into account. So this means that have to support the 4880 MUSTs to remain compatible with current applications and user base. > The installed base is about private/public keys. They > *will* create the ECC keys any way you tell them. If you > don't tell them to set a preference for 3DES ... they won't > do it. > > Or have I got something wrong? that 3DES is an implied preference, even if not there. > >> 3DES is more of a "problem" - it's set to co-exist with AES until > >> 2030 (for US Fed.), and even if we obliterate 1024-160-80 crypto > >> we've still got 3DES as our OpenPGP vestigial tail. > > > > Sure. Leave it there in RFC4880. That's history. > > Or are you telling us that Suite B mandates 3DES??? no, Suite B doesn't mandate 3DES it doesn't. If we want to integrate into/with the current 4880 then 3DES needs to be in[herited in!] OpenPGP-ECC. I'm not "over-joyed" by this, but if my "longer keys are preferred" bit is added onto the "SHOULD try and match sym. and pub. key lengths" bit then that's about as near to the "encouraging" of AES over 3DES as we are likely to be able to get. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24FfcJe076740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 08:41:38 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m24Ffcbt076739; Tue, 4 Mar 2008 08:41:38 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from goten.sonance.net (goten.sonance.net [88.198.58.135]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24FfapA076731 for ; Tue, 4 Mar 2008 08:41:37 -0700 (MST) (envelope-from iang@systemics.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id B6C0557B17; Tue, 4 Mar 2008 16:41:35 +0100 (CET) Received: from goten.sonance.net ([127.0.0.1]) by localhost (goten.sonance.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlKUfFxkQ83Q; Tue, 4 Mar 2008 16:41:35 +0100 (CET) Received: from zhukov.local (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id 4DCFB57B0B; Tue, 4 Mar 2008 16:41:35 +0100 (CET) Message-ID: <47CD6DAE.9010409@systemics.com> Date: Tue, 04 Mar 2008 16:41:34 +0100 From: Ian G User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: "Daniel A. Nagy" , Andrey Jivsov , David Crick Subject: Re: ECC in OpenPGP proposal References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C7FDEA.5070103@systemics.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> In-Reply-To: <20080301090315.GB8868@epointsystem.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: OK, I think I found it. Sorry for not keeping up! Daniel A. Nagy wrote: > I think, Andrey makes a very important point here. The option to use 3DES > symmetric encryption, SHA1 digest and ZLIB compression must remain open until > a formal process of phasing them out is initiated, with a clear road map. > Right now, excluding these algorithms would break interoperability in a very > bad way, as described by Andrey. I disagree, below :) > Of course, SHA1 and 3DES are not without problems, but for most > security-critical applications they are still perfectly adequate. Right. The question is not about the security of the algorithms (which are more or less Pareto-secure-ish). Instead, it is about the business aspects of delivering the most security to the most people. > On Fri, Feb 29, 2008 at 09:36:11PM -0800, Andrey Jivsov wrote: >> David Crick wrote: >> ... >>> The ecc-pre-6.txt's section 2 pretty much says "this is how to >>> do ECC with AES," and we've said that this proposal is a "MAY." >>> In a sense this is therefore some kind of a fork (sub-superset?) >>> of 4880, so we're not concerned with 3DES (or CAST), and - as >>> with DSA - we can make specific restrictions in order to meet >>> compliance. Yes. This is a natural fork. It is for people who want Suite B. Which means the various USG organisations. Which before have not in the past been that impressed with OpenPGP. Actually, not impressed with anything in the open world, I'd say. We are really in new territory now that the NSA/NIST people have opened their hearts and declared Suite B. Which isn't to say that we shouldn't consider compatibility, but to say that this is a good, natural fork. We should also think about taking it... (I would. I remember the pain that was PGP 5.) >> I think we need to be careful here. Let's examine a use case. >> >> I am a user of some RFC 4880 OpenPGP application. All algorithms are >> available to me, e.g. I am not a government employee. >> >> * I use the application to encrypt mail to 5 recipients, my friends. >> They use RSA/DSA/ElGamal keys. >> >> * I upgraded the application to the next version that happened to >> implement "ECC in OpenPGP". >> >> I assume that we agree that if I encrypt to exactly the same 5 people >> with new version, as far as algorithm selection is concerned, the result >> is identical to the previous version. >> >> * I added 6th recipient to the list, which uses ECDH key. OK I see that. If... >> I hope we will agree that it must be possible to send single e-mail to 6 >> recipients. RFC 4880 specifies that the default encryption algorithm is >> 3DES, thus, there is always a match. Why shouldn't single e-mail be sent >> to 6 recipients with 3DES symmetric key? Sorry, I don't agree. The RFC4880 specification is only for applications that apply (more or less) to RFC4880! Applications that implement both RFC4880 *and* OpenPGP/ECC/Suite B are given no guarantee that this is likely to be seamless and joyful and without any degradation in their promised user experience. Just like S/MIME and RFC4880. To imagine otherwise would be to say that RFC4880's promise is that *all future work* is also compatible. That's hopeless. How far do we want to take that promise? OpenPGP quantum key exchange? What happens if the Russkies decide they want an OpenPGP GOST and they decide it is incompatible by definition with OpenPGP ECC? Or, we can retitle S/MIME as OpenPGP/S/Mime and insist on compatibility :) My point: It is *not* a given that people using OpenPGP Suite B can talk to people using RFC4880. Desirable, sure, but not a given. (I'd bet the NSA would prefer this *not* to be the case ;) Example: Consider properly written small-device platforms using the ECC stuff: They will likely implement the AES128-ECC-SHA "small" profile, and not include 3DES at all. The last thing anyone in the smart card / mobile world wants is incompatibility forced by vestigial circumstances. They want all *their* people talking, and that means one system, one algorithm. Talking to other people is a distant second in most business plans, and a controversial one at that. >> If the application is operating in Suite-B mode, or FIPS more, etc, then >> the situation is different. Yes, there are security ramifications. Are we really implementing Suite B if the application can leak info by sending out emails encrypted in Suite B (strong) and in 3DES to some 512 RSA key (not so strong)? iang Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24F2jAc072659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 08:02:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m24F2jkg072658; Tue, 4 Mar 2008 08:02:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from goten.sonance.net (goten.sonance.net [88.198.58.135]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24F2iOK072644 for ; Tue, 4 Mar 2008 08:02:44 -0700 (MST) (envelope-from iang@systemics.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id 0E12E57B17; Tue, 4 Mar 2008 16:02:41 +0100 (CET) Received: from goten.sonance.net ([127.0.0.1]) by localhost (goten.sonance.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yphsffn-jT5s; Tue, 4 Mar 2008 16:02:40 +0100 (CET) Received: from zhukov.local (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id 51CEF57B0B; Tue, 4 Mar 2008 16:02:40 +0100 (CET) Message-ID: <47CD648E.10705@systemics.com> Date: Tue, 04 Mar 2008 16:02:38 +0100 From: Ian G User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Andrey Jivsov CC: ietf-openpgp@imc.org, David Crick , "Daniel A. Nagy" Subject: Re: ECC in OpenPGP proposal References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C7FDEA.5070103@systemics.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <47CC7750.7080206@brainhub.org> In-Reply-To: <47CC7750.7080206@brainhub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Andrey Jivsov wrote: > > Let me explain my choices in this respect in the ECC proposal. > > We need 3DES as a fallback default to smoothly integrate ECC keys into > existing installed base, as I mentioned earlier. Can you say more about this? I do not see any reason to specify 3DES with ECC. (Yes, I know it is in RFC4880. I just don't know what that has to do with a separate ECC proposal.) We all know that 3DES should be retired in favour of AES. This means, in principle, not to write it into any new proposals, and smooth the way forward to let the implementors phase it out. The installed base is about private/public keys. They *will* create the ECC keys any way you tell them. If you don't tell them to set a preference for 3DES ... they won't do it. Or have I got something wrong? >> 3DES is more of a "problem" - it's set to co-exist with AES until >> 2030 (for US Fed.), and even if we obliterate 1024-160-80 crypto >> we've still got 3DES as our OpenPGP vestigial tail. Sure. Leave it there in RFC4880. That's history. Or are you telling us that Suite B mandates 3DES??? >> So maybe we can mangle ECC support so that we can still use >> 3DES with it,or maybe we need to crack on with V5, make it ECC >> only, and - as with the PGP 2 -> PGP 5 transition - have people >> run parallel apps (or send multiple messages) if they want to >> inter operate with 2048-3072-bit mod. non-ECC OpenPGP users. iang Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24EtZCC071675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 07:55:36 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m24EtZTp071674; Tue, 4 Mar 2008 07:55:35 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24EtYp8071668 for ; Tue, 4 Mar 2008 07:55:35 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by wf-out-1314.google.com with SMTP id 28so919796wff.28 for ; Tue, 04 Mar 2008 06:55:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=bStQoE/7PYO+5oz8HgYI1kk5BuA7+GEKxSQVsNpJ/Cw=; b=Bak20KbIK0BZSjZ+D/+kyFYyOPcfYqGZDIxD7mZejvTZU0NFzggfkiJlxlfFZp3gWNiob+PhXecXQ0ni/CqYhyAMwSLxRsojqjNoIaCOFqDgDvGHa3sMdbdyYubgflOn9k0886lwc9UyHJx7nCxpVHYw3VKPya8MByOUCK4bNqc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fP58sfmm9PezKwyOH5q9BPVqyBk11QTUFPu3jrMneIFVNVfCr/Fs8LwT8KFoKBabb4mw4JAhAwYGG7l1W0ir2yG2mPnKTCX3yHUoipQmR3YDu1F2MJAB/EAR86l+U77TAe4+6qHBq8tI/AK0H11na62frskJ6X5g4d7aeT9sykk= Received: by 10.142.222.21 with SMTP id u21mr557950wfg.41.1204642533770; Tue, 04 Mar 2008 06:55:33 -0800 (PST) Received: by 10.143.172.3 with HTTP; Tue, 4 Mar 2008 06:55:33 -0800 (PST) Message-ID: <117bad160803040655x3f393c7cuda72f361fbd119a4@mail.gmail.com> Date: Tue, 4 Mar 2008 14:55:33 +0000 From: "David Crick" To: ietf-openpgp@imc.org Subject: Re: ECC in OpenPGP proposal Cc: "Andrey Jivsov" In-Reply-To: <47CD0451.9000503@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <47CC7750.7080206@brainhub.org> <117bad160803031449p1efb03bao654561db48a5dbb2@mail.gmail.com> <47CD0451.9000503@brainhub.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 3/4/08, Andrey Jivsov wrote: > David Crick wrote: > >> We need 3DES as a fallback default to smoothly integrate ECC keys > >> into existing installed base, as I mentioned earlier. > >> > > > > then (reluctantly, but not violently against) how about: > > > > MAY implement ECC > > o MUST implement SHA256 > > o MUST implement ECC256 > > [ o MUST implement 3DES - directly inherited from 4880, like it or not] > > o MUST implement AES128 [or just inherit the SHOULD from 4880??] > > > > o SHOULD implement AES256-SHA512-521ECC > > o MAY implement AES256-SHA384-384ECC > > > > o SHOULD try to match cipher strength with ECC strength, where > > recipient key preferences allow. > > > > (then need to add wording in about restrictions required for if strict > > Suite B compliance is required.) > > > > > David, I agree with this. > > Assuming this is consensus, I will change section 11.1 to "MUST > implement curve with ID 1 and SHOULD implement curve with ID 3". Also in > section 11.1, I will change to "MUST implement SHA2-256 and should > implement SHA2-512,", dropping curve ID 2 and dropping SHA2-384 as MUST > for OpenPGP profile. this sounds like what what we've got to so far, although I note that this makes the [AES256-]SHA384-384ECC an *implicit* MAY rather than *specifically* mentioning SHA384 and ECC384 as MAYs. So, should we *explicitly* mention them? (also, an aside regarding repetition of a point I've previous made: the (e.g.) keywrapping text in -pre6 only talks about AES; this needs to be made more general, referring instead to keylengths.) > I will add a few sentences about Suite B and RFC4880 (in)compatibility. > The problems are very very similar to the issue of FIPS mode of > operation and RFC 4880. yes > Regarding algorithm tupples, Section 12 already lists > AES256-SHA512-521ECC and AES256-SHA384-384ECC as SHOULD combinations. the -pre6 document specifically lists P384-SHA384-AES192 in 12 (which, as per NIST, *are* the matching strengths), with the "MAY use stronger" in the paragraph before the table, but with the the AES256 (as per Suite B) in 11.2.2 before. All these pieces *together* allow for our discussed AES256-SHA384-384ECC combination, i.e. to support Suite B and to "drop" AES192. > I think it is better to break tupples into 3 pieces and address them > independently. Maybe it's because I haven't re-read the document as a whole with all our changes in place, but I'm personally finding it a bit hard to read our discussed cipher suggestions when they are split up as they currently are. Do you want to try producing a -pre7 so that we can see if we think it (a) matches our growing consensus and, (b) says it in a clear manner? If it does then great, otherwise some section, paragraph and topic re-ordering might be required. > The choice of symmetric algorithm is governed by key > preferences of (multiple) recipients. We shouldn't disregard preference > list and prefer AES-256 (even for ECC keys). 4880 section 13.2 says this: An implementation MUST NOT use a symmetric algorithm that is not in the recipient's preference list. When encrypting to more than one recipient, the implementation finds a suitable algorithm by taking the intersection of the preferences of the recipients. Note that the MUST-implement algorithm, TripleDES, ensures that the intersection is not null. *The implementation may use any mechanism to pick an algorithm in the intersection.* I suggest we *use* this freedom by (but!) tightening it in OpenPGP ECC applications. So, our ECC document would have something like: Having obtained an intersection of symmetric algorithm preferences, implementations SHOULD attempt to match symmetric algorithm size with public key size. [*Personally*, I'd like to continue: ", favouring longer lengths where possible."] The following table provides current equivalent recommendations (SP800-57). Note TripleDES is considered to have 112-bit security. Asymmetric | Hash | Symmetric | Elliptic key size | size | key size | curve key (RSA + D-H) | | | size ------------+--------+-------------------------- 1024 160 80 160 2048 224 112 224 3072 256 128 256 7680 384 192 384 15360 512 256 521 [the columns should probably be in a "better" order, this was just copied from 4800 with ECC then added on the end] > So section 11.1 tell > MUST/SHOULD for individual algorithms and section 12 gives SHOULD > recommendations regarding dependencies between algorithms. Subject to my "clarity" point above, then OK, yes, I can see this is how you are conveying this at present. > After above changes to section 11.1, the only missing correction there > is "SHOULD implement AES-256". yup. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m248C7Hb029492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 01:12:07 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m248C76c029490; Tue, 4 Mar 2008 01:12:07 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m248C5Tj029478 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 4 Mar 2008 01:12:06 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from localhost.localdomain (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by mail.cyberonic.com (8.12.8/8.12.8) with ESMTP id m248Dqo5015423; Tue, 4 Mar 2008 03:13:53 -0500 Message-ID: <47CD0451.9000503@brainhub.org> Date: Tue, 04 Mar 2008 00:12:01 -0800 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: David Crick Subject: Re: ECC in OpenPGP proposal References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <47CC7750.7080206@brainhub.org> <117bad160803031449p1efb03bao654561db48a5dbb2@mail.gmail.com> In-Reply-To: <117bad160803031449p1efb03bao654561db48a5dbb2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Crick wrote: >> We need 3DES as a fallback default to smoothly integrate ECC keys >> into existing installed base, as I mentioned earlier. >> > > then (reluctantly, but not violently against) how about: > > MAY implement ECC > o MUST implement SHA256 > o MUST implement ECC256 > [ o MUST implement 3DES - directly inherited from 4880, like it or not] > o MUST implement AES128 [or just inherit the SHOULD from 4880??] > > o SHOULD implement AES256-SHA512-521ECC > o MAY implement AES256-SHA384-384ECC > > o SHOULD try to match cipher strength with ECC strength, where > recipient key preferences allow. > > (then need to add wording in about restrictions required for if strict > Suite B compliance is required.) > David, I agree with this. Assuming this is consensus, I will change section 11.1 to "MUST implement curve with ID 1 and SHOULD implement curve with ID 3". Also in section 11.1, I will change to "MUST implement SHA2-256 and should implement SHA2-512,", dropping curve ID 2 and dropping SHA2-384 as MUST for OpenPGP profile. I will add a few sentences about Suite B and RFC4880 (in)compatibility. The problems are very very similar to the issue of FIPS mode of operation and RFC 4880. Regarding algorithm tupples, Section 12 already lists AES256-SHA512-521ECC and AES256-SHA384-384ECC as SHOULD combinations. I think it is better to break tupples into 3 pieces and address them independently. The choice of symmetric algorithm is governed by key preferences of (multiple) recipients. We shouldn't disregard preference list and prefer AES-256 (even for ECC keys). So section 11.1 tell MUST/SHOULD for individual algorithms and section 12 gives SHOULD recommendations regarding dependencies between algorithms. After above changes to section 11.1, the only missing correction there is "SHOULD implement AES-256". Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m23MnBi2077774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Mar 2008 15:49:11 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m23MnBC4077773; Mon, 3 Mar 2008 15:49:11 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m23MnAQK077767 for ; Mon, 3 Mar 2008 15:49:10 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by wf-out-1314.google.com with SMTP id 28so402485wff.28 for ; Mon, 03 Mar 2008 14:49:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=zvmjLW5kTiwZ7/sHpS7o29jyT5ZKSZzEVTKLV/b2HZM=; b=VEYLlJgjfSEPXkpKh/ubSx3/uDbhkZOI88l0AyhG2yjYK4HQBOiER6k6c6OQxyHaWuHg5NnidqOroi0jPOcoXrfLLCM34GjAeanjE0fD990G7xL7aTJrmYvaCkd4I2zmBPe7OCoD7verCEFuTKG1qPwb2iFVMxVTZ7tmZ5pJIpk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XNaf0AzoeA8AmZ5aoEEF/ko9i34mWy8JqzDy4whPgV4gKzonJ4JjxYvYZ8/EtsJNhb/2wcYoNqQnbhJnwNRwcWnjjrU7sSwHWsk0mUkQ7MFNoY5r91pwJIWijye9CnwOEiPajoDreH4v2KzkPpkxciijMF1Hy5Yc3T7pk/C+wjE= Received: by 10.142.213.9 with SMTP id l9mr395744wfg.104.1204584550053; Mon, 03 Mar 2008 14:49:10 -0800 (PST) Received: by 10.143.172.3 with HTTP; Mon, 3 Mar 2008 14:49:09 -0800 (PST) Message-ID: <117bad160803031449p1efb03bao654561db48a5dbb2@mail.gmail.com> Date: Mon, 3 Mar 2008 22:49:09 +0000 From: "David Crick" To: ietf-openpgp@imc.org Subject: Re: ECC in OpenPGP proposal Cc: "Andrey Jivsov" , "Daniel A. Nagy" In-Reply-To: <47CC7750.7080206@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> <47CC7750.7080206@brainhub.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > We need 3DES as a fallback default to smoothly integrate ECC keys > into existing installed base, as I mentioned earlier. then (reluctantly, but not violently against) how about: MAY implement ECC o MUST implement SHA256 o MUST implement ECC256 [ o MUST implement 3DES - directly inherited from 4880, like it or not] o MUST implement AES128 [or just inherit the SHOULD from 4880??] o SHOULD implement AES256-SHA512-521ECC o MAY implement AES256-SHA384-384ECC o SHOULD try to match cipher strength with ECC strength, where recipient key preferences allow. (then need to add wording in about restrictions required for if strict Suite B compliance is required.) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m23MAdfk074874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Mar 2008 15:10:39 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m23MAdXi074873; Mon, 3 Mar 2008 15:10:39 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from brainhub.org (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m23MAbpH074864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 3 Mar 2008 15:10:38 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from [63.251.255.221] (63-251-255-221.pgp.com [63.251.255.221] (may be forged)) by brainhub.org (8.14.2/8.14.1) with ESMTP id m23MATA4006750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Mar 2008 14:10:30 -0800 Message-ID: <47CC7750.7080206@brainhub.org> Date: Mon, 03 Mar 2008 14:10:24 -0800 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: David Crick , "Daniel A. Nagy" Subject: Re: ECC in OpenPGP proposal References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C7FDEA.5070103@systemics.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> In-Reply-To: <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Let me explain my choices in this respect in the ECC proposal. We need 3DES as a fallback default to smoothly integrate ECC keys into existing installed base, as I mentioned earlier. Fortunately, we are lucky with signatures. * We know that most of deployed applications support SHA-256 already, the code is written and tested. * We can assume that when an applications understands ECC keys, it understands SHA-256. * Although there are smartcard hardware vendors today that insist on exclusively using SHA-1, they only support RSA keys. (We hope their new release with ECC support will not have hardcoded 20 bytes + ASN.1 prefix size check.) It follows then that: ** Self-signatures can use SHA-256. (If an applications doesn't understand SHA-256, it doesn't understand ECC.) ** Because the key's self-signatures must be verified, data signatures and certifications with ECC keys can use SHA-256. ** Certifications on RSA/DSA keys with ECC keys can use SHA-256 too. ** Back signatures by subkeys can use SHA-256 too. So, SHA-1, which is too weak for any curve in this proposal, can be safely disallowed for generation or verification of signatures made by an ECC key. Applications should be tolerant to SHA-1 on other keys or existing structures. David Crick wrote: > On 3/1/08, Daniel A. Nagy wrote: > >> I think, Andrey makes a very important point here. The option to use 3DES >> symmetric encryption, SHA1 digest and ZLIB compression must remain open until >> a formal process of phasing them out is initiated, with a clear road map. >> Right now, excluding these algorithms would break interoperability in a very >> bad way, as described by Andrey. >> > > as someone said about alternative V5 key routes - let's absolutely > make sure we break it! > > >> Of course, SHA1 and 3DES are not without problems, but for most >> security-critical applications they are still perfectly adequate. >> > > SHA1 is due to be retired in 2010 (at least for US Federal agencies). > > That means 1024-bit DSA keys are due to demise soon. The most > recent bruteforce of RSA was on a "special" form of ~1024-bit keys > (2^1039 -1); no doubt the normal form will fall in the not too > considerable future. > > Germany has apparently said 1024-bit crypto is no longer allowed > as of 2008 (this was posted regarding OpenPGP smartcards on > one of the gnupg mailing lists). > > CSE say 80-bit ciphers will no longer be acceptable for Protected > A & B information from 2010 (for protected C it was 2005) and > that for A & B pk modulus 1024 will no longer be acceptable from > 2010 (again, for C it is already 2048 minimum). > > > The writing is on the wall for 1024 pks / 160 hashes / 80 ciphers! > > > That means our applications (and RFCs) need to be updated to > reflect this (*now!*; someone tell SSL web site maintainers...). > > 3DES is more of a "problem" - it's set to co-exist with AES until > 2030 (for US Fed.), and even if we obliterate 1024-160-80 crypto > we've still got 3DES as our OpenPGP vestigial tail. > > > So maybe we can mangle ECC support so that we can still use > 3DES with it, or maybe we need to crack on with V5, make it ECC > only, and - as with the PGP 2 -> PGP 5 transition - have people > run parallel apps (or send multiple messages) if they want to > inter operate with 2048-3072-bit mod. non-ECC OpenPGP users. > > ... Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m23LgH0G072916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Mar 2008 14:42:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m23LgHUL072915; Mon, 3 Mar 2008 14:42:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from brainhub.org (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m23LgFTj072908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 3 Mar 2008 14:42:16 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from [63.251.255.221] (63-251-255-221.pgp.com [63.251.255.221] (may be forged)) by brainhub.org (8.14.2/8.14.1) with ESMTP id m23Lg8wD006558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Mar 2008 13:42:09 -0800 Message-ID: <47CC70AB.5050909@brainhub.org> Date: Mon, 03 Mar 2008 13:42:03 -0800 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: "Daniel A. Nagy" Subject: Re: ECC in OpenPGP proposal References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C7FDEA.5070103@systemics.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> In-Reply-To: <20080301090315.GB8868@epointsystem.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel A. Nagy wrote: > I think, Andrey makes a very important point here. The option to use 3DES > symmetric encryption, SHA1 digest and ZLIB compression must remain open until > a formal process of phasing them out is initiated, with a clear road map. > Right now, excluding these algorithms would break interoperability in a very > bad way, as described by Andrey. > > Of course, SHA1 and 3DES are not without problems, but for most > security-critical applications they are still perfectly adequate. > > I agree. As a side note, it is a easier to deal with hashes, because the sender produces one signature data structure. Compare this with encryption when the sender may need to creates multiple ESK. I think we can disallow encoding with SHA-1 from this proposal without compatibility issues, but not RFC 4880 encryption algorithms. > Also note that prior to ECC, any symmetric cipher could have been matched > with any public key algorithm, because the secure block size for asymmetric > encryption algorithms (ElGamal and RSA) well exceeded the key sizes for > symmetric block ciphers. The encryption of session keys with random padding > has never been an issue. With ECC, this is no longer the case. For instance, > 256-bit AES keys won't fit into one ECC ElGamal blocks, which are otherwise > reasonably secure. Heck, even 3DES might be a little problematic, if 192-bit > curves are used. > I will note that current proposal doesn't have this limitation. It doesn't use ElGamal ECC. It uses key wrapping mechanism defined in RFC3394 for session key transport. I provided source code to see how the wrapping is done: http://brainhub.googlepages.com/aeswrap-RFC3394.c.html. > Finally, I would like to draw the group's attention to a special need of > moblie communication, that seems not to receive due attention. While it is > true that computational power is less and less of an issue with mobile > phones (although there are still plenty of under-powered devices in use and > even in production), the message size issue is here to stay for much longer. > In GSM networks, which are by far the most common around the globe, > peer-to-peer messaging between handsets is done in 1120-bit chunks, for > which operators charge money. Using an RFC4880-compliant format, even the > shortest message using reasonably strong asymmetric encryption (1024-bit > RSA), requires two chunks, which cost exactly twice as much for the sender > (and in some North-American setups even the recipient) as a regular text > message. Short public key and encrypted session key sizes of ECC may > actually prove to be the primary driving force behind its adoptation in the > mobile world, even if Moore's law renders low computational costs > irrelevant. > I agree. It is likely that many mobile vendors that entertained the idea of implementing OpenPGP passed on this format because of resource constrains. We will never know for sure, but we should attempt to give them another opportunity. OpenPGP makes a lot of sense for mobile communication. I paid special attention in this proposal to the size of per-message data structures, such as ESKs. I moved anything that can be moved from the per-message data structures into the public key. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m21DQ3ZT080419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Mar 2008 06:26:03 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m21DQ3Hb080418; Sat, 1 Mar 2008 06:26:03 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m21DQ2Dr080412 for ; Sat, 1 Mar 2008 06:26:02 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by wf-out-1314.google.com with SMTP id 28so4321324wff.28 for ; Sat, 01 Mar 2008 05:26:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=ofgnbfC9WiEADZRkVWTeyLY8hs/K8D4EIAOw6bE0X/A=; b=rQA7blW9mQ6VCgKH135oAUJsZhJovOGJUIfsPVGxcAqWLOrV18xx2FidlmGoO/JBDiI6L050T0/oVAIjeDGXYj/3AhXodRnQXIvcNgS/BI2PgxF1Ex6eRHFPAXtOry9JOpCApKZmcKPwGqZW7bH7X97Lq4oUKPtfVxBog5ycnfY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IVm/kpFiLoLHmfrfrAZWed/8gHas4BM035Agwx9mR+Syh/Qo7B8oNgluP6qrCaysnFnhL7pY9soV+mSRrEIhF8umCuvzUWEAW2h++MqpesU9ePZGu6+dd2U5VSPLRLL8K3/BrPooAn7pBmGPs72dOrasBP3GDqA7nZ3B5RCfOGQ= Received: by 10.142.49.4 with SMTP id w4mr795264wfw.57.1204377962038; Sat, 01 Mar 2008 05:26:02 -0800 (PST) Received: by 10.143.172.3 with HTTP; Sat, 1 Mar 2008 05:26:01 -0800 (PST) Message-ID: <117bad160803010526l4f8779bfue2453cc250b38676@mail.gmail.com> Date: Sat, 1 Mar 2008 13:26:01 +0000 From: "David Crick" To: ietf-openpgp@imc.org Subject: Re: ECC in OpenPGP proposal Cc: "Andrey Jivsov" , "Daniel A. Nagy" In-Reply-To: <20080301090315.GB8868@epointsystem.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C7FDEA.5070103@systemics.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> <20080301090315.GB8868@epointsystem.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 3/1/08, Daniel A. Nagy wrote: > I think, Andrey makes a very important point here. The option to use 3DES > symmetric encryption, SHA1 digest and ZLIB compression must remain open until > a formal process of phasing them out is initiated, with a clear road map. > Right now, excluding these algorithms would break interoperability in a very > bad way, as described by Andrey. as someone said about alternative V5 key routes - let's absolutely make sure we break it! > Of course, SHA1 and 3DES are not without problems, but for most > security-critical applications they are still perfectly adequate. SHA1 is due to be retired in 2010 (at least for US Federal agencies). That means 1024-bit DSA keys are due to demise soon. The most recent bruteforce of RSA was on a "special" form of ~1024-bit keys (2^1039 -1); no doubt the normal form will fall in the not too considerable future. Germany has apparently said 1024-bit crypto is no longer allowed as of 2008 (this was posted regarding OpenPGP smartcards on one of the gnupg mailing lists). CSE say 80-bit ciphers will no longer be acceptable for Protected A & B information from 2010 (for protected C it was 2005) and that for A & B pk modulus 1024 will no longer be acceptable from 2010 (again, for C it is already 2048 minimum). The writing is on the wall for 1024 pks / 160 hashes / 80 ciphers! That means our applications (and RFCs) need to be updated to reflect this (*now!*; someone tell SSL web site maintainers...). 3DES is more of a "problem" - it's set to co-exist with AES until 2030 (for US Fed.), and even if we obliterate 1024-160-80 crypto we've still got 3DES as our OpenPGP vestigial tail. So maybe we can mangle ECC support so that we can still use 3DES with it, or maybe we need to crack on with V5, make it ECC only, and - as with the PGP 2 -> PGP 5 transition - have people run parallel apps (or send multiple messages) if they want to inter operate with 2048-3072-bit mod. non-ECC OpenPGP users. > Also note that prior to ECC, any symmetric cipher could have been matched > with any public key algorithm, because the secure block size for asymmetric > encryption algorithms (ElGamal and RSA) well exceeded the key sizes for > symmetric block ciphers. The encryption of session keys with random padding > has never been an issue. With ECC, this is no longer the case. For instance, > 256-bit AES keys won't fit into one ECC ElGamal blocks, which are otherwise > reasonably secure. Heck, even 3DES might be a little problematic, if 192-bit > curves are used. > > Finally, I would like to draw the group's attention to a special need of > moblie communication, that seems not to receive due attention. While it is > true that computational power is less and less of an issue with mobile > phones (although there are still plenty of under-powered devices in use and > even in production), the message size issue is here to stay for much longer. > In GSM networks, which are by far the most common around the globe, > peer-to-peer messaging between handsets is done in 1120-bit chunks, for > which operators charge money. Using an RFC4880-compliant format, even the > shortest message using reasonably strong asymmetric encryption (1024-bit > RSA), requires two chunks, which cost exactly twice as much for the sender > (and in some North-American setups even the recipient) as a regular text > message. Short public key and encrypted session key sizes of ECC may > actually prove to be the primary driving force behind its adoptation in the > mobile world, even if Moore's law renders low computational costs > irrelevant. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m21CiOu5075359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Mar 2008 05:44:24 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m21CiOro075358; Sat, 1 Mar 2008 05:44:24 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m21CiNMF075352 for ; Sat, 1 Mar 2008 05:44:24 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by wf-out-1314.google.com with SMTP id 28so4302920wff.28 for ; Sat, 01 Mar 2008 04:44:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Klvn1HOv+K9p/TGxgJ9JUzV86fRRNDOYMbMxxG9v8cc=; b=cWbYSnrqG1oLZDFo3ExXKAGldoXNU9DDEapridD1DvyE3aSbtmdbXQQuhJXv0CoNbe/2Shjop5p3nKiTj7dL/7NbaslNlUXaX1g3xb8gbljPDCpkBVcNM2HxgZSicw9yO6XygmSbYd4OHLgIdToWF/DWzV7kI0Zso2qulBcXvgw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uYloaQzddwWe04D9XMIowOpLIYHlkJXKDKym+77FAUDBlYc39XjxXS6TNJ3YHHm0suI1g+trm/MNcFNHluje2fdjZhdPvCBPhI7+j5vG/2i0v/a88y2ySW2ho1LsEa4yu3C/ZNtoBXYHOOa6KDkvwYmNEH816Zr0ofHGiVRAMYA= Received: by 10.142.89.9 with SMTP id m9mr7695511wfb.35.1204375463094; Sat, 01 Mar 2008 04:44:23 -0800 (PST) Received: by 10.143.172.3 with HTTP; Sat, 1 Mar 2008 04:44:23 -0800 (PST) Message-ID: <117bad160803010444l6fd5732fsc8d92e282a16c72d@mail.gmail.com> Date: Sat, 1 Mar 2008 12:44:23 +0000 From: "David Crick" To: ietf-openpgp@imc.org Subject: Re: ECC in OpenPGP proposal Cc: "Andrey Jivsov" In-Reply-To: <47C8EB4B.9010909@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C7FDEA.5070103@systemics.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 3/1/08, Andrey Jivsov wrote: > David Crick wrote: > > The ecc-pre-6.txt's section 2 pretty much says "this is how to > > do ECC with AES," and we've said that this proposal is a "MAY." > > In a sense this is therefore some kind of a fork (sub-superset?) > > of 4880, so we're not concerned with 3DES (or CAST), and - as > > with DSA - we can make specific restrictions in order to meet > > compliance. (further to my point above, if we really want ECC to support 3DES then the ECC document needs to be updated for that) > I think we need to be careful here. Let's examine a use case. > > I am a user of some RFC 4880 OpenPGP application. All algorithms are > available to me, e.g. I am not a government employee. > > * I use the application to encrypt mail to 5 recipients, my friends. > They use RSA/DSA/ElGamal keys. > > * I upgraded the application to the next version that happened to > implement "ECC in OpenPGP". > > I assume that we agree that if I encrypt to exactly the same 5 people > with new version, as far as algorithm selection is concerned, the result > is identical to the previous version. > > * I added 6th recipient to the list, which uses ECDH key. > > I hope we will agree that it must be possible to send single e-mail to 6 > recipients. RFC 4880 specifies that the default encryption algorithm is > 3DES, thus, there is always a match. Why shouldn't single e-mail be sent > to 6 recipients with 3DES symmetric key? I use PGP 2.6, I upgrade to PGP 5.0. Shiny new DH/DSS keys - but no RSA support! Until the RSA patent expired (well, was placed prematurely into the public domain) we ran parallel systems and/or kept "old" and "new" keys. Even now with 3DES as a must, we have this delightful phrase in 4880: "Implementations MUST implement TripleDES. Implementations SHOULD implement AES-128 and CAST5. Implementations that interoperate with PGP 2.6 or earlier *need to* support IDEA, as that is the only symmetric cipher those versions use. Implementations MAY implement any other algorithm." "need to"! But, NB, "might not be able to" - due to the IDEA patent. I seem to recall one of the PGP (5+) versions popping up a message about mixed V3/V4 (or RSA/DH) keys when I attempted to encrypt something (or maybe it was due to an IDEA/3DES conflict). (Maybe Jon can confirm my vague recollections here?) > If the application is operating in Suite-B mode, or FIPS more, etc, then > the situation is different. right. > RFC 4880 currently grants to a user of embedded device a method to say > "don't do AES-256 to me" by using cipher preferences that exclude AES > 256. We should respect this. We cannot change the fact that there are > hardware platforms that don't implement or don't like AES 256. OK, but they SHOULD support AES-128 (which would make a 128-256-256 ECC MUST not seem absolutely unworkable). Question: how "interoperable" do these "embedded devices" need to be with the rest of the world? Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m21AYKxr058091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Mar 2008 03:34:20 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m21AYKIh058090; Sat, 1 Mar 2008 03:34:20 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m21AYIme058077 for ; Sat, 1 Mar 2008 03:34:19 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id C23304AAE; Sat, 1 Mar 2008 11:30:14 +0100 (CET) Date: Sat, 1 Mar 2008 11:30:14 +0100 To: ietf-openpgp@imc.org Subject: Thoughts and suggestions on V5 key format Message-ID: <20080301103008.GC8868@epointsystem.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="t0UkRYy7tHLRMCai" Content-Disposition: inline User-Agent: Mutt/1.5.9i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --t0UkRYy7tHLRMCai Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable As noted earlier, there are many problems with V4 public and private key formats that merit the consideration of a new key format (V5). This message is intended as a list of the problems and solutions that come to my mind in order to initiate a discussion that would hopefully lead to a sound design that can be standardized. 1. Private key format 1.1. Purpose I think, it should be explicitly stated that private key packet format is specified solely for the purpose of exporting and importing private keys. While implementations may choose to store private keys in this format, as it has no bearing on interoperability, it is outside the scope of the standard. 1.2. Structure The straightforward structure of public key material followed by private key material is fine, but the symmetrically encrypted private key material must be ditched, in my opinion. For confidentiality protection, the entire private key packet (including both public and private key material) must be encapsulated in a symmetrically encrypted and integrity protected packet (with an optional compression in between). This has several benefits: it prevents the Klima-Rosa attack, removes the need to define and implement symmetric encryption twice in slightly different ways, etc. For RSA keys, facilities for the multiprime variant must be included. Public keys with two or more prime factors should not be distinguished, though. 2. Fingerprints and Key IDs 2.1. Hashed material I think that only the key material and the algorithm identifier should influence the fingerprint; creation time should not, because it may not be readily available even if the public key is. However, I like the feature of V4 that the fingerprint is simply the hash of a canonized public key packet. Thus, I would recommend removing creation time from the public key packet altogether. This approach would facilitate (partial) interoperability with hardware and software not specifically designed for OpenPGP, as OpenPGP fingerprints and key IDs can then be calculated for any public key, no matter where it comes =66rom. 2.2. String representation Key IDs should be either decimal or octal. There are many crypto-capable devices with numeric-only keypads (e.g. cellphones). It would be very nice if key IDs could be conveniently typed on such devices. As an added benefit, it would reinforce the metaphor of the KeyID being something similar to a phone number, making it a good shot at the middle of Zooko's triangle. Since the key id being part of the fingerprint is a nice feature, fingerprints may also be decimal or octal, respectively. We could also blur the boundary between fingerprints and key ID by allowing the use of any sufficiently long (e.g. 10 decimal or 11 octal digits) suffix of the fingerprint as a key identifier (which is not necessarily unique, of course). 2.3. Hash function There should be only one, because the fingerprint must uniquely identify the corresponding key; there shouldn't be different fingerprints for the same key. Increasing the length of the fingerprint reduces its usability. Again, I would suggest the blurring of the boundary between fingerprints and key IDs, as above. Thus, we could use some super-safe hash function (e.g. SHA-512), but use only a sufficiently long tail for practical purposes. Regards, --=20 Daniel --t0UkRYy7tHLRMCai Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iQDVAwUBR8kwL9lNfsjr6fBFAQKhlgYArjjVXkmXe1lDJhDML+M/z6iZ57N1b4r2 cIjXA/+6wyMI80dAl7ZDv6d7tg0sMVwJk1mt26cWxx86jzgljRfznFOFY2JKbthv PHuSKKMWw3h2CtioNsJWKnK9fKkaH9W+FnFqu4IjUk+caoCpM4fRGYFqNKKpGF48 nGyCB+nVKmG5SFAt+fbkR3RipUwUs2W8gZdrazj+WfR7bH3k4GIn39KmOiJcI8ll uxqB+hJ2eCdUU3b+DZtDUjjXSjiWxPRD =y739 -----END PGP SIGNATURE----- --t0UkRYy7tHLRMCai-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m2197KXX049575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Mar 2008 02:07:20 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m2197K8h049574; Sat, 1 Mar 2008 02:07:20 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m2197I0S049566 for ; Sat, 1 Mar 2008 02:07:19 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 988604A95; Sat, 1 Mar 2008 10:03:15 +0100 (CET) Date: Sat, 1 Mar 2008 10:03:15 +0100 To: Andrey Jivsov Cc: ietf-openpgp@imc.org, David Crick Subject: Re: ECC in OpenPGP proposal Message-ID: <20080301090315.GB8868@epointsystem.org> References: <117bad160802281102q315f490di4344ec5af6c05620@mail.gmail.com> <47C7FDEA.5070103@systemics.com> <117bad160802290516u4c204142n6427d5fccb6a60f4@mail.gmail.com> <47C82549.8080703@systemics.com> <117bad160802290820x4050e635kaf6d6d637149c4a9@mail.gmail.com> <47C8777F.2020702@brainhub.org> <117bad160802291622p5a2acab6obf56c8cce54aed2d@mail.gmail.com> <47C8EB4B.9010909@brainhub.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V0207lvV8h4k8FAm" Content-Disposition: inline In-Reply-To: <47C8EB4B.9010909@brainhub.org> User-Agent: Mutt/1.5.9i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --V0207lvV8h4k8FAm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I think, Andrey makes a very important point here. The option to use 3DES symmetric encryption, SHA1 digest and ZLIB compression must remain open unt= il a formal process of phasing them out is initiated, with a clear road map. Right now, excluding these algorithms would break interoperability in a very bad way, as described by Andrey. Of course, SHA1 and 3DES are not without problems, but for most security-critical applications they are still perfectly adequate. Also note that prior to ECC, any symmetric cipher could have been matched with any public key algorithm, because the secure block size for asymmetric encryption algorithms (ElGamal and RSA) well exceeded the key sizes for symmetric block ciphers. The encryption of session keys with random padding has never been an issue. With ECC, this is no longer the case. For instance, 256-bit AES keys won't fit into one ECC ElGamal blocks, which are otherwise reasonably secure. Heck, even 3DES might be a little problematic, if 192-bit curves are used. Finally, I would like to draw the group's attention to a special need of moblie communication, that seems not to receive due attention. While it is true that computational power is less and less of an issue with mobile phones (although there are still plenty of under-powered devices in use and even in production), the message size issue is here to stay for much longer. In GSM networks, which are by far the most common around the globe, peer-to-peer messaging between handsets is done in 1120-bit chunks, for which operators charge money. Using an RFC4880-compliant format, even the shortest message using reasonably strong asymmetric encryption (1024-bit RSA), requires two chunks, which cost exactly twice as much for the sender (and in some North-American setups even the recipient) as a regular text message. Short public key and encrypted session key sizes of ECC may actually prove to be the primary driving force behind its adoptation in the mobile world, even if Moore's law renders low computational costs irrelevant. On Fri, Feb 29, 2008 at 09:36:11PM -0800, Andrey Jivsov wrote: >=20 > David Crick wrote: > ... > > > >The ecc-pre-6.txt's section 2 pretty much says "this is how to > >do ECC with AES," and we've said that this proposal is a "MAY." > >In a sense this is therefore some kind of a fork (sub-superset?) > >of 4880, so we're not concerned with 3DES (or CAST), and - as > >with DSA - we can make specific restrictions in order to meet > >compliance. >=20 > I think we need to be careful here. Let's examine a use case. >=20 > I am a user of some RFC 4880 OpenPGP application. All algorithms are=20 > available to me, e.g. I am not a government employee. >=20 > * I use the application to encrypt mail to 5 recipients, my friends.=20 > They use RSA/DSA/ElGamal keys. >=20 > * I upgraded the application to the next version that happened to=20 > implement "ECC in OpenPGP". >=20 > I assume that we agree that if I encrypt to exactly the same 5 people=20 > with new version, as far as algorithm selection is concerned, the result= =20 > is identical to the previous version. >=20 > * I added 6th recipient to the list, which uses ECDH key. >=20 > I hope we will agree that it must be possible to send single e-mail to 6= =20 > recipients. RFC 4880 specifies that the default encryption algorithm is= =20 > 3DES, thus, there is always a match. Why shouldn't single e-mail be sent= =20 > to 6 recipients with 3DES symmetric key? >=20 > If the application is operating in Suite-B mode, or FIPS more, etc, then= =20 > the situation is different. >=20 > > > >Dependant on the "low spec" argument/evidence, we could just > >make one of the larger curve-hash pairs as the MUST, and make > >AES256 as the must cipher. Then if we need to encrypt to one > >of the two bigger curves *and* a smaller curve then we just > >"up" the cipher to AES256 for the small curve recipient. >=20 > RFC 4880 currently grants to a user of embedded device a method to say=20 > "don't do AES-256 to me" by using cipher preferences that exclude AES=20 > 256. We should respect this. We cannot change the fact that there are=20 > hardware platforms that don't implement or don't like AES 256. --V0207lvV8h4k8FAm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iQDVAwUBR8kb0tlNfsjr6fBFAQKjrwX+NzA41sPlgcox94sp1JcreQW93wjawLLH bS/LeScya9eeOG9uQheVZ9d+JTN/1HDfioHQuEAAg2gBKbZ49l2GvPv6FVhZJCpT yzrO4UO/qwgqMA0SS81gU2jHtjmgbEYcw7m6MscJc4nbXRLxXGlhTbJHduNVhEcy gks6pqkuiCwvRpe6gFKt02DrtTR0JB0gKbd0NJlLs/FXwdO2crR+KvFjn8x0xENE eqBg6wIiwuMvvwvuVy0uKACswGc8SIFV =K1tq -----END PGP SIGNATURE----- --V0207lvV8h4k8FAm--