From infinity0@gmx.com Tue Jul 2 16:22:33 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C758C21F9A64 for ; Tue, 2 Jul 2013 16:22:33 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zA92iv0013Mk for ; Tue, 2 Jul 2013 16:22:29 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id D450321F9A71 for ; Tue, 2 Jul 2013 16:22:27 -0700 (PDT) Received: from [192.168.1.193] ([86.146.201.131]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MADqP-1V4rGt2ywz-00BKpz for ; Wed, 03 Jul 2013 01:22:26 +0200 Message-ID: <51D360B2.1070709@gmx.com> Date: Wed, 03 Jul 2013 00:22:26 +0100 From: Ximin Luo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130518 Icedove/17.0.5 MIME-Version: 1.0 To: openpgp@ietf.org X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2VAOLFNADWSFUDNFALFUN" X-Provags-ID: V03:K0:rGhrqN2PAPI9A1x600EFUV96ykGeVUbtnlpLaLvO4rSW+t2TJ40 g1N+Gny7Ih6y9i4yJWyfqInsSQDFtjv5D/McBBiz7fMIcrWfVgdVVF1sPZKYTq/KTrkvkVW EnFM6eaB5qW3oc7nmnvgNXDqDGAikeVbzwXfhzN66j3OTErwgFMRZEFUqSLOZIhdCrV71Li CFKY+ny3y8re1hypYycHw== Subject: [openpgp] signed/encrypted emails vs unsigned/unencrypted headers X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 23:25:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2VAOLFNADWSFUDNFALFUN Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To openpgp@ietf.org, As per [1] and [2], sign-then-encrypt is only really secure as long as yo= u do it on *all* the information that forms the message, some of which might b= e external to the message data itself. Crucially, this includes the recipie= nt. What's the current status of this in the PGP/MIME standard? Is it still a= problem? I notice that email subject headers are in a similar situation, = and users have complained about it.[3] The problem of unencrypted/unauthentic= ated recipient is less obvious, so I haven't seen user complaints, but potenti= ally it is more serious. Although not explicitly mentioned in the previous citations, these are conceptually the same problem - i.e. you are only executing sign-then-enc= rypt on *part* of the data that should be secured. So, I believe that it's pos= sible to work towards a single clean solution that fixes both problems. (Sorry if this has been asked before already, or if the problem has alrea= dy been fixed; I did check the list archives but couldn't find anything on a= quick scan, nor a quick session of web searching.) X [1] http://crypto.stackexchange.com/questions/5458/should-we-sign-then-encryp= t-or-encrypt-then-sign [2] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html#CITEpgp [3] http://www.mozilla-enigmail.org/forum/viewtopic.php?f=3D9&t=3D328 --=20 GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0 ------enig2VAOLFNADWSFUDNFALFUN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJR02CyAAoJEIYN7zuPZQt5j3wP/2VLAKLoSi5P33oK2ImmgIwf DE1LkMLDOccp70ybyokBB/NxCzGzYLm0o/2PpNITyQU1alwZFpthVBnJ4tflJNcq 1KGC0fpt3VrmmMk1FmgOaA4BuIM8BCccSv67JKwCp9A+UwjKXeSjphJtdezRn4Di 0BSa32x2cweLgJrpK3PxPI3zoaxDGbeDdpKTPb7d7UzXW65f9IcVRczyf/q2TOLp DpUKgLpok2PiIVZyb9FX/37YHYyWS6ogQBJ+p9ZBrIFG8DBBnd/mDheaEVv/QbGM D8NW85IYBFVN3LQo0hXlM+GKObxrmLDch3XY7BXrt7yiTxBizDsbv+ROXaMWJ/g6 TXSmSo1zDZcow3+AyqWH6ZlGdvM45LdFR8exLCGWZlKbkN0DSOftuGLaKg9BTqmG p0AKyY6Q5FfbKPNbqgkQXLMGu0Ff6x1UW0VEB6WSFmvBxviAj2qJHHM+M6CJI4bL RdrN0/e7bioXFc9JQpTwDFfK4vXMPOXws9Tj9WYJEdP7iVyJ1ngDPCYbMLd/3KQv dmDUfsVI8Rm/3TboCtBDxDY6+rc/49SrAIe9zQDqe3T7mom8618aiPtX+Utexd2a enoro4loyRziTjGN5NPduZp52daz55RmKvcRA8PZ6vY2l7PRAEAkR3mCQnreCcN8 iyZgxPHA5FkB3dZtGeuL =Tf0D -----END PGP SIGNATURE----- ------enig2VAOLFNADWSFUDNFALFUN-- From paul@nohats.ca Mon Jul 15 15:33:31 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8198511E81AD for ; Mon, 15 Jul 2013 15:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhVlL1k6Y-8H for ; Mon, 15 Jul 2013 15:33:15 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5214111E822A for ; Mon, 15 Jul 2013 15:32:55 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3bvKJ16lbSz5XC for ; Mon, 15 Jul 2013 18:32:49 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id p-oO5CfPJFso for ; Mon, 15 Jul 2013 18:32:48 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP for ; Mon, 15 Jul 2013 18:32:47 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 89573817DB; Mon, 15 Jul 2013 18:32:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7E189817D7 for ; Mon, 15 Jul 2013 18:32:48 -0400 (EDT) Date: Mon, 15 Jul 2013 18:32:46 -0400 (EDT) From: Paul Wouters To: openpgp@ietf.org Message-ID: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [openpgp] Fwd: New Version Notification for draft-wouters-dane-openpgp-00.txt (fwd) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 22:33:31 -0000 I've submitted a draft to associate an PGP public key with an email address using DANE. Paul A new version of I-D, draft-wouters-dane-openpgp-00.txt has been successfully submitted by Paul Wouters and posted to the IETF repository. Filename: draft-wouters-dane-openpgp Revision: 00 Title: Using DANE to Associate OpenPGP public keys with email addresses Creation date: 2013-07-15 Group: Individual Submission Number of pages: 11 URL: http://www.ietf.org/internet-drafts/draft-wouters-dane-openpgp-00.txt Status: http://datatracker.ietf.org/doc/draft-wouters-dane-openpgp Htmlized: http://tools.ietf.org/html/draft-wouters-dane-openpgp-00 Abstract: OpenPGP is a message format for email (and file) encryption, that lacks a standarized secure lookup mechanism to obtain OpenPGP public keys. This document specifies a standarized method for securely publishing and locating OpenPGP public keys in DNS using a new OPENPGPKEY DNS Resource Record. The IETF Secretariat _______________________________________________ dane mailing list dane@ietf.org https://www.ietf.org/mailman/listinfo/dane From openpgp@brainhub.org Mon Jul 15 16:20:31 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C4511E8264 for ; Mon, 15 Jul 2013 16:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W76vRVf2NtdG for ; Mon, 15 Jul 2013 16:20:23 -0700 (PDT) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id 388DE11E8258 for ; Mon, 15 Jul 2013 16:20:23 -0700 (PDT) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta01.emeryville.ca.mail.comcast.net with comcast id 0nB81m0031zF43QA1nLNgw; Mon, 15 Jul 2013 23:20:22 +0000 Received: from [127.0.0.1] ([69.181.162.123]) by omta24.emeryville.ca.mail.comcast.net with comcast id 0nLL1m00l2g33ZR8knLM1W; Mon, 15 Jul 2013 23:20:22 +0000 Message-ID: <51E482E5.5020201@brainhub.org> Date: Mon, 15 Jul 2013 16:16:53 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: openpgp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373930422; bh=Hz2521is7wXgvjQ7BbEfpS9c455DPgFG7aK9kyovTMc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=a+fwvQuelQCCQNRr17gkobtO3TletJMY+9vCwfjLZ6CaKpA4+7shGjdhKhsvjFjQh KFe9cJuSPZBl03274lUdtikvP2TFB1ErkAty8OFv1kG4X63pSYJkr/9T9xLRZ1iCjw ETSd6Hzx/Ks2QmsRHrM0PhtpWwJ2lv/C8i9R4aJuAD8Q+OK+YrmEPeKYxJlBlnt0sC dMrtARzSDjmUIVdaxX1qXcW1xaNw6f5uu20Ug7BdFaXyMRysss2iU9PcZ1GvDkO5AW c69xZfkHBcrpcSaz5onmLS0sMFf8hIjPoqtfc1L6zCrz10Q4tm7dOE0N7kDcYGuRoV m7/k8IfyfM4cg== Cc: Paul Wouters Subject: Re: [openpgp] Fwd: New Version Notification for draft-wouters-dane-openpgp-00.txt (fwd) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 23:20:31 -0000 A few quick comments follow. 1. > Currently deployed key servers have no method of validating any > uploaded OpenPGP public key. The key servers simply store and > publish. Anyone can add public keys with any name or email address > and anyone can add signatures to any other public key using forged > malicious identities. For example, bogus keys of prominent > dissidents have been uploaded to these well-known key servers in > attempts to capture encrypted email. Furthermore, once uploaded, > public keys cannot be deleted. People who did not pre-sign a key > revocation and who have lost access to their private key can never > remove their public key from these key servers. This ignores prior work in this area. https://keyserver.pgp.com is known to solve exactly the problems you described for many years now. 2. Given that the size of the record is very important when stored in DNS records, it's odd to see that ECC OpenPGP keys are not even mentioned. In fact, given that we are talking about a new format here, one can see many benefits of standardizing *only* on ECC keys or at least preferring/encouraging ECC keys. I think you raise a valid concern that keys placed in DNS records should be "cleaned". A 4096 bit RSA key with 10 subkeys and 3d party signatures seems excessive. I planned to introduce the compact key format http://tools.ietf.org/html/draft-jivsov-ecc-compact soon to OpenPGP. This might be a mandatory tweak to further minimize the size for ECC keys when stored in DNS records. 3. I suspect that "4.6. Subject: line encryption" is prone to bugs for complex messages with multiple MIME parts. It probably needs more work to be acceptable. On 07/15/2013 03:32 PM, Paul Wouters wrote: > > I've submitted a draft to associate an PGP public key with an email > address using DANE. > > Paul > > > > A new version of I-D, draft-wouters-dane-openpgp-00.txt > has been successfully submitted by Paul Wouters and posted to the > IETF repository. > > Filename: draft-wouters-dane-openpgp > Revision: 00 > Title: Using DANE to Associate OpenPGP public keys with email > addresses > Creation date: 2013-07-15 > Group: Individual Submission > Number of pages: 11 > URL: > http://www.ietf.org/internet-drafts/draft-wouters-dane-openpgp-00.txt > Status: http://datatracker.ietf.org/doc/draft-wouters-dane-openpgp > Htmlized: http://tools.ietf.org/html/draft-wouters-dane-openpgp-00 > > > Abstract: > OpenPGP is a message format for email (and file) encryption, that > lacks a standarized secure lookup mechanism to obtain OpenPGP public > keys. This document specifies a standarized method for securely > publishing and locating OpenPGP public keys in DNS using a new > OPENPGPKEY DNS Resource Record. > > > > > The IETF Secretariat ... From paul@nohats.ca Mon Jul 15 19:02:05 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0AD11E819A for ; Mon, 15 Jul 2013 19:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.704 X-Spam-Level: X-Spam-Status: No, score=-2.704 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTv8y2ryGMBi for ; Mon, 15 Jul 2013 19:02:01 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE3B11E817B for ; Mon, 15 Jul 2013 19:02:00 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3bvPxJ6lVlz72B; Mon, 15 Jul 2013 22:01:56 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id fkJNRA4VE-Ip; Mon, 15 Jul 2013 22:01:56 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Mon, 15 Jul 2013 22:01:55 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id D3F06817DB; Mon, 15 Jul 2013 22:01:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C6F0F817D7; Mon, 15 Jul 2013 22:01:55 -0400 (EDT) Date: Mon, 15 Jul 2013 22:01:55 -0400 (EDT) From: Paul Wouters To: Andrey Jivsov In-Reply-To: <51E482E5.5020201@brainhub.org> Message-ID: References: <51E482E5.5020201@brainhub.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: openpgp@ietf.org Subject: Re: [openpgp] Fwd: New Version Notification for draft-wouters-dane-openpgp-00.txt (fwd) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 02:02:05 -0000 On Mon, 15 Jul 2013, Andrey Jivsov wrote: > A few quick comments follow. Thanks for the comments. > This ignores prior work in this area. https://keyserver.pgp.com is known to > solve exactly the problems you described for many years now. Ahh, yet another different webgui? I see the howto also states "You can only remove your own key and the email address must match exactly". I had one of my email addresses yanked two years ago with zero notice. I would not have been able to remove my key. But even so, many (most?) people still seem to use other more well known, non-commercial, keyservers, such as pgp.mit.edu and pgp.surfnet.nl. Even if I use very secure key servers, if people look for my key on crappy old key servers, the risk remains. > 2. Given that the size of the record is very important when stored in DNS > records, it's odd to see that ECC OpenPGP keys are not even mentioned. I specifically did not want to limit the record to any particular type. I just wanted it to support RFC OpenPGP compliant keys. Some people don't want to use ECC (for legal other other reasons). Others don't want to use ElGamal, DSA, RSA, etc. There is no reason for this draft to distinguish and force people to pick a specific key type. > In > fact, given that we are talking about a new format here, one can see many > benefits of standardizing *only* on ECC keys or at least > preferring/encouraging ECC keys. There is no new format of public key. Only a base32 encoding for an existing format. The base32 is there only not cause problems with DNS (and the LHS needs to use base32, so it seemed prudent to make the RHS also use base32) > I think you raise a valid concern that keys placed in DNS records should be > "cleaned". A 4096 bit RSA key with 10 subkeys and 3d party signatures seems > excessive. Though still doable. DNSSEC has forced a lot of cleanup of the port 53 TCP path. While I think it is still better to try and keep things small, I don't think it poses a big problem anymore. > 3. I suspect that "4.6. Subject: line encryption" is prone to bugs for > complex messages with multiple MIME parts. It probably needs more work to be > acceptable. I do feel it is a little out of place, but it's such a simple thing to do, I wonder why this isn't being done by existing PGP clients and plugins already. Perhaps it can be rewritten as more of an "informative hint". Paul From wk@gnupg.org Mon Jul 15 23:14:46 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4134021E81B1 for ; Mon, 15 Jul 2013 23:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2h9-G4+bWy3j for ; Mon, 15 Jul 2013 23:14:41 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by ietfa.amsl.com (Postfix) with ESMTP id 14EF521E81A8 for ; Mon, 15 Jul 2013 23:14:40 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1UyyX0-0006R0-Cq for ; Tue, 16 Jul 2013 08:14:38 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.80 #3 (Debian)) id 1UyyPI-0008OX-O6; Tue, 16 Jul 2013 08:06:40 +0200 From: Werner Koch To: Paul Wouters References: Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Tue, 16 Jul 2013 08:06:40 +0200 In-Reply-To: (Paul Wouters's message of "Mon, 15 Jul 2013 18:32:46 -0400 (EDT)") Message-ID: <87y597jaxb.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: openpgp@ietf.org Subject: Re: [openpgp] Fwd: New Version Notification for draft-wouters-dane-openpgp-00.txt (fwd) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 06:14:46 -0000 On Tue, 16 Jul 2013 00:32, paul@nohats.ca said: > I've submitted a draft to associate an PGP public key with an email address using DANE. Some quick notes: Basically this is the same as the existing CERT RRs which are support by GnuPG for many years. The twist here is the Base32 encoding, which is avoids a few problems. I might haved missed that but they are not mentioned in the I-D. What I miss in this I-D are indirections and the use of URLs to download a complete key. Putting a 100k keyring into the DNS does not seem to be optimal. Granted, this is the exception but provisions for this should be defined. I consider wildcard mail address a bad idea. If you do not want end-to-end encryption, STARTTLS is much easier measure (we are not relaying anymore, right?) > 4.6. Subject: line encryption There is a well defined way to do this. The special case for the Subject is not needed. Wrap the mail into an message/rfc822 containers which has innocent headers. In any case I doubt that this is in the scope of the I-D. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From infinity0@gmx.com Tue Jul 16 01:06:16 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D00CB21E81C3 for ; Tue, 16 Jul 2013 01:06: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZYpxOyv7kRJ for ; Tue, 16 Jul 2013 01:06:13 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id BA8B121E81AD for ; Tue, 16 Jul 2013 01:06:12 -0700 (PDT) Received: from [192.168.1.193] ([81.157.80.80]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lxgt9-1U6Yzj3DvH-017C4S for ; Tue, 16 Jul 2013 10:06:08 +0200 Message-ID: <51E4FEF0.7010004@gmx.com> Date: Tue, 16 Jul 2013 09:06:08 +0100 From: Ximin Luo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130518 Icedove/17.0.5 MIME-Version: 1.0 To: openpgp@ietf.org References: <51D360B2.1070709@gmx.com> In-Reply-To: <51D360B2.1070709@gmx.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2GIRDOVNEELWRGBTGNVVT" X-Provags-ID: V03:K0:UAEhMHXt8O+MvyNHhI2HnHonzA8VvYe5yuNZDk1Dxfhz7CwcquZ xX6S/iWtHwR2OcrWCi8jcmR0Gx9nL+cOdGMAzMGOpzCnoppM021amBsp481g4ePUqn4r3/P oYWusKYl+Ixm1dvHHkG1pCteb1lIWF6iS70YwXwDlEEnyijgaeWMQi2Qas+OOQWeCIK7BL7 WFCzMNAqsbUQUlosBeaXQ== Subject: Re: [openpgp] signed/encrypted emails vs unsigned/unencrypted headers X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 08:06:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2GIRDOVNEELWRGBTGNVVT Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable comments, anyone? On 03/07/13 00:22, Ximin Luo wrote: > To openpgp@ietf.org, >=20 > As per [1] and [2], sign-then-encrypt is only really secure as long as = you do > it on *all* the information that forms the message, some of which might= be > external to the message data itself. Crucially, this includes the recip= ient. >=20 > What's the current status of this in the PGP/MIME standard? Is it still= a > problem? I notice that email subject headers are in a similar situation= , and > users have complained about it.[3] The problem of unencrypted/unauthent= icated > recipient is less obvious, so I haven't seen user complaints, but poten= tially > it is more serious. >=20 > Although not explicitly mentioned in the previous citations, these are > conceptually the same problem - i.e. you are only executing sign-then-e= ncrypt > on *part* of the data that should be secured. So, I believe that it's p= ossible > to work towards a single clean solution that fixes both problems. >=20 > (Sorry if this has been asked before already, or if the problem has alr= eady > been fixed; I did check the list archives but couldn't find anything on= a quick > scan, nor a quick session of web searching.) >=20 > X >=20 > [1] > http://crypto.stackexchange.com/questions/5458/should-we-sign-then-encr= ypt-or-encrypt-then-sign > [2] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html#CITEpgp > [3] http://www.mozilla-enigmail.org/forum/viewtopic.php?f=3D9&t=3D328 >=20 >=20 >=20 > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp >=20 --=20 GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0 ------enig2GIRDOVNEELWRGBTGNVVT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJR5P7wAAoJEIYN7zuPZQt5emMQALkyUiQA56xiqDXyRZhpt6eV G3Fc/JMaJI0XsA439U/O2qtd0fVXSYdSA/9+p1h04ZtvMJLiMo8tUQv8Hl4xmX9v 3yVbVULXSGpn/kqfRzs36q+jg2DSisgwk4GAhWg9p1piq6zWsL5pkPxK0ViK+wUR sXG3oA0OcvWogNoUTtmUrIG7JX2OIT7IWy5FiE99vZKr+H0T2Kj8nJH7IuiQLwgf MHXu5dAZEG2qlcNtcKyzP5JiScTEzbA4fof0vlDdsIo+WPYQlMj+W/C7ujEZkFIB bQ/I9Qb6V1bb83stnpEGCwaJhLMamNVtJQK4n1HrVxdjyDkzBn1WEEOOzLEFh6n6 ViA1eiPPPyfjezex02zQ08jT1T/0BRh5HrjmBUDExPmLvZEt7urg/GjFrcd7zoE3 8kk/PykYYEqx22ApP0f9M+bsAj37jHx2bxQXBGFNSrs0k5deqFkhO20Uk4KIXqHf sxYYCLANSURJjx5eFp4lJ6RmYgNbdwDsUYYAkqeAkCE90sBFEycp2xFqPlf1HRTp BoZXHMtJspmgn5HCs7ak2JqThIeB6qh3MDL8ojiTgUQrH4LWFZPM+mAvIUAOL6Ie 7KUK7PS72+FEKmSgp9/3fPrvnTYzK8LMADpkO4auVbeTEr1afquYHotwXy2XNohM z0pFGM2RFNwq5nPA+Cta =7tvc -----END PGP SIGNATURE----- ------enig2GIRDOVNEELWRGBTGNVVT-- From wk@gnupg.org Tue Jul 16 01:24:45 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA2C11E8268 for ; Tue, 16 Jul 2013 01:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvuil95hTB-d for ; Tue, 16 Jul 2013 01:24:40 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by ietfa.amsl.com (Postfix) with ESMTP id EF5EB11E8257 for ; Tue, 16 Jul 2013 01:24:39 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1Uz0Yo-0006u4-O7 for ; Tue, 16 Jul 2013 10:24:38 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.80 #3 (Debian)) id 1Uz0QX-0000Mf-Ho; Tue, 16 Jul 2013 10:16:05 +0200 From: Werner Koch To: Ximin Luo References: <51D360B2.1070709@gmx.com> <51E4FEF0.7010004@gmx.com> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Tue, 16 Jul 2013 10:16:05 +0200 In-Reply-To: <51E4FEF0.7010004@gmx.com> (Ximin Luo's message of "Tue, 16 Jul 2013 09:06:08 +0100") Message-ID: <87fvvekji2.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: openpgp@ietf.org Subject: Re: [openpgp] signed/encrypted emails vs unsigned/unencrypted headers X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 08:24:45 -0000 On Tue, 16 Jul 2013 10:06, infinity0@gmx.com said: > On 03/07/13 00:22, Ximin Luo wrote: >> What's the current status of this in the PGP/MIME standard? Is it still a >> problem? I notice that email subject headers are in a similar situation, and >> users have complained about it.[3] The problem of unencrypted/unauthenticated >> recipient is less obvious, so I haven't seen user complaints, but potentially There is a simple and standard conform way to tackle this: message/rfc822 - all covered by PGP/MIME. FWIW, PGP/MIME allows you to do encrypt-then-sign or any other combination - if you really want that. PGP/MIME is a well thought out and matured system created 17 years ago. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From infinity0@gmx.com Tue Jul 16 01:29:03 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEB5E11E8268 for ; Tue, 16 Jul 2013 01:29:03 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OF33xd86B5an for ; Tue, 16 Jul 2013 01:28:59 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9C511E826D for ; Tue, 16 Jul 2013 01:28:54 -0700 (PDT) Received: from [192.168.1.193] ([81.157.80.80]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MC4y8-1UqFCV0lYe-008sJw; Tue, 16 Jul 2013 10:28:51 +0200 Message-ID: <51E50442.8050701@gmx.com> Date: Tue, 16 Jul 2013 09:28:50 +0100 From: Ximin Luo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130518 Icedove/17.0.5 MIME-Version: 1.0 To: Werner Koch References: <51D360B2.1070709@gmx.com> <51E4FEF0.7010004@gmx.com> <87fvvekji2.fsf@vigenere.g10code.de> In-Reply-To: <87fvvekji2.fsf@vigenere.g10code.de> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2EXVVCXMGEKMDSANQUNNV" X-Provags-ID: V03:K0:QA+yWQszbP1kSMT1hErdOdWhkpS0xDR8ScsFhPFg9HzU9ZYJ5rG vPKutSpqcFXy40d0GnrOxrMwLaSIIpmYqaYGJ2qmSxxofQKTcQfn4TuHhrnOtbabqvkPs6r qmWan32K9w/BuelXC4+qmp6uk7y4N2RP7XmhccmTgjB6n7qbSE6gwbra/nlFxcn6XcmmnqL Z4ylNgkuuVTqMrpOYeIvA== Cc: openpgp@ietf.org Subject: Re: [openpgp] signed/encrypted emails vs unsigned/unencrypted headers X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 08:29:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2EXVVCXMGEKMDSANQUNNV Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 16/07/13 09:16, Werner Koch wrote: > On Tue, 16 Jul 2013 10:06, infinity0@gmx.com said: >> On 03/07/13 00:22, Ximin Luo wrote: >=20 >>> What's the current status of this in the PGP/MIME standard? Is it sti= ll a >>> problem? I notice that email subject headers are in a similar situati= on, and >>> users have complained about it.[3] The problem of unencrypted/unauthe= nticated >>> recipient is less obvious, so I haven't seen user complaints, but pot= entially >=20 > There is a simple and standard conform way to tackle this: > message/rfc822 - all covered by PGP/MIME. >=20 > FWIW, PGP/MIME allows you to do encrypt-then-sign or any other > combination - if you really want that. PGP/MIME is a well thought out > and matured system created 17 years ago. >=20 Thanks, I will take a look. Could you take a guess on why this feature is not used more? I haven't se= en any emails that use it (either an encrypted To: or Subject: field), either be= cause no emails actually use it, or perhaps it's my client's fault for not disp= laying it correctly. As mentioned in a previous link, it includes a security issue due to surreptitious forwarding of signed messages to unintended recipients. So = I would've thought people writing these PGP email clients would've taken it= into account. X --=20 GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0 ------enig2EXVVCXMGEKMDSANQUNNV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJR5QRCAAoJEIYN7zuPZQt5B/gP/0U5U5hdPRZsyCug4XHD+8Wc 5v61WNwIeclE17aET6adzzj96T6nmsfsd8chfJa1IBmNJO7FgGFyrFpqAHh279Sy 6VpstoDqDr4loPETcGrNNbkQsVngwEfbeBZI/qTBU7u9N3CPSBVIWpJ9wpvQ3gvI 8zdl19Iz4C3APVA7RzlCPfkDYHfcMFyWGOIm1AjzDiUFhBC3GPYNUS1FzBP+sPCi aqzoYT/PvhqM+jwGieW7k2OUmgzPUCX7cteGc8l3lLjUHcNdaSn2yzxdHpZq0dRf 33AaNXw32gOJ5EtbtoyRajgRfV47yKz6YFhzMPOIKlKeyos6LZUJpCW4oY3uxrn6 vr0l7U5hW7Bjwxto/rGM1XDpayX4yHAdJZHTlYpEXNSgmhJL9S5pKAt1kX5zHT2n QT/EhHvmUE/T+paBbgGkIql4lcUN9knu7A80ZhLRer+Uf0ryrdKnRu79sc9PsHGQ zGCnfWPEAPSPawMaoahBthmza8Wq4ZR+pQVawqdEjs544RD/CmjjteNg/NwDa2/6 M52OK6JeRbyDPLwUHfG9hNdyh0np0JuIkUgZaIqSTKc1aCsS5x0ZmmGZjNq1wmao mM1qvwRX1cETQ3Sr+M7bUdE6Mk2Rk30L8Tnv5VoOiafmnbiVp/qkY77csMhLOpGY SvFJ7TUUVYxXdp0kyURp =C+aq -----END PGP SIGNATURE----- ------enig2EXVVCXMGEKMDSANQUNNV-- From wk@gnupg.org Tue Jul 16 03:09:45 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF2321E81C3 for ; Tue, 16 Jul 2013 03:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KW8Bkam67o4e for ; Tue, 16 Jul 2013 03:09:40 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by ietfa.amsl.com (Postfix) with ESMTP id 1E56E11E8276 for ; Tue, 16 Jul 2013 03:09:39 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1Uz2CQ-0007Hp-Sd for ; Tue, 16 Jul 2013 12:09:38 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.80 #3 (Debian)) id 1Uz24P-0000py-LA; Tue, 16 Jul 2013 12:01:21 +0200 From: Werner Koch To: Ximin Luo References: <51D360B2.1070709@gmx.com> <51E4FEF0.7010004@gmx.com> <87fvvekji2.fsf@vigenere.g10code.de> <51E50442.8050701@gmx.com> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Tue, 16 Jul 2013 12:01:21 +0200 In-Reply-To: <51E50442.8050701@gmx.com> (Ximin Luo's message of "Tue, 16 Jul 2013 09:28:50 +0100") Message-ID: <877ggqkemm.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: openpgp@ietf.org Subject: Re: [openpgp] signed/encrypted emails vs unsigned/unencrypted headers X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 10:09:45 -0000 On Tue, 16 Jul 2013 10:28, infinity0@gmx.com said: > Could you take a guess on why this feature is not used more? I haven't seen any The first question should be, why OpenPGP is not used more. The subject fulfills an important task: It allows to quickly sort and order messages. An encrypted subject would require that you decrypt all messages even if you are not interested in them. Further, support for arbitrary nested MIME structures seems to be broken in some MUAs. Salam-Shalom, Werner p.s. What I do is to use a nonsense subject line for encrypted messages. This helps to remember the context of a mail thread while not revealing the content of the conversation. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From benlaurie@gmail.com Tue Jul 16 04:31:56 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78AD711E81C6 for ; Tue, 16 Jul 2013 04:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qP7o-kJFRUoP for ; Tue, 16 Jul 2013 04:31:55 -0700 (PDT) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFBC11E8294 for ; Tue, 16 Jul 2013 04:31:55 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id o13so2220983qaj.10 for ; Tue, 16 Jul 2013 04:31:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=L+ye2lSdn15e711sfThdLauEQX4SliI8y63YfQ2jbnk=; b=R0v0ZQCJD2oAEKIeKlaIUMeyoPJCH49Ll4T93ERb3f0BMpOqm4gUffN6FPpgJb6S0k QFZvCnoN7rHNa2LH6aibF7Xcbd67zP+i97LFAU7Y4F6J8J0+uDdwh0HntBg7LsgUP9+R bbaUWBmlJ3JbRY7ioSBEchLI5Qnn3wWjELVj2xGQEDncg0uXR/3hPLpmfQqQJd6AQi4V 6QdLLInf3AvbYOu8meGhORL5aux0pZja+NrR9K2Fbq7ihGiJlQW+BpQOa+bsSC4EXRP5 8Ln4v3dE6CHrL7ow5MvaKawTmOCeXP5iu3Hv3eZr/wyaz5Gid2CLdQqVwMgZaxB7SEqr sG1w== MIME-Version: 1.0 X-Received: by 10.49.48.83 with SMTP id j19mr1189143qen.56.1373974314676; Tue, 16 Jul 2013 04:31:54 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.49.19.73 with HTTP; Tue, 16 Jul 2013 04:31:54 -0700 (PDT) In-Reply-To: <51D360B2.1070709@gmx.com> References: <51D360B2.1070709@gmx.com> Date: Tue, 16 Jul 2013 12:31:54 +0100 X-Google-Sender-Auth: 4GHTBkpbN7qM22N5WG9XAB3p2Ts Message-ID: From: Ben Laurie To: Ximin Luo Content-Type: text/plain; charset=ISO-8859-1 Cc: openpgp@ietf.org Subject: Re: [openpgp] signed/encrypted emails vs unsigned/unencrypted headers X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 11:31:56 -0000 On 3 July 2013 00:22, Ximin Luo wrote: > To openpgp@ietf.org, > > As per [1] and [2], sign-then-encrypt is only really secure as long as you do > it on *all* the information that forms the message, some of which might be > external to the message data itself. Crucially, this includes the recipient. > > What's the current status of this in the PGP/MIME standard? Is it still a > problem? I notice that email subject headers are in a similar situation, and > users have complained about it.[3] The problem of unencrypted/unauthenticated > recipient is less obvious, so I haven't seen user complaints, but potentially > it is more serious. Not clear why this is an issue? Surely the fact the message is encrypted to the recipient is sufficient? > Although not explicitly mentioned in the previous citations, these are > conceptually the same problem - i.e. you are only executing sign-then-encrypt > on *part* of the data that should be secured. So, I believe that it's possible > to work towards a single clean solution that fixes both problems. > > (Sorry if this has been asked before already, or if the problem has already > been fixed; I did check the list archives but couldn't find anything on a quick > scan, nor a quick session of web searching.) > > X > > [1] > http://crypto.stackexchange.com/questions/5458/should-we-sign-then-encrypt-or-encrypt-then-sign > [2] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html#CITEpgp > [3] http://www.mozilla-enigmail.org/forum/viewtopic.php?f=9&t=328 > > -- > GPG: 4096R/5FBBDBCE > https://github.com/infinity0 > https://bitbucket.org/infinity0 > https://launchpad.net/~infinity0 > > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > From infinity0@gmx.com Tue Jul 16 14:49:57 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC7821F9E5C for ; Tue, 16 Jul 2013 14:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_47=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rJwy4CVgXqf for ; Tue, 16 Jul 2013 14:49:54 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id A8A6121F9E4D for ; Tue, 16 Jul 2013 14:49:53 -0700 (PDT) Received: from [192.168.1.66] ([109.152.229.244]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lx83d-1U5nNB39nF-016ddA for ; Tue, 16 Jul 2013 23:49:52 +0200 Message-ID: <51E5BFFC.1040505@gmx.com> Date: Tue, 16 Jul 2013 22:49:48 +0100 From: Ximin Luo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130518 Icedove/17.0.5 MIME-Version: 1.0 To: openpgp@ietf.org References: <51D360B2.1070709@gmx.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2IFWVMUHRAATVTOMTGLDJ" X-Provags-ID: V03:K0:NlDNZ66vym0PsAUl1SrRmSyjA7kcqxsyS+mdxw9CNzq5TuxiXmw +qf4Ytq+mOHfQ1WR93ai1COAGwHlWckYS/JA17Xb8DfTRbE7JUHh1/LsYJOmq7jQYV7CjPA ny3BW1CHQ2R+fywcgwKLxtiVJQFT5RcutHYTDNqe8jG2aVOZdOqpLVAEPoUXcLvgGpzQ0TG b7ZL5Gde77NEhWcGJqn7g== Subject: Re: [openpgp] signed/encrypted emails vs unsigned/unencrypted headers X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 21:49:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2IFWVMUHRAATVTOMTGLDJ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 16/07/13 12:31, Ben Laurie wrote: > On 3 July 2013 00:22, Ximin Luo wrote: >> To openpgp@ietf.org, >> >> As per [1] and [2], sign-then-encrypt is only really secure as long as= you do >> it on *all* the information that forms the message, some of which migh= t be >> external to the message data itself. Crucially, this includes the reci= pient. >> >> What's the current status of this in the PGP/MIME standard? Is it stil= l a >> problem? I notice that email subject headers are in a similar situatio= n, and >> users have complained about it.[3] The problem of unencrypted/unauthen= ticated >> recipient is less obvious, so I haven't seen user complaints, but pote= ntially >> it is more serious. >=20 > Not clear why this is an issue? Surely the fact the message is > encrypted to the recipient is sufficient? >=20 The signed part does not explicit say who the recipient is. When the init= ial recipient decrypts the message, they remove this implicit information= (the intended recipient). They are then free to encrypt the signed messa= ge to a different, *unintended*, recipient. (See [2] I linked previously.= ) It is possible that I missed something, that PGP sign+encrypt actually do= es already implicitly add this information to the inner signed (non-forge= able) data. But this is not consistent with my research - I do not see an= ything in RFC 4880 that would prevent the attack described. I haven't rea= d it in full, so I could be wrong, but the sources I cited previously agr= ee with this, and that's why I emailed this list about it. Please correct= me if I am wrong! X P.S. The GnuPG CLI does not let you decrypt a sign+encrypted file, withou= t also verifying the signature. So, I hoped that it was actually transpar= ently adding the list of encryption recipients to the inner signed data. = However this appears not to be the case, which means in theory someone co= uld write a tool to do the surreptitious forwarding attack. I did an expe= riment, using "a.txt" containing 6 bytes "12345\n". Let's see the results= : # Signed and encrypted data, using gpg --sign --encrypt $ gpg --list-packets a.txt.siggpg :pubkey enc packet: version 3, algo 1, keyid 68AE6913E59091EC data: [2048 bits] :encrypted data packet: length: unknown mdc_method: 2 :compressed packet: algo=3D2 :onepass_sig packet: keyid 860DEF3B8F650B79 version 3, sigclass 0x00, digest 8, pubkey 1, last=3D1 :literal data packet: mode b (62), created 1373995055, name=3D"", raw data: 6 bytes :signature packet: algo 1, keyid 860DEF3B8F650B79 version 4, created 1373995055, md5len 0, sigclass 0x00 digest algo 8, begin of digest de 4e hashed subpkt 2 len 4 (sig created 2013-07-16) subpkt 16 len 8 (issuer key ID 860DEF3B8F650B79) data: [4096 bits] None of the inner decrypted packets contain any To: information about any= encryption recipients - onepass_sig http://tools.ietf.org/html/rfc4880#section-5.4 - literal data (6 bytes cannot possibly contain To: info) - signature packet, version 4 http://tools.ietf.org/html/rfc4880#section-= 5.2.3 For more evidence, compare this to a non-encrypted signed file, of the sa= me data. The signature-relevant packets are the same in both the encrypte= d/cleartext versions, and contain no additional information on the encryp= tion recipient. # Signed clear data, using gpg --sign $ gpg --list-packets a.txt.sig :compressed packet: algo=3D1 :onepass_sig packet: keyid 860DEF3B8F650B79 version 3, sigclass 0x00, digest 8, pubkey 1, last=3D1 :literal data packet: mode b (62), created 1373994966, name=3D"", raw data: 6 bytes :signature packet: algo 1, keyid 860DEF3B8F650B79 version 4, created 1373994966, md5len 0, sigclass 0x00 digest algo 8, begin of digest ef 3a hashed subpkt 2 len 4 (sig created 2013-07-16) subpkt 16 len 8 (issuer key ID 860DEF3B8F650B79) data: [4095 bits] >> Although not explicitly mentioned in the previous citations, these are= >> conceptually the same problem - i.e. you are only executing sign-then-= encrypt >> on *part* of the data that should be secured. So, I believe that it's = possible >> to work towards a single clean solution that fixes both problems. >> >> (Sorry if this has been asked before already, or if the problem has al= ready >> been fixed; I did check the list archives but couldn't find anything o= n a quick >> scan, nor a quick session of web searching.) >> >> X >> >> [1] >> http://crypto.stackexchange.com/questions/5458/should-we-sign-then-enc= rypt-or-encrypt-then-sign >> [2] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html#CITEpgp >> [3] http://www.mozilla-enigmail.org/forum/viewtopic.php?f=3D9&t=3D328 >> >> -- >> GPG: 4096R/5FBBDBCE >> https://github.com/infinity0 >> https://bitbucket.org/infinity0 >> https://launchpad.net/~infinity0 >> >> >> _______________________________________________ >> openpgp mailing list >> openpgp@ietf.org >> https://www.ietf.org/mailman/listinfo/openpgp >> > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp >=20 ------enig2IFWVMUHRAATVTOMTGLDJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJR5b//AAoJEIYN7zuPZQt5ExEQAI+Q6GI3yZNnJXDYVSOP/xRA bBL7f0L32lEYWgyml8nDErWRgaqFBOA/yJXSkhvh356fUwz645SAtGU3rP2VPNZm 9xDroftYUjnKCnaos463ljBjygyGfLGMw4MCcn/w07m+TTUwusy+rgXOlyTpF/Yz SilPqEg6j4sTmYVuE0iMpUTQSQEpzY/+WhYGHEFXLi4PpQKie3rTHO9TAxkbxfvd mtZvHzWvZt8apwrJ/xaUqfw6jk0B2Rg3KoknYef3yjbJCbr0gvA/WmibTny0VMMP yR2os9juRY4FKNMoqP4n5OydRLt+/o0msq+M05T5dxNuNmlpVe+pfrYmF+3s3lJN sCRoe+H0y1I/agSHdLmnekSSQfTeZfCsX09IFCgXpaoFy9VVWykQNIEzYoAVc5KR AVzI5n9m9fG5VQPiz7e7cRJoURnXdSKtZ6XjjAR99bCfFpnPFEMFJcxDl+YU85uk AaMWxPCaZpxn+Wt9cj2zZiF2MEn2Tinai5U7/r6u4u9O3Uvyj5yrM1ELiV+b/SXw M9fC5aw0V1+oRYaUkTbT8PXiJ2r9ULVaMZX45uxJwFElp8937f7mmSIFLV6RxFcv LnrVIi+JO6fv5c+7RzCl0yFayP/3bte38vL4bL5jdlUhD/f2vrZc+vu+Qpw0ZTgx CnRaJ/niZvQROHcd8Yjq =OAYq -----END PGP SIGNATURE----- ------enig2IFWVMUHRAATVTOMTGLDJ-- From infinity0@gmx.com Tue Jul 16 15:05:19 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C52421F9815 for ; Tue, 16 Jul 2013 15:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_47=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBr7iKqiKuzp for ; Tue, 16 Jul 2013 15:05:13 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id DC04921F93DB for ; Tue, 16 Jul 2013 15:05:12 -0700 (PDT) Received: from [192.168.1.66] ([109.152.229.244]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LZzKf-1UHx0M3Hpd-00lj4T for ; Wed, 17 Jul 2013 00:05:11 +0200 Message-ID: <51E5C397.6050403@gmx.com> Date: Tue, 16 Jul 2013 23:05:11 +0100 From: Ximin Luo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130518 Icedove/17.0.5 MIME-Version: 1.0 To: openpgp@ietf.org References: <51D360B2.1070709@gmx.com> <51E4FEF0.7010004@gmx.com> <87fvvekji2.fsf@vigenere.g10code.de> <51E50442.8050701@gmx.com> <877ggqkemm.fsf@vigenere.g10code.de> In-Reply-To: <877ggqkemm.fsf@vigenere.g10code.de> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2TITFOIFMPJJIAXRAATFB" X-Provags-ID: V03:K0:ZS9ka9evqUUSFnhacf/2F3yJHGKDWv5OxRxD2UAXSwPsDQFVT12 oh3r1vUiGcwI4w29qY8bOiQPNhifmjJGrz7aV2ZqfYv9uWj1Q/cPaJ8M1lFLj+fxMCJjdmo Y+xaT5Mfe4cDfu1q3Ml6UrZrTpZnrg5ojrX2r3WW/4XxtA/md1kh9girCg05MBtUqev/AnI TQBTs3KXk0zIS0s4ap9PQ== Subject: Re: [openpgp] signed/encrypted emails vs unsigned/unencrypted headers X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 22:05:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2TITFOIFMPJJIAXRAATFB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 16/07/13 11:01, Werner Koch wrote: > On Tue, 16 Jul 2013 10:28, infinity0@gmx.com said: >=20 >> Could you take a guess on why this feature is not used more? I haven't= seen any >=20 > The first question should be, why OpenPGP is not used more. The subjec= t > fulfills an important task: It allows to quickly sort and order > messages. An encrypted subject would require that you decrypt all > messages even if you are not interested in them. Further, support for > arbitrary nested MIME structures seems to be broken in some MUAs. >=20 I think those are separate questions. :p Your argument about "would require decrypt" is not tight; it applies equa= lly to the message contents ("you can't search yada"). This is a trade-se= curity-for-convenience approach, which is asking for trouble even if you = can't explicitly think of an attack. For maximum security, all headers that have end-to-end semantics should b= e added to the signed part of the message, and only the subset of these t= hat are actually necessary for email to work correctly, should be sent in= the clear. For example, one could imagine an attack where you have 1000 messages in = a thread with 10 people, then you could infer from the plaintext Referenc= es: headers, a prediction on which of these 10 people are closely connect= ed with each other. You can attack the plaintext To: header as I describe= d in a previous post, and perhaps you can similarly attack the Subject: h= eader even though right now it *seems* unimportant. A future application = may use email transport in a novel way and treat the Subject: header to h= ave much more valuable semantic meaning that affects application logic, w= rongly assuming that PGP sign+encrypt is "secure" in that area. X =20 >=20 > Salam-Shalom, >=20 > Werner >=20 >=20 > p.s. > What I do is to use a nonsense subject line for encrypted messages. Th= is > helps to remember the context of a mail thread while not revealing the > content of the conversation. >=20 =E3=80=8D ------enig2TITFOIFMPJJIAXRAATFB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJR5cOXAAoJEIYN7zuPZQt5H50P/33yJWXy87l2/SVv9XFoMZch aX/kEwjef+wx+vM4qsPeGAnWBiS43HvSFvqPRis9bF75DKQMR8wbbaltk5FyBqsS 2utn5K5lsgtvcwBwI4kp+tJNbKbfrmjABKM+qIv8HglvzZrG/NVfvAwP/4JP/5iM IRTDZ3ofTrn/ETe9y5k2XSPoGR450vFtAmzhlRCMmZza9Camj/7F5qjpw/nu3K5U 199ZQNP4cEtGKpuUznpwFSsZbCOz5+eSpD9oVvnrOZCF73Vf2wWBSo10jlDu4rdF ZTdkCiM2ytHFdYtweMaU7SCQtoB8i2CGB/DQOXQUUQx2oYz+xE0TLPkk6WKoqo/w JfdCh5UK2zdEIiZZNz4uPnAqVRPVj844eNWSHyYcDNBY7Nb1JF5aO7zHAINNSrDs oI39VYobTFAsGtcWMh793YI04YSrg2xwvHqSU1cRV/fawBv3XqLMPbKjIJ9J4zfs 8u6NB5qocogzDFloWwPPUG6LOYlObrCqsPlfc2LB7OCV/oYjSSxFGixKJwpUQ5ok 2MA5h0auVlpfaqO85dmzzRxqmhrFrGyKHMlUDpfgtSXqHc/WP3XK4EjiXa2WSUJT WgDGOXTzX7jkArFmIfHE+IaNuFlspUhc0xRHkR9SgUCgW752UF+x5AfscMjUKY5Z lN/bkMjAlJ36AC4IcVkR =Pqyp -----END PGP SIGNATURE----- ------enig2TITFOIFMPJJIAXRAATFB-- From wk@gnupg.org Wed Jul 17 00:54:48 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF84521F9D98 for ; Wed, 17 Jul 2013 00:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YAFJrNe0vZ5 for ; Wed, 17 Jul 2013 00:54:43 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC7421F9D30 for ; Wed, 17 Jul 2013 00:54:41 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1UzMZL-0003Bn-JK for ; Wed, 17 Jul 2013 09:54:39 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.80 #3 (Debian)) id 1UzMQZ-0005Lx-TY; Wed, 17 Jul 2013 09:45:35 +0200 From: Werner Koch To: Ximin Luo References: <51D360B2.1070709@gmx.com> <51E4FEF0.7010004@gmx.com> <87fvvekji2.fsf@vigenere.g10code.de> <51E50442.8050701@gmx.com> <877ggqkemm.fsf@vigenere.g10code.de> <51E5C397.6050403@gmx.com> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Wed, 17 Jul 2013 09:45:35 +0200 In-Reply-To: <51E5C397.6050403@gmx.com> (Ximin Luo's message of "Tue, 16 Jul 2013 23:05:11 +0100") Message-ID: <87bo61hbog.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: openpgp@ietf.org Subject: Re: [openpgp] signed/encrypted emails vs unsigned/unencrypted headers X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 07:54:48 -0000 On Wed, 17 Jul 2013 00:05, infinity0@gmx.com said: > Your argument about "would require decrypt" is not tight; it applies > equally to the message contents ("you can't search yada"). This is a No, it does not. Stepping users of webmail aside, most people are using IMAP and not POP3 or UUCP. With IMAP you download the headers (including the subject) and only then select which mails to read and finally download. Yes, this makes a difference if you think about businesses with multi-megabyte PDF documents. In any case, this is not relevant to the OpenPGP standard and thus you may want to move this discussion to another list. FWIW, S/MIME has the very same semantics. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From infinity0@gmx.com Wed Jul 17 01:01:45 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B7721F9DA0 for ; Wed, 17 Jul 2013 01:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLysz5yZoEog for ; Wed, 17 Jul 2013 01:01:41 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCD521F9DA5 for ; Wed, 17 Jul 2013 01:01:41 -0700 (PDT) Received: from [192.168.1.193] ([109.152.229.244]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MHXXo-1V0S4m0E7Y-003Nhe for ; Wed, 17 Jul 2013 10:01:40 +0200 Message-ID: <51E64F5D.9000203@gmx.com> Date: Wed, 17 Jul 2013 09:01:33 +0100 From: Ximin Luo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130518 Icedove/17.0.5 MIME-Version: 1.0 To: openpgp@ietf.org References: <51D360B2.1070709@gmx.com> <51E4FEF0.7010004@gmx.com> <87fvvekji2.fsf@vigenere.g10code.de> <51E50442.8050701@gmx.com> <877ggqkemm.fsf@vigenere.g10code.de> <51E5C397.6050403@gmx.com> <87bo61hbog.fsf@vigenere.g10code.de> In-Reply-To: <87bo61hbog.fsf@vigenere.g10code.de> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2FXPRGWMMAIQJSJOCUIXM" X-Provags-ID: V03:K0:STUdMzn6Le6N5zkdtu6eenlT1tAs3hvawGZr7goQk803EW3pARB vFZgHcovxr5BH4QmuCVAhPyzjNZoJiRO5wTNQ20SbknGpT9lV+ORWaFZXQ0Ms8dpwqaR+qA CwTbeKucfVN93k/SSYTngZqLJLN6M1mvE5EvP+cME0gnvoHL+2LOGcBlSElD4TYiQw1KM4M vcPobdmNDWModCLCqUntw== Subject: Re: [openpgp] signed/encrypted emails vs unsigned/unencrypted headers X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 08:01:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2FXPRGWMMAIQJSJOCUIXM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 17/07/13 08:45, Werner Koch wrote: > On Wed, 17 Jul 2013 00:05, infinity0@gmx.com said: >=20 >> Your argument about "would require decrypt" is not tight; it applies >> equally to the message contents ("you can't search yada"). This is a >=20 > No, it does not. Stepping users of webmail aside, most people are usin= g > IMAP and not POP3 or UUCP. With IMAP you download the headers > (including the subject) and only then select which mails to read and > finally download. Yes, this makes a difference if you think about > businesses with multi-megabyte PDF documents. >=20 I don't see how this is significant - is it such a conceptual stretch to imagine headers and the body being encrypted separately? Or do you mean t= hat RFC 822 does not support this? > In any case, this is not relevant to the OpenPGP standard and thus you > may want to move this discussion to another list. FWIW, S/MIME has the= > very same semantics. >=20 Which mailing list, then? pgp-mime has been shut down and redirected to t= his one: http://www.imc.org/ietf-pgp-mime/ X --=20 GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0 ------enig2FXPRGWMMAIQJSJOCUIXM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJR5k9iAAoJEIYN7zuPZQt5/AYQAL5Laek/w5D2Vek/Wj4kbMqr ce4wcNCp7qkLG3QO6yl3DWzumM7Bag3amAt3qGkYFO1ZJ2UEolfzc5e4BVaKWTSR OZCPPVJSBmZEIBKkOCaOnaGHdYRnrFesIfaZ4HQImwuUfutcq5cgqswqk8zUw+oc tOr+7/M1Fh1jJrtPWQjv1TovNlCn0BtfrQtFRQkNc2qwnhGkwd3F1rMeNIcxdCC7 nwV3BcLDWwtZyVvixrmcw6C8E5kLUGuMjDYhmDTxyyGUoxQh821+W3jcOOKiThjy yBB7lvx5t77l6n5+W+v3jLti8i1kImiTk0UwX3GtdaexixcDlIcZUisvggbA8rhr TMm525fxvQF/tw2gIlJakCIhuNTPxfxHmrZQbwfq/4cdSrvIAGgTdKUy8KfWX9Hx sU/JZoO4sZ1I1eJHlVlQTbueDvLOcVzGgyMvkL14JnRJwcAD7qmGOkoL9J1Shp6u tdzRUvbHVNlsgCIePwvZeBp1M4WQtX2nMbybsxtBzjezXuURC1CsnM7/ure2jCVb ZzHfr2wzJSDFem57eGC6RhtI1X0U2BFcjEOrtuApKYZvx9LfUg/L+d1ds9C2x1rY NMjUEuMKBc/cXjLXJqGfRQG2Z1Mkf/OhxkrwGs2WPnzl03j6jo/qh2YlEMAI1df1 nqYvJyMhvvfsBzdV7UY7 =3uTa -----END PGP SIGNATURE----- ------enig2FXPRGWMMAIQJSJOCUIXM-- From wk@gnupg.org Wed Jul 17 02:34:46 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95CE21F995A for ; Wed, 17 Jul 2013 02:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAKCAT-L3z7E for ; Wed, 17 Jul 2013 02:34:41 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE7021F94DC for ; Wed, 17 Jul 2013 02:34:41 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1UzO87-0003jD-Iw for ; Wed, 17 Jul 2013 11:34:39 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.80 #3 (Debian)) id 1UzO3P-0008Pa-3k; Wed, 17 Jul 2013 11:29:47 +0200 From: Werner Koch To: Ximin Luo References: <51D360B2.1070709@gmx.com> <51E4FEF0.7010004@gmx.com> <87fvvekji2.fsf@vigenere.g10code.de> <51E50442.8050701@gmx.com> <877ggqkemm.fsf@vigenere.g10code.de> <51E5C397.6050403@gmx.com> <87bo61hbog.fsf@vigenere.g10code.de> <51E64F5D.9000203@gmx.com> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Wed, 17 Jul 2013 11:29:47 +0200 In-Reply-To: <51E64F5D.9000203@gmx.com> (Ximin Luo's message of "Wed, 17 Jul 2013 09:01:33 +0100") Message-ID: <87y595fsac.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: openpgp@ietf.org Subject: Re: [openpgp] signed/encrypted emails vs unsigned/unencrypted headers X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 09:34:47 -0000 On Wed, 17 Jul 2013 10:01, infinity0@gmx.com said: > I don't see how this is significant - is it such a conceptual stretch to > imagine headers and the body being encrypted separately? Or do you mean that > RFC 822 does not support this? MIME supports this. But it does not care about the outer header. Partly because it carries the meta data required for parsing MIME. If you like to encrypt the subject, you may simply use a single line base64 encoding of the an OpenPGP encrypted message. But there are problems. Imagine that you need to encrypt to several recipients with the resulting line extending to over 989 characters - which violates rfc822. > Which mailing list, then? pgp-mime has been shut down and redirected to this Feel free to use the gnupg-users list. Over the years this kind of ideas have been discussed there several time. Or any other MUA related list. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From benlaurie@gmail.com Wed Jul 17 02:43:24 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97FFA21F9A1D for ; Wed, 17 Jul 2013 02:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_47=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcgkIIF9zlHm for ; Wed, 17 Jul 2013 02:43:23 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6A86E21F9963 for ; Wed, 17 Jul 2013 02:43:23 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id j10so970669qcx.17 for ; Wed, 17 Jul 2013 02:43:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LpBKzWGQ0UTeK+W4imMMYSka8tNB8XvQakhhbjDg5Gg=; b=gvydzoCVEXwE82JcwS5wW03rGr9PLHN0gHHlwZ4Y/NQAl5Jccggi1jZL5ncm3hNKH+ UH2UX1kGr766BqsCzBy9dN/x6FxB3G1OE7VtDOQUFgLZNlvLeBrZrYm2j4FlHFwJi0qX kuJ+8HU3w15Ki4a67g84kCStqNxAnoGZWzlYIIculgsd29g4kLk65+LRhJvuuFXiRkkF CvlhIilUeF4fiW+1aYei7bAUV4oaWRkqcXyqElbxT9XcXf2frV4yPwfVusxg5llRSSD0 V11k+FCSUyyulSdFTgo7BClVRHVeLwHqu4Uz1Q2t0ia/Olz8iK425KgaP6WY3oxUsCOL pLLQ== MIME-Version: 1.0 X-Received: by 10.224.127.137 with SMTP id g9mr8094773qas.4.1374054200556; Wed, 17 Jul 2013 02:43:20 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.49.19.73 with HTTP; Wed, 17 Jul 2013 02:43:20 -0700 (PDT) In-Reply-To: <51E5BFFC.1040505@gmx.com> References: <51D360B2.1070709@gmx.com> <51E5BFFC.1040505@gmx.com> Date: Wed, 17 Jul 2013 10:43:20 +0100 X-Google-Sender-Auth: xXsfFMA_JZpUBZ-LLGh8qM17hXM Message-ID: From: Ben Laurie To: Ximin Luo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: openpgp@ietf.org Subject: Re: [openpgp] signed/encrypted emails vs unsigned/unencrypted headers X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 09:43:24 -0000 On 16 July 2013 22:49, Ximin Luo wrote: > On 16/07/13 12:31, Ben Laurie wrote: >> On 3 July 2013 00:22, Ximin Luo wrote: >>> To openpgp@ietf.org, >>> >>> As per [1] and [2], sign-then-encrypt is only really secure as long as = you do >>> it on *all* the information that forms the message, some of which might= be >>> external to the message data itself. Crucially, this includes the recip= ient. >>> >>> What's the current status of this in the PGP/MIME standard? Is it still= a >>> problem? I notice that email subject headers are in a similar situation= , and >>> users have complained about it.[3] The problem of unencrypted/unauthent= icated >>> recipient is less obvious, so I haven't seen user complaints, but poten= tially >>> it is more serious. >> >> Not clear why this is an issue? Surely the fact the message is >> encrypted to the recipient is sufficient? >> > > The signed part does not explicit say who the recipient is. When the init= ial recipient decrypts the message, they remove this implicit information (= the intended recipient). They are then free to encrypt the signed message t= o a different, *unintended*, recipient. (See [2] I linked previously.) Ah, I see. I am sure I remember this being discussed before. But I can't remember where. > It is possible that I missed something, that PGP sign+encrypt actually do= es already implicitly add this information to the inner signed (non-forgeab= le) data. But this is not consistent with my research - I do not see anythi= ng in RFC 4880 that would prevent the attack described. I haven't read it i= n full, so I could be wrong, but the sources I cited previously agree with = this, and that's why I emailed this list about it. Please correct me if I a= m wrong! I'm not sure what you think the attack is. I get that you end up with a signed blob that is sent to someone other than the intended recipient. So what? You might find sections 3 and 4 of http://www.apache-ssl.org/tech-legal.pdf helpful. > > X > > P.S. The GnuPG CLI does not let you decrypt a sign+encrypted file, withou= t also verifying the signature. So, I hoped that it was actually transparen= tly adding the list of encryption recipients to the inner signed data. Howe= ver this appears not to be the case, which means in theory someone could wr= ite a tool to do the surreptitious forwarding attack. I did an experiment, = using "a.txt" containing 6 bytes "12345\n". Let's see the results: > > # Signed and encrypted data, using gpg --sign --encrypt > $ gpg --list-packets a.txt.siggpg > :pubkey enc packet: version 3, algo 1, keyid 68AE6913E59091EC > data: [2048 bits] > :encrypted data packet: > length: unknown > mdc_method: 2 > :compressed packet: algo=3D2 > :onepass_sig packet: keyid 860DEF3B8F650B79 > version 3, sigclass 0x00, digest 8, pubkey 1, last=3D1 > :literal data packet: > mode b (62), created 1373995055, name=3D"", > raw data: 6 bytes > :signature packet: algo 1, keyid 860DEF3B8F650B79 > version 4, created 1373995055, md5len 0, sigclass 0x00 > digest algo 8, begin of digest de 4e > hashed subpkt 2 len 4 (sig created 2013-07-16) > subpkt 16 len 8 (issuer key ID 860DEF3B8F650B79) > data: [4096 bits] > > None of the inner decrypted packets contain any To: information about any= encryption recipients > - onepass_sig http://tools.ietf.org/html/rfc4880#section-5.4 > - literal data (6 bytes cannot possibly contain To: info) > - signature packet, version 4 http://tools.ietf.org/html/rfc4880#section-= 5.2.3 > > For more evidence, compare this to a non-encrypted signed file, of the sa= me data. The signature-relevant packets are the same in both the encrypted/= cleartext versions, and contain no additional information on the encryption= recipient. > > # Signed clear data, using gpg --sign > $ gpg --list-packets a.txt.sig > :compressed packet: algo=3D1 > :onepass_sig packet: keyid 860DEF3B8F650B79 > version 3, sigclass 0x00, digest 8, pubkey 1, last=3D1 > :literal data packet: > mode b (62), created 1373994966, name=3D"", > raw data: 6 bytes > :signature packet: algo 1, keyid 860DEF3B8F650B79 > version 4, created 1373994966, md5len 0, sigclass 0x00 > digest algo 8, begin of digest ef 3a > hashed subpkt 2 len 4 (sig created 2013-07-16) > subpkt 16 len 8 (issuer key ID 860DEF3B8F650B79) > data: [4095 bits] > >>> Although not explicitly mentioned in the previous citations, these are >>> conceptually the same problem - i.e. you are only executing sign-then-e= ncrypt >>> on *part* of the data that should be secured. So, I believe that it's p= ossible >>> to work towards a single clean solution that fixes both problems. >>> >>> (Sorry if this has been asked before already, or if the problem has alr= eady >>> been fixed; I did check the list archives but couldn't find anything on= a quick >>> scan, nor a quick session of web searching.) >>> >>> X >>> >>> [1] >>> http://crypto.stackexchange.com/questions/5458/should-we-sign-then-encr= ypt-or-encrypt-then-sign >>> [2] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html#CITEpgp >>> [3] http://www.mozilla-enigmail.org/forum/viewtopic.php?f=3D9&t=3D328 >>> >>> -- >>> GPG: 4096R/5FBBDBCE >>> https://github.com/infinity0 >>> https://bitbucket.org/infinity0 >>> https://launchpad.net/~infinity0 >>> >>> >>> _______________________________________________ >>> openpgp mailing list >>> openpgp@ietf.org >>> https://www.ietf.org/mailman/listinfo/openpgp >>> >> _______________________________________________ >> openpgp mailing list >> openpgp@ietf.org >> https://www.ietf.org/mailman/listinfo/openpgp >> > > > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > From infinity0@gmx.com Wed Jul 17 11:27:54 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157D621F9E33 for ; Wed, 17 Jul 2013 11:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_47=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrMJ76Z0YFrf for ; Wed, 17 Jul 2013 11:27:50 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8B62E21F996F for ; Wed, 17 Jul 2013 11:27:49 -0700 (PDT) Received: from [192.168.1.66] ([109.152.229.244]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MY75A-1UdRDv38gy-00Us3M for ; Wed, 17 Jul 2013 20:27:47 +0200 Message-ID: <51E6E21C.4020708@gmx.com> Date: Wed, 17 Jul 2013 19:27:40 +0100 From: Ximin Luo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130518 Icedove/17.0.5 MIME-Version: 1.0 To: openpgp@ietf.org References: <51D360B2.1070709@gmx.com> <51E5BFFC.1040505@gmx.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2QEBRXVEXEWHSOPUGRATH" X-Provags-ID: V03:K0:6oaFGHbh9P8VN3fTwDPi75YonRldnKatCB/103o/+EuhfRN1Gdc 5SMtnrZqiU1zUIEyViJ9FS/5wfxbSsIldrc51H3AxsmkWlj/eTU4RCwsLb0QD4YSR5uw76S 2NBBCOB8vjnf2MKeBQ8nYo/nKCjMZUjFUORg1/H+IUjMjPoStzXHpdcNoeetCAR5mzzR2uw Olrn2Lw2GPAa9jdw0YQlg== Subject: Re: [openpgp] signed/encrypted emails vs unsigned/unencrypted headers X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 18:27:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2QEBRXVEXEWHSOPUGRATH Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 17/07/13 10:43, Ben Laurie wrote: > On 16 July 2013 22:49, Ximin Luo wrote: >> On 16/07/13 12:31, Ben Laurie wrote: >>> On 3 July 2013 00:22, Ximin Luo wrote: >>>> To openpgp@ietf.org, >>>> >>>> As per [1] and [2], sign-then-encrypt is only really secure as long = as you do >>>> it on *all* the information that forms the message, some of which mi= ght be >>>> external to the message data itself. Crucially, this includes the re= cipient. >>>> >>>> What's the current status of this in the PGP/MIME standard? Is it st= ill a >>>> problem? I notice that email subject headers are in a similar situat= ion, and >>>> users have complained about it.[3] The problem of unencrypted/unauth= enticated >>>> recipient is less obvious, so I haven't seen user complaints, but po= tentially >>>> it is more serious. >>> >>> Not clear why this is an issue? Surely the fact the message is >>> encrypted to the recipient is sufficient? >>> >> >> The signed part does not explicit say who the recipient is. When the i= nitial recipient decrypts the message, they remove this implicit informat= ion (the intended recipient). They are then free to encrypt the signed me= ssage to a different, *unintended*, recipient. (See [2] I linked previous= ly.) >=20 > Ah, I see. I am sure I remember this being discussed before. But I > can't remember where. >=20 >> It is possible that I missed something, that PGP sign+encrypt actually= does already implicitly add this information to the inner signed (non-fo= rgeable) data. But this is not consistent with my research - I do not see= anything in RFC 4880 that would prevent the attack described. I haven't = read it in full, so I could be wrong, but the sources I cited previously = agree with this, and that's why I emailed this list about it. Please corr= ect me if I am wrong! >=20 > I'm not sure what you think the attack is. I get that you end up with > a signed blob that is sent to someone other than the intended > recipient. So what? >=20 > You might find sections 3 and 4 of > http://www.apache-ssl.org/tech-legal.pdf helpful. >=20 As per [2], if I ever sign a message consisting of "yes" or "no" or some = other short message with very little context, the attacker (whom I encryp= ted the signed message to) could use this signed message in some other co= ntext, fooling people that I said something I didn't. One might argue "ho= w unlikely", but it's still an unnecessary caveat (i.e. complexity) in us= ing encrypted email, which will confuse people not familiar with the deta= ils. My original point was that this attack is a specific example of a general= design flaw in encrypted email - i.e. unsigned/unencrypted headers. I'm not concerned that some legal principle clears me of responsibility; = practical objective security should not be dependant on the efficiency or= subjective justice of any legal system. I would much rather the attack n= ot be possible in the first place. >>>> >>>> [1] >>>> http://crypto.stackexchange.com/questions/5458/should-we-sign-then-e= ncrypt-or-encrypt-then-sign >>>> [2] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html#CITEpg= p >>>> [3] http://www.mozilla-enigmail.org/forum/viewtopic.php?f=3D9&t=3D32= 8 >>>> ------enig2QEBRXVEXEWHSOPUGRATH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJR5uIhAAoJEIYN7zuPZQt5+J4P/R3xKfezFF5xLGCaUien5JqN 8Wkp8Rhs3ojWL530nw0NZOSx0fx3j5/75k6wVUtYj4eM5+4aJj12HIlLBwlKF6ej gfmmBTFSV5LmihD+zzukBwNVWFOewbPCUA8eCcpee2C3SPgIqaNO66dGVyzuDYGa iKv2kiT+bfMCpg2SLM1Upxp4J9yJOSm5SxmJaOQvV18WE5t6aL/ucTWCfbIS8jA4 pdJWylTTv+gQ3R/bzqNOFoD7mB02aYhtindoldvgrvZKvC0k7KjD2tCLNoXGAkQr TuHKt/liDyw8xcdEA9sAi8EbJn0YDMdCLE6N2CrjGSMGCHbnXw+vEb9X1uApOUti Do5e1qIo4KkOPAEVcP94zOmhN5SGmk0CRkUEg8thSvXoMS3LzP3oQU0flIQt3qbe lPhSXkI8thsXZP5FTNkg8NJcZ2UJ+J8vmo32bPp7ynqRzaX4JbbZ6yZXEj+wOWS/ KOmfL2r20TsizK0QzfNxxHNFMaNmvdWfvmnrTM/kML8UCQYDruLkN4JKvpS8vh0z 3+ZNNv0oCTcFq3H01SJawBBdZqwPS4eZGzbb0gcIhFlPbbesptsp2Gf+Ec1AO/10 aG2RHRzp7oGo1sIWjfLFsd2EKULQMBcCaQUw/4Vlam1ewOrgv8Nq55v492mbIZNI L3vGVzIBvRWsoF/P4TMh =2hzT -----END PGP SIGNATURE----- ------enig2QEBRXVEXEWHSOPUGRATH-- From dkg@fifthhorseman.net Wed Jul 17 12:06:21 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4EF821E8097 for ; Wed, 17 Jul 2013 12:06:21 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2udAUzSxLjvf for ; Wed, 17 Jul 2013 12:06:13 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id CEC3021E808F for ; Wed, 17 Jul 2013 12:06:12 -0700 (PDT) Received: from [192.168.23.229] (dsl254-070-154.nyc1.dsl.speakeasy.net [216.254.70.154]) by che.mayfirst.org (Postfix) with ESMTPSA id 6AAF4F948 for ; Wed, 17 Jul 2013 15:06:09 -0400 (EDT) Message-ID: <51E6EB1E.8010209@fifthhorseman.net> Date: Wed, 17 Jul 2013 15:06:06 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 MIME-Version: 1.0 To: openpgp@ietf.org References: <51D360B2.1070709@gmx.com> <51E5BFFC.1040505@gmx.com> <51E6E21C.4020708@gmx.com> In-Reply-To: <51E6E21C.4020708@gmx.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2VMFDMUOCQFBRJNPXOAXT" Subject: Re: [openpgp] signed/encrypted emails vs unsigned/unencrypted headers X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 19:06:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2VMFDMUOCQFBRJNPXOAXT Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/17/2013 02:27 PM, Ximin Luo wrote: > As per [2], if I ever sign a message consisting of "yes" or "no" or som= e other short message with very little context, the attacker (whom I encr= ypted the signed message to) could use this signed message in some other = context, fooling people that I said something I didn't. One might argue "= how unlikely", but it's still an unnecessary caveat (i.e. complexity) in = using encrypted email, which will confuse people not familiar with the de= tails. >=20 > My original point was that this attack is a specific example of a gener= al design flaw in encrypted email - i.e. unsigned/unencrypted headers. the attack you're describing above has nothing to do with encryption; it has to do with signatures. This is a fundamental vulnerability of any system that involves signed data that is dependent for interpretation on unsigned context. This is also the case for (e.g.) clearsigned plain text files. It sounds to me like you're proposing a way that some additional context could be automatically signed by compatible mail user agents. I think this is a fine idea, though i think it needs more detail than what has been sketched out here thus far. For example, what should a compatible MUA do if the signed message contains a signed copy of a header which doesn't match the unsigned header of the message in question? what if a signed message contains two sets of signed headers that conflict with each other? how should an MUA represent the idea that headers are signed? and so forth... it also sounds like it would be relevant for other e-mail signature standards too, since S/MIME (for example) might want the same sort of protection. This makes it out of scope for the current mailing list, since it isn't OpenPGP specific. Werner already suggested that gnupg-users@gnupg.org might be a reasonable place to have this more general discussion. Maybe followup should happen over there? Regards, --dkg ------enig2VMFDMUOCQFBRJNPXOAXT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJR5useXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcJx8P/0DR/epJ8TfAg/1t82w08DK0 hFRjyMfw53rBa/gO4j2DYlTpYpP5fTdDDuICenSVa0PzbT7UWeZ20AauOE7chpf5 UdyoQmVluOaPK6vyv42erxLSWZKo0A/SaT0oVSUiVWTH/Pu5Oxd2R6TfGH3hir6Q /CjNwDCGYIRyQfPMulnV3kh1VL+y6K6pCuV9rnVa3CPiGPQssCWMLVEHgy5qWWur KkCFnCT+KpKyQqiw8Txy3wmTsJSaRJbYB4ubC2Lbf2zq30zp0t4CaU1eoORWfSK4 TlDbVDbyPzeDtYpiFNgTLG+FMnArP+Zj3OF00BbKfHuU8oljZE9oMcUzToz3WtVv kjLUwI8Z1l9kWHu0aYn231SaZmMqoNpZbaHzQXVOf91KnEdsG4sCOCO6R7zIUt+b PBs8X5eWWDkkOk2znQ6yvdxEviFbReSA7UbrRD24eWcxF++t64Et6I/Mfp1FQYDO HziGn0MTC5L/7SLkVSJ3nhMfJaqNIAcSH00ED02nLM0z6T0MGdGHHfTEj+c8VfGO oaQk6gCv05zcArJ3zZR2K7Vl6Msxo+okNR8NA7eQ5c4vZaFzBv1/c2RldnQpm00H kOtIPPv/jAeGftZKNS5GypCR0dBd/6zaBvWSrx+6KPbBPANNBocsrSZmMCii8oI5 ImWqWoSN3q/E+BxgiPiw =IJj6 -----END PGP SIGNATURE----- ------enig2VMFDMUOCQFBRJNPXOAXT-- From infinity0@gmx.com Wed Jul 17 12:42:35 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C7621F8F67 for ; Wed, 17 Jul 2013 12:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23eaRr8HfAaS for ; Wed, 17 Jul 2013 12:42:30 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 18FBC21E804C for ; Wed, 17 Jul 2013 12:42:27 -0700 (PDT) Received: from [192.168.1.66] ([109.152.229.244]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LpObx-1UTlYu1aOz-00fAgT for ; Wed, 17 Jul 2013 21:42:21 +0200 Message-ID: <51E6F39A.8040805@gmx.com> Date: Wed, 17 Jul 2013 20:42:18 +0100 From: Ximin Luo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130518 Icedove/17.0.5 MIME-Version: 1.0 To: openpgp@ietf.org References: <51D360B2.1070709@gmx.com> <51E5BFFC.1040505@gmx.com> <51E6E21C.4020708@gmx.com> <51E6EB1E.8010209@fifthhorseman.net> In-Reply-To: <51E6EB1E.8010209@fifthhorseman.net> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2ETDSLCAUJIKFSFISSUQT" X-Provags-ID: V03:K0:JvZNSf9CMJuy+8FDrOJ2D/qQk3J4m+ich8ZT8NGnb0GSRQvQ/3+ mmfa/vALm+dcnGNrFiGgwOZdaMzH2GWew2EQuiBcEYxYIljYd+2wNgWtcSqMA2ObbFx3zHU OlQiGZqdtR3c6ldVR25l6kgckgbrtVIEvFWdhrPqp5ax7L8oAVaSgEhm81UdabPeDPengMo ICfVx1uhWlcVYvv29F+HQ== Subject: Re: [openpgp] signed/encrypted emails vs unsigned/unencrypted headers X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 19:42:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2ETDSLCAUJIKFSFISSUQT Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 17/07/13 20:06, Daniel Kahn Gillmor wrote: > On 07/17/2013 02:27 PM, Ximin Luo wrote: >> As per [2], if I ever sign a message consisting of "yes" or "no" or so= me other short message with very little context, the attacker (whom I enc= rypted the signed message to) could use this signed message in some other= context, fooling people that I said something I didn't. One might argue = "how unlikely", but it's still an unnecessary caveat (i.e. complexity) in= using encrypted email, which will confuse people not familiar with the d= etails. >> >> My original point was that this attack is a specific example of a gene= ral design flaw in encrypted email - i.e. unsigned/unencrypted headers. >=20 > the attack you're describing above has nothing to do with encryption; i= t > has to do with signatures. >=20 > This is a fundamental vulnerability of any system that involves signed > data that is dependent for interpretation on unsigned context. This is= > also the case for (e.g.) clearsigned plain text files. >=20 It is *mostly* to do with signatures yes, but encryption does play a part= - it adds the implicit *non-signed* information that the data is a messa= ge TO someone. (Although I take your point, a signed non-encrypted email = also has this implicit metadata, and is vulnerable too.) If you signed a = self-contained plain text file, this is not necessarily the case. > It sounds to me like you're proposing a way that some additional contex= t > could be automatically signed by compatible mail user agents. I think > this is a fine idea, though i think it needs more detail than what has > been sketched out here thus far. For example, what should a compatible= > MUA do if the signed message contains a signed copy of a header which > doesn't match the unsigned header of the message in question? what if = a > signed message contains two sets of signed headers that conflict with > each other? how should an MUA represent the idea that headers are > signed? and so forth... >=20 > it also sounds like it would be relevant for other e-mail signature > standards too, since S/MIME (for example) might want the same sort of > protection. This makes it out of scope for the current mailing list, > since it isn't OpenPGP specific. >=20 > Werner already suggested that gnupg-users@gnupg.org might be a > reasonable place to have this more general discussion. Maybe followup > should happen over there? >=20 Good points and yes, I will take this discussion there. Thanks for all the info and comments everyone! ------enig2ETDSLCAUJIKFSFISSUQT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJR5vOaAAoJEIYN7zuPZQt5zZIQALT4CPgFGJCsOL4MB4NYd1sI Ha6anFXJjqA+pwUpx4nuAIBIGerOEHbXOzUBZFVqaljCrzT+7QCuGhmtPeBYNJTY RQzohJPCv9QOsnBU7BKcw6QhQOHuYi7wJTtiF/5/nJeEKV16MitPQFARWGTkPuG+ s/CPL91femIR0u6mZre4vIE6nuv1Q3PsCXne6rzvbrFpsnSy6YzfiJzlmlE9rOGS f/Gv3o/eh0dQWx3SXcRm4gKrVM08C9HDKaBuOVYmC+RHfZKkSomh2EFKtOtTjtHa 5MZXvE5411kvm51A6WAQUP8t81I57bXraqjBUvWXeHWG7wEqT2JYW1X5yRShouhe TeJx4zynDWMfu6ZN8bpNgGl9LfDfTkYDeXipxXTlFurhE2ljTgc3nq4HJQ9KXGvJ zGBEI/vra/+4vVNYNG71W77Cas3kMeKrr2ml+9LdThsv5swbQX0/xUrF4vP4ZaHq ZRngDuSwEkSGnE3PW+x1eI3Ylj6fFXi9+1Bo3F9LzeQieS+yOM0CxwRV9KunDKxf A3TvzTi0mnhx6usVHc1pSTUaH5CM8G0hYSvGarjyVNvhvmmQGVPVaTwuRjh8v8qY rdm5iKFw7jFLqD7d6MJYwyH+NbADrAa/Ob1YWzVBCszotA+doZlzydaNRSZfj2+7 B72YjHucGJ76FMAVhc0A =89KK -----END PGP SIGNATURE----- ------enig2ETDSLCAUJIKFSFISSUQT-- From openpgp@brainhub.org Thu Jul 18 11:37:30 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8654721E8167 for ; Thu, 18 Jul 2013 11:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgIjTIcLJKNx for ; Thu, 18 Jul 2013 11:37:26 -0700 (PDT) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:96]) by ietfa.amsl.com (Postfix) with ESMTP id 3A51021E8161 for ; Thu, 18 Jul 2013 11:37:23 -0700 (PDT) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta09.emeryville.ca.mail.comcast.net with comcast id 1uCd1m00B0vp7WLA9udNVs; Thu, 18 Jul 2013 18:37:22 +0000 Received: from [127.0.0.1] ([69.181.162.123]) by omta05.emeryville.ca.mail.comcast.net with comcast id 1udL1m00Y2g33ZR8RudLfs; Thu, 18 Jul 2013 18:37:22 +0000 Message-ID: <51E8350E.7010403@brainhub.org> Date: Thu, 18 Jul 2013 11:33:50 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: openpgp@ietf.org References: <51E482E5.5020201@brainhub.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374172642; bh=482shEaz74hHUCQl6CPOB1zmFeKaQFTIKMx601UNV9k=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=m/5zLl9KgNN9Pm8UzynG9n/rdHZuaqT8ocNW5SHoKG84YrQg+q1ReKgc5tEjeFnVJ 23XncN48rPsc/w2iQFU6b5wOwHMC0rwiM8Kq1EVUbe9f3gmrSRE+OSgqHhqBacvadB nLJfqkYil36uReqURXiBgmfRYm8UKb+VfswJCeJhjvkg807kR8XVnBMoeU1IxdaVnV yUIiKFOgLlgrdK37tBB3/1tyOSsr5sHtHjQ6ju5LVgHLQVuUI7d/KtxRln8Xc36LY8 2w/Mv6uSeFQUEKPCFfUR80RdoPgWj79JjhtJAEcAXZ01yxrA/5TCBN1csB2rfXnqfA l2yiDAtU7O1Kg== Cc: Paul Wouters Subject: Re: [openpgp] Fwd: New Version Notification for draft-wouters-dane-openpgp-00.txt (fwd) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 18:37:30 -0000 On 07/15/2013 07:01 PM, Paul Wouters wrote: > On Mon, 15 Jul 2013, Andrey Jivsov wrote: > >> A few quick comments follow. > > Thanks for the comments. > >> This ignores prior work in this area. https://keyserver.pgp.com is >> known to solve exactly the problems you described for many years now. > > Ahh, yet another different webgui? I see the howto also states "You can > only remove your own key and the email address must match exactly". I > had one of my email addresses yanked two years ago with zero notice. I > would not have been able to remove my key. But even so, many (most?) > people still seem to use other more well known, non-commercial, > keyservers, such as pgp.mit.edu and pgp.surfnet.nl. Even if I use very > secure key servers, if people look for my key on crappy old key servers, > the risk remains. Yes, it's a valid use case. The https://keyserver.pgp.com server will periodically send renewal requests to e-mails on the key, and if the owner doesn't reply the key key will be deleted. > >> 2. Given that the size of the record is very important when stored in >> DNS records, it's odd to see that ECC OpenPGP keys are not even >> mentioned. > > I specifically did not want to limit the record to any particular type. > I just wanted it to support RFC OpenPGP compliant keys. Some people > don't want to use ECC (for legal other other reasons). Others don't > want to use ElGamal, DSA, RSA, etc. There is no reason for this draft > to distinguish and force people to pick a specific key type. I agree that support for all keys is one way to do this, but this intention is unclear from the draft-wouters-dane-openpgp-00.txt: if one mentions RFC 4880 but not RFC 6637, it can be interpreted as the exclusion of ECC keys. ... From paul@nohats.ca Thu Jul 18 12:21:39 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13CEF11E81F6 for ; Thu, 18 Jul 2013 12:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.693 X-Spam-Level: X-Spam-Status: No, score=-2.693 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYwEBGmirl5L for ; Thu, 18 Jul 2013 12:21:28 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2621A11E81E2 for ; Thu, 18 Jul 2013 12:21:27 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3bx4vj15Rmz6qQ; Thu, 18 Jul 2013 15:21:21 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id B1HkXEUWKS4o; Thu, 18 Jul 2013 15:21:20 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Thu, 18 Jul 2013 15:21:19 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id E0D6E8188E; Thu, 18 Jul 2013 15:21:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D4E208179A; Thu, 18 Jul 2013 15:21:19 -0400 (EDT) Date: Thu, 18 Jul 2013 15:21:19 -0400 (EDT) From: Paul Wouters To: Andrey Jivsov In-Reply-To: <51E8350E.7010403@brainhub.org> Message-ID: References: <51E482E5.5020201@brainhub.org> <51E8350E.7010403@brainhub.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: openpgp@ietf.org Subject: Re: [openpgp] Fwd: New Version Notification for draft-wouters-dane-openpgp-00.txt (fwd) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 19:21:39 -0000 On Thu, 18 Jul 2013, Andrey Jivsov wrote: >>> 2. Given that the size of the record is very important when stored in >>> DNS records, it's odd to see that ECC OpenPGP keys are not even >>> mentioned. >> >> I specifically did not want to limit the record to any particular type. >> I just wanted it to support RFC OpenPGP compliant keys. Some people >> don't want to use ECC (for legal other other reasons). Others don't >> want to use ElGamal, DSA, RSA, etc. There is no reason for this draft >> to distinguish and force people to pick a specific key type. > > I agree that support for all keys is one way to do this, but this intention > is unclear from the draft-wouters-dane-openpgp-00.txt: if one mentions RFC > 4880 but not RFC 6637, it can be interpreted as the exclusion of ECC keys. I was simply not aware of RFC 6637. I will add a reference to it in the document. Thanks! Paul From openpgp@brainhub.org Thu Jul 18 13:07:50 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECE321E80F7 for ; Thu, 18 Jul 2013 13:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.94 X-Spam-Level: X-Spam-Status: No, score=0.94 tagged_above=-999 required=5 tests=[AWL=-1.377, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FRT_BELOW2=2.154, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_45=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7N2imAIDK7Fk for ; Thu, 18 Jul 2013 13:07:44 -0700 (PDT) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id 9081B21E80F6 for ; Thu, 18 Jul 2013 13:07:44 -0700 (PDT) Received: from omta11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by qmta01.emeryville.ca.mail.comcast.net with comcast id 1v7y1m0050mlR8UA1w7krQ; Thu, 18 Jul 2013 20:07:44 +0000 Received: from [127.0.0.1] ([69.181.162.123]) by omta11.emeryville.ca.mail.comcast.net with comcast id 1w7i1m00d2g33ZR8Xw7jov; Thu, 18 Jul 2013 20:07:43 +0000 Message-ID: <51E84A3C.8060800@brainhub.org> Date: Thu, 18 Jul 2013 13:04:12 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: openpgp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374178064; bh=7G0GlKwEFkFJ3hRqTzVHiJZYambI78dZ7CYT4ImWnCY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=cODKm+JStDqV7XuS3xMeWdkhY6aWSqY2T8e4DavOwSCpJlAnh0cC1kiQNcluxyM2i eP0JMV7HPePfJITeNCh3Hmd7bjNK7BEaK1geLaypqmkuuqwHJxiCcOy29fDhTDG5Wh J7jTE1I8L7u2n7ft+/4vQAGKqWzpZSnAEoMXRN3QXtexH3mPfuSCCFzAa3YuWyh5+W yUvBPOT5vhuyJjOgqVfq9Kenc4SjQuOvauGwW6A8Z8j/ugexXXDufeqnNDB1FOyT1x LFXW10XRtJGyYf27lCBu4w0JafIfVAPeHLR6F1e0AZ6VSogHokr2LzVvhSdg3DC+NE zyYQLZWM/+bNQ== Subject: [openpgp] PKI (RFC 5480) mapping to ECC keys (RFC 6637) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 20:07:50 -0000 Hello. I noticed one unfortunate inconvenience about ECC public key definition. Currently RFC 6637 defines two types of keys: ID 18: ECDH ID 19: ECDSA but no "joint" or "unlimited" ID. As shown bellow, this is needed for easier interchangeability with PKI standards. I was probably hypnotized by the already reserved ID 18 for ECDSA in RFC 4880 to not think in general terms, which is: Given that EC keys can do both signing+encryption, just as RSA keys, why there isn't a single public key ID (i.e. the analog to ID 1 for RSA). We have key usage flags to narrow down the usage. The issue is that it's justifiable in many cases to have a single top-key only OpenPGP key and such a key should be capable of both signing+encryption. In particular, this issue comes up when one tries to map an X.509 ECC certificate, as defined in RFC 5480, to RFC 6637. As I understand it based on my observations of the current use of ECC X.509 certificates, the most common usage will be sec 2.1.1 of RFC 5480, which defines an "unrestricted" id-ecPublicKey algorithm identifier. The problem is that there is no way to map it cleanly into an RFC 6637 ID. RFC 5480 also has restricted id-ecDH (but not sign-only ID). Interestingly, there is no sign-only ID in RFC 5480, thus, even CA certificates that are restricted to signing will get id-ecPublicKey algorithm ID. In RFC 6637, ID 18 (ECDH) is a superset of fields of ID 19 (ECDSA) What are the possible fixes here? 1. Add ID 20 that is ECDH+ECDSA. It will be defined identically to ID 18 (ECDH), but will also be allowed to perform the signature/verification functionality of ID 19 (ECDSA). 2. Overload ID 18 to allow ECDSA. One problem here is that it we loose the ability to map id-ecDH into ID 18. 3. Overload of ID 19 will not work, because it lacks KEK parameters that are needed for encryption. Plus, sign-only application are useful for regulatory compliance (because it's not encryption). I assume that it will be common (or at least possible) to issue end-user X.509 certificates for SMIME that are signing+encryption. Thus, even though current PKI CA certificates can be mapped to ID 19 based on keyUsage flags, we cannot do this in all cases. I see #1 as the only perfect solution for the problem. Does anybody have any other thought about how to proceed? Thank you. From dkg@fifthhorseman.net Thu Jul 18 13:18:03 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3EF11E81ED for ; Thu, 18 Jul 2013 13:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+r7gMbqLJFH for ; Thu, 18 Jul 2013 13:17:59 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id F03EE11E81A1 for ; Thu, 18 Jul 2013 13:17:58 -0700 (PDT) Received: from [192.168.13.182] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 7D937F948 for ; Thu, 18 Jul 2013 16:17:56 -0400 (EDT) Message-ID: <51E84D72.2010406@fifthhorseman.net> Date: Thu, 18 Jul 2013 16:17:54 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 MIME-Version: 1.0 To: openpgp@ietf.org References: <51E84A3C.8060800@brainhub.org> In-Reply-To: <51E84A3C.8060800@brainhub.org> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2UFVHPUNHNEOFCRKHABPH" Subject: Re: [openpgp] PKI (RFC 5480) mapping to ECC keys (RFC 6637) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 20:18:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2UFVHPUNHNEOFCRKHABPH Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/18/2013 04:04 PM, Andrey Jivsov wrote: > 1. Add ID 20 that is ECDH+ECDSA. It will be defined identically to ID 1= 8 > (ECDH), but will also be allowed to perform the signature/verification > functionality of ID 19 (ECDSA). >=20 > 2. Overload ID 18 to allow ECDSA. One problem here is that it we loose > the ability to map id-ecDH into ID 18. >=20 > 3. Overload of ID 19 will not work, because it lacks KEK parameters tha= t > are needed for encryption. Plus, sign-only application are useful for > regulatory compliance (because it's not encryption). >=20 > I assume that it will be common (or at least possible) to issue end-use= r > X.509 certificates for SMIME that are signing+encryption. Thus, even > though current PKI CA certificates can be mapped to ID 19 based on > keyUsage flags, we cannot do this in all cases. >=20 > I see #1 as the only perfect solution for the problem. Does anybody hav= e > any other thought about how to proceed? Your first proposed solution (#1) seems reasonable to me, and not without precedent. It's similar to the asymmetric key IDs allocated for RSA: https://tools.ietf.org/html/rfc4880#section-9.1 1 - RSA (Encrypt or Sign) [HAC] 2 - RSA Encrypt-Only [HAC] 3 - RSA Sign-Only [HAC] Regards, --dkg ------enig2UFVHPUNHNEOFCRKHABPH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJR6E1yXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc6o8QAJUZVLbjygO9TaYWTWcgp1j1 q5pEM+u+9oWJV4KlItfTjFZSGcRelHZ2a0xTzVcmFD9LM4AqPdvooXaVVviokdDZ B5kHgSxBLh/vtwiOPcWyo/ghqhpFezT7kn+gzw+eYwZO/QN0F2QiWmrgtBX20XqN aDe7jCrxDvXzP1I2v9g/2yb8naJkZ6ms/5qOFA3SQkIpHP9NZAXvIHVirIzkwO7o sweBog3kaIc+a8yR7dNI6gAnn2M5PZTn8JmbD2UiJ3YNlgXTkoocJBxXQU1lE4ks xwZKvNBqG+tvFBcn2PduHLiH2gdaREiXY4aK95nRniNzHlXSde2AdD7HcKP2ro0y go8jXF5sxM/glaX5ZjcdBAAswgxe4wCkRgzCfMT1F6JRvKQg91lMMsamPiMBSenZ U1SYlSzA9QPt7b4rl1XLvBxOc6AJ4KxLHziO0+vDwUtvfOUUeBRcUBQ2VgGMVKx4 OH9yH27yXrop2hAmIJEigsXyCHbkH9HxzEYLtYGIIGZrfZ4h8T5i4cllkKJyH5br JYfDW/Q2385tFExcwlaqZGSOnBqO3Sf0h7eB5ppXcVtpBBz8Ji24VvihaakaqcMG 5RRN2p9DNs3BvkYu6+9z1eq970mWP1TeXFsH8zteSOMUZLSLV9MAiblh/ReL2jWB Fp4YDi2S5JKurGGq9kK+ =ytAF -----END PGP SIGNATURE----- ------enig2UFVHPUNHNEOFCRKHABPH-- From wk@gnupg.org Fri Jul 19 05:39:49 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD57A11E8117 for ; Fri, 19 Jul 2013 05:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfLLN4xCrTUW for ; Fri, 19 Jul 2013 05:39:44 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBFB11E8105 for ; Fri, 19 Jul 2013 05:39:44 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1V09yG-000522-1E for ; Fri, 19 Jul 2013 14:39:40 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.80 #3 (Debian)) id 1V09tN-0002eO-Us; Fri, 19 Jul 2013 14:34:37 +0200 From: Werner Koch To: Andrey Jivsov References: <51E84A3C.8060800@brainhub.org> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Fri, 19 Jul 2013 14:34:37 +0200 In-Reply-To: <51E84A3C.8060800@brainhub.org> (Andrey Jivsov's message of "Thu, 18 Jul 2013 13:04:12 -0700") Message-ID: <87a9lid8yq.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: openpgp@ietf.org Subject: Re: [openpgp] PKI (RFC 5480) mapping to ECC keys (RFC 6637) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 12:39:49 -0000 On Thu, 18 Jul 2013 22:04, openpgp@brainhub.org said: > 1. Add ID 20 that is ECDH+ECDSA. It will be defined identically to ID > 18 (ECDH), but will also be allowed to perform the > signature/verification functionality of ID 19 (ECDSA). You can't use 20 because it was used for Elgamal in rfc2440. A new one needs to be allocated. 22 would be the next. > I assume that it will be common (or at least possible) to issue > end-user X.509 certificates for SMIME that are > signing+encryption. Thus, even though current PKI CA certificates can > be mapped to ID 19 based on keyUsage flags, we cannot do this in all Frankly I can't see why this is an advantage. X.509 and OpenPGP are enitirely different and having the same algorthm numbers does not matter at all. > I see #1 as the only perfect solution for the problem. Does anybody > have any other thought about how to proceed? The IETF consonsus method shall be used for new algorithms. Thus you need to write an I-D. IIRC, you are already working on a compressed ECC key specification. What about using the new algorithm for this - or at least to use that I-D for adding a new algorithm number? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From openpgp@brainhub.org Fri Jul 19 13:26:52 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89FF11E81AD for ; Fri, 19 Jul 2013 13:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.807 X-Spam-Level: X-Spam-Status: No, score=0.807 tagged_above=-999 required=5 tests=[AWL=-0.556, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_45=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_54=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBZ01R+EtgWx for ; Fri, 19 Jul 2013 13:26:48 -0700 (PDT) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id 368FC11E8141 for ; Fri, 19 Jul 2013 13:26:41 -0700 (PDT) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta01.emeryville.ca.mail.comcast.net with comcast id 2JtM1m0051ZMdJ4A1LSgbj; Fri, 19 Jul 2013 20:26:40 +0000 Received: from [127.0.0.1] ([69.181.162.123]) by omta16.emeryville.ca.mail.comcast.net with comcast id 2LSf1m0072g33ZR8cLSgjb; Fri, 19 Jul 2013 20:26:40 +0000 Message-ID: <51E9A029.6000303@brainhub.org> Date: Fri, 19 Jul 2013 13:23:05 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: openpgp@ietf.org References: <51E84A3C.8060800@brainhub.org> <87a9lid8yq.fsf@vigenere.g10code.de> In-Reply-To: <87a9lid8yq.fsf@vigenere.g10code.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374265600; bh=Zsb75CjucMOSDuH5uducCTzTyLBNyZvPWzvfvesUohw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kAXzac/AH31U/PLe33P5QxPQsVT3oXTeIWbEkoWE9srBYBEmP7Q4TGnmOFQoPQ6VJ Gm84SHr9hbEnvaUV/ilxTM2WeyLCvOYt2zFUf/bTAR8Kv89jA/xNxjIH7PwsgreX1H Yf4fmgzFYRaPY1TfPvcdhS8y6JDQ4dJC5KOgZnv+fVTsbzyXxMeopFCsT22A7tz1H1 6TPCryBNVdRDeNLY8jKGIcaTaZT5B8ZQjj58xrtm41EXbr9uK1SS6GMgjLWRAlQRyo igc4s/UoWK1fXx8Zs84GV2FmN7GtqT1PnNZtRwu4a5FViDvSfDiJtBW/MRARrsMIY0 vXZR4dlkrn3tg== Subject: Re: [openpgp] PKI (RFC 5480) mapping to ECC keys (RFC 6637) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 20:26:52 -0000 He Werner. On 07/19/2013 05:34 AM, Werner Koch wrote: > On Thu, 18 Jul 2013 22:04, openpgp@brainhub.org said: > >> 1. Add ID 20 that is ECDH+ECDSA. It will be defined identically to ID >> 18 (ECDH), but will also be allowed to perform the >> signature/verification functionality of ID 19 (ECDSA). > > You can't use 20 because it was used for Elgamal in rfc2440. A new one > needs to be allocated. 22 would be the next. I was thinking about recycling ID 20, given that there is small benefit for the IDs to be consecutive. The simplification is generic. Now that we would have 3 IDs for ECC, it is more efficient to check 18 <= x <= 20 then for 3 arbitrary IDs. Also, consecutive IDs allow easy transition to zero-based indexing (just subtract 18). Current definition of 20 in RFC 4880 is: 20 - Reserved (formerly Elgamal Encrypt or Sign) In RFC 2440 it is: 20 - Elgamal (Encrypt or Sign) Do we know of at least one case when 20 is used in deployed applications? This will be enough to require 22 for ECDSA+ECDH. > >> I assume that it will be common (or at least possible) to issue >> end-user X.509 certificates for SMIME that are >> signing+encryption. Thus, even though current PKI CA certificates can >> be mapped to ID 19 based on keyUsage flags, we cannot do this in all > > Frankly I can't see why this is an advantage. X.509 and OpenPGP are > enitirely different and having the same algorthm numbers does not matter > at all. I am not sure what exactly do you mean. Let me answer why do I think that ECDSA+ECDH ID is a useful feature. Alignment with the PKI standard is helpful in applications where one maps an X.509 certificate into an OpenPGP key. See, for example, http://www.ietf.org/mail-archive/web/openpgp/current/msg01742.html Turns out that ECC certificates use id-ecPublicKey and then restrict usage with key flags, exactly as most of OpenPGP keys are doing it right now. Assuming that most OpenPGP keys are RSA keys, they use sign+encrypt ID 1 and then use the appropriate key usage flags. Often the key usage needs to be adjusted after the key generation. For example, it was an encryption-only subkey originally and the user wants to make it sign+encryption. OpenPGP doesn't offer this feature right now for ECC keys (while it does so for RSA). With current RFC 6637 this usage change would mean a new KeyID. > >> I see #1 as the only perfect solution for the problem. Does anybody >> have any other thought about how to proceed? > > The IETF consonsus method shall be used for new algorithms. Thus you > need to write an I-D. IIRC, you are already working on a compressed ECC > key specification. What about using the new algorithm for this - or at > least to use that I-D for adding a new algorithm number? The compact ECC point representation plus ECDSA+ECDH ID in a single document is one way to do this. I was wondering, however, that given that ECDSA+ECDH ID is such an easy change that fits in a few sentences, it feels like an errata to the RFC 6637. All it needs to say is that "use ID 2x for ECDSA+ECDH" and then define that ID in another sentence. The compact point document is a logically different document. RFC 6637 attained the "Standards Track", while the compact point will likely be "Informational" and optional. > > > Shalom-Salam, > > Werner > From paul@nohats.ca Fri Jul 19 13:33:12 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B3A11E81A3 for ; Fri, 19 Jul 2013 13:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=-0.384, BAYES_00=-2.599, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Vt9rBg5Wcih for ; Fri, 19 Jul 2013 13:33:05 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3B56C11E819F for ; Fri, 19 Jul 2013 13:33:03 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3bxkRs2GQlz1wM; Fri, 19 Jul 2013 16:32:57 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id ZJU5luUm9aCf; Fri, 19 Jul 2013 16:32:56 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Fri, 19 Jul 2013 16:32:56 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 60FEF80FB2; Fri, 19 Jul 2013 16:32:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5097280EF3; Fri, 19 Jul 2013 16:32:57 -0400 (EDT) Date: Fri, 19 Jul 2013 16:32:57 -0400 (EDT) From: Paul Wouters To: Andrey Jivsov In-Reply-To: <51E9A029.6000303@brainhub.org> Message-ID: References: <51E84A3C.8060800@brainhub.org> <87a9lid8yq.fsf@vigenere.g10code.de> <51E9A029.6000303@brainhub.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: openpgp@ietf.org Subject: Re: [openpgp] PKI (RFC 5480) mapping to ECC keys (RFC 6637) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 20:33:14 -0000 On Fri, 19 Jul 2013, Andrey Jivsov wrote: >> You can't use 20 because it was used for Elgamal in rfc2440. A new one >> needs to be allocated. 22 would be the next. Indeed. > I was thinking about recycling ID 20, given that there is small benefit for > the IDs to be consecutive. > > The simplification is generic. Now that we would have 3 IDs for ECC, it is > more efficient to check 18 <= x <= 20 then for 3 arbitrary IDs. Also, > consecutive IDs allow easy transition to zero-based indexing (just subtract > 18). Those "benefits" are just coding errors waiting to happen in the future. A switch statement seems much more appropriate. > Current definition of 20 in RFC 4880 is: > > 20 - Reserved (formerly Elgamal Encrypt or Sign) > > In RFC 2440 it is: > > 20 - Elgamal (Encrypt or Sign) > > Do we know of at least one case when 20 is used in deployed applications? > This will be enough to require 22 for ECDSA+ECDH. Even with no implementation out there, the allocated numbers should not be recycled, unless in extreme use cases, eg where we've ran out of numbers. Paul From wk@gnupg.org Sat Jul 20 01:24:59 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA35B11E80CC for ; Sat, 20 Jul 2013 01:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.949 X-Spam-Level: X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vn7aMtS+Lwy7 for ; Sat, 20 Jul 2013 01:24:54 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by ietfa.amsl.com (Postfix) with ESMTP id DC98811E8135 for ; Sat, 20 Jul 2013 01:24:53 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1V0ST2-0000h1-KD for ; Sat, 20 Jul 2013 10:24:40 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.80 #3 (Debian)) id 1V0SOY-0003iQ-HM; Sat, 20 Jul 2013 10:20:02 +0200 From: Werner Koch To: Andrey Jivsov References: <51E84A3C.8060800@brainhub.org> <87a9lid8yq.fsf@vigenere.g10code.de> <51E9A029.6000303@brainhub.org> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Sat, 20 Jul 2013 10:20:02 +0200 In-Reply-To: <51E9A029.6000303@brainhub.org> (Andrey Jivsov's message of "Fri, 19 Jul 2013 13:23:05 -0700") Message-ID: <87zjthabil.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: openpgp@ietf.org Subject: Re: [openpgp] PKI (RFC 5480) mapping to ECC keys (RFC 6637) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 08:24:59 -0000 On Fri, 19 Jul 2013 22:23, openpgp@brainhub.org said: > The simplification is generic. Now that we would have 3 IDs for ECC, > it is more efficient to check 18 <=3D x <=3D 20 then for 3 arbitrary Compared to the cyrpto operations any efficieny here is a joke. > Do we know of at least one case when 20 is used in deployed > applications? This will be enough to require 22 for ECDSA+ECDH. GnuPG supported this from 1998 to 1.3.5 (2004-02-26). I have hundreds of those signatures in my keyrings despite that there is no more support in GnuPG. Recycling this identifier would be a Bad Thing=E2=84=A2. Intern= al PGP versions used a couple of the lower numbered IDs and they have not been recycled, either. > Let me answer why do I think that ECDSA+ECDH ID is a useful feature. I agree that it is useful; I only remarked that the X.509 based rationale is a bit weak. > right now. Assuming that most OpenPGP keys are RSA keys, they use > sign+encrypt ID 1 and then use the appropriate key usage flags. Or 2 or 3. They still pop once once in a while. > The compact ECC point representation plus ECDSA+ECDH ID in a single > document is one way to do this. >From my understanding of the IETF procedures this will indeed be the case. > I was wondering, however, that given that ECDSA+ECDH ID is such an > easy change that fits in a few sentences, it feels like an errata to > the RFC 6637. All it needs to say is that "use ID 2x for ECDSA+ECDH" > and then define that ID in another sentence. Maybe, but recall rfc4880 states: initial values for this registry can be found in Section 9. Adding a new public-key algorithm MUST be done through the IETF CONSENSUS method, as described in [RFC2434]. That is for an algorithm but not the id, though. Please use whatever is the easiest way for you. I would appreciate if we could informally agree on an identifier right now so that I can put it into the next GnuPG 1.4 release which is due in a few days. This would avoid a '?' as algorithm in a key listing. Salam-Shalom, Werner --=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From openpgp@brainhub.org Sat Jul 20 13:54:08 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B6B11E80D1 for ; Sat, 20 Jul 2013 13:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.318 X-Spam-Level: X-Spam-Status: No, score=0.318 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_54=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpNgfaQDdFXM for ; Sat, 20 Jul 2013 13:54:03 -0700 (PDT) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:64]) by ietfa.amsl.com (Postfix) with ESMTP id 1826A21F9644 for ; Sat, 20 Jul 2013 13:54:02 -0700 (PDT) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta07.emeryville.ca.mail.comcast.net with comcast id 2kRH1m0020b6N64A7ku2l4; Sat, 20 Jul 2013 20:54:02 +0000 Received: from [192.168.1.8] ([69.181.162.123]) by omta03.emeryville.ca.mail.comcast.net with comcast id 2ku11m00E2g33ZR8Pku1QS; Sat, 20 Jul 2013 20:54:02 +0000 Message-ID: <51EAF8E9.5050406@brainhub.org> Date: Sat, 20 Jul 2013 13:54:01 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: openpgp@ietf.org References: <51E84A3C.8060800@brainhub.org> <87a9lid8yq.fsf@vigenere.g10code.de> <51E9A029.6000303@brainhub.org> <87zjthabil.fsf@vigenere.g10code.de> In-Reply-To: <87zjthabil.fsf@vigenere.g10code.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374353642; bh=TGwF9qBE4qkO12eYmZXFMoAHIoqgg22RNcm2RSuZYuk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=dUxbAGDaF5QFwgTXkaHElFKTJK4VA7fud+PKvG/NDA5KQ9SPp1tFHldauLg1jp0Sy 9IvQkOV2hFJ+jhOI+s9ZEsom2Jv1bC0z3ItioBxYR7Ukz6D/yIwv7susXGl6iHCzyi JCzrDGiWsMV7ikO0V/NYWtJVJym4yNj/9oVksLtOUsM9F0OIz0aWpFm/NmqIwD8F4u 6vZ3QT0ZKFJi09AAI1mDuX7pWvSdIfQutc94khUGJDzd8cmyJQAZpujHSC9ZUhIlxn lnB/sjNe5+8HfvLtOSWOWS0HVNMaAPD3qkxLby0N5s2lT/OIAsmml1mtjeB2Hs8zY2 mVcBXy9t3nmUg== Cc: Werner Koch Subject: Re: [openpgp] PKI (RFC 5480) mapping to ECC keys (RFC 6637) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 20:54:08 -0000 On 07/20/2013 01:20 AM, Werner Koch wrote: ... > I would appreciate if we could informally agree on an identifier right > now so that I can put it into the next GnuPG 1.4 release which is due in > a few days. This would avoid a '?' as algorithm in a key listing. Your earlier e-mail leaves us with 22 for ECDSA+ECDH. From wk@gnupg.org Sat Jul 20 15:24:48 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02AF321F880F for ; Sat, 20 Jul 2013 15:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.17 X-Spam-Level: X-Spam-Status: No, score=-10.17 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hR9OzhxSWfXl for ; Sat, 20 Jul 2013 15:24:43 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by ietfa.amsl.com (Postfix) with ESMTP id CD76F11E80ED for ; Sat, 20 Jul 2013 15:24:42 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1V0fZx-0003L5-HB for ; Sun, 21 Jul 2013 00:24:41 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.80 #3 (Debian)) id 1V0fRA-0006SO-SP; Sun, 21 Jul 2013 00:15:36 +0200 From: Werner Koch To: Andrey Jivsov References: <51E84A3C.8060800@brainhub.org> <87a9lid8yq.fsf@vigenere.g10code.de> <51E9A029.6000303@brainhub.org> <87zjthabil.fsf@vigenere.g10code.de> <51EAF8E9.5050406@brainhub.org> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Sun, 21 Jul 2013 00:15:36 +0200 In-Reply-To: <51EAF8E9.5050406@brainhub.org> (Andrey Jivsov's message of "Sat, 20 Jul 2013 13:54:01 -0700") Message-ID: <87wqok98tz.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: openpgp@ietf.org Subject: Re: [openpgp] PKI (RFC 5480) mapping to ECC keys (RFC 6637) X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 22:24:48 -0000 On Sat, 20 Jul 2013 22:54, openpgp@brainhub.org said: > Your earlier e-mail leaves us with 22 for ECDSA+ECDH. Very well. It is easy to remember. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From iang@iang.org Fri Jul 26 01:00:02 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E196D21F8A53 for ; Fri, 26 Jul 2013 01:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbX8iO2j13JG for ; Fri, 26 Jul 2013 00:59:57 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) by ietfa.amsl.com (Postfix) with ESMTP id AD6B221F8934 for ; Fri, 26 Jul 2013 00:59:57 -0700 (PDT) Received: from tormenta.local (www2.futureware.at [78.41.115.142]) by virulha.pair.com (Postfix) with ESMTPSA id DB5196D48B; Fri, 26 Jul 2013 03:59:50 -0400 (EDT) Message-ID: <51F22C78.3070300@iang.org> Date: Fri, 26 Jul 2013 10:59:52 +0300 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: openpgp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [openpgp] Flush+Reload: a High Resolution, Low Noise, L3 Cache Side-Channel Attack X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 08:00:02 -0000 might be of some interest, h/t to Jeff Walton: ---------- Forwarded message ---------- From: Hurgel Bumpf Date: Fri, Jul 26, 2013 at 2:31 AM Subject: [Full-disclosure] Flush+Reload: a High Resolution, Low Noise, L3 Cache Side-Channel Attack To: "full-disclosure@lists.grok.org.uk" Just found this online.. might be of interest Abstract: Flush+Reload is a cache side-channel attack that monitors access to data in shared pages. In this paper we demonstrate how to use the attack to extract private encryption keys from GnuPG. The high resolution and low noise of the Flush+Reload attack enables a spy program to recover over 98% of the bits of the private key in a single decryption or signing round. Unlike previous attacks, the attack targets the last level L3 cache. Consequently, the spy program and the victim do not need to share the execution core of the CPU. The attack is not limited to a traditional OS and can be used in a virtualised environment, where it can attack programs executing in a different VM. Category / Keywords: Side Channel Attack, Cache, RSA, Exponentiation Date: received 18 Jul 2013 By: Yuval Yarom and Katrina Falkner http://eprint.iacr.org/2013/448 Direct PDF: http://eprint.iacr.org/2013/448.pdf --- Have a nice Friday, Bonan the bavarian _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/