Re: secure sign & encrypt
pgut001@cs.auckland.ac.nz (Peter Gutmann) Thu, 23 May 2002 05:19 UTC
Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18334 for <openpgp-archive@odin.ietf.org>; Thu, 23 May 2002 01:19:38 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4N49fv09884 for ietf-openpgp-bks; Wed, 22 May 2002 21:09:41 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4N49dL09880 for <ietf-openpgp@imc.org>; Wed, 22 May 2002 21:09:39 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.3/8.12.3) with ESMTP id g4N49Yaq009503; Thu, 23 May 2002 16:09:34 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id QAA446700; Thu, 23 May 2002 16:09:33 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz)
Date: Thu, 23 May 2002 16:09:33 +1200
Message-ID: <200205230409.QAA446700@ruru.cs.auckland.ac.nz>
From: pgut001@cs.auckland.ac.nz
To: vedaal@hotmail.com, warlord@mit.edu
Subject: Re: secure sign & encrypt
Cc: ietf-openpgp@imc.org
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Derek Atkins <warlord@mit.edu> writes: >No, the best way around this problem is the USER INTERFACE and EDUCATION. Jim Schaad posted a good analysis of this a while back. It's attached below for people who haven't seen it. Peter. -- Snip -- I was hoping that this issue was going to disappear if I ignored it. I feel that the problem listed, while potentially interesting, is not one that can be solved via this type of mechanism. The problem: I get a message, signed, and I forward it to you signed and then possibly encrypted. You believe that since it was encrypted to you that nobody else could have sent it but the signer. Response: 1) A better answer is to put names in e-mail. 2) Am I suppose to start doing this for all signed mail. 3) How do I convince a large company like Microsoft that this is even an interesting problem for them to "fix" in their mail. 4) This does not fix information leaks in anyway. (A far more interesting problem in my estimation.) Why this does not work: I don't know how to begin to tell Microsoft how to write this code. The simple case is, if my mail box name is not on the To/CC line then pop up a warning message. But this is not an easy thing to say and program in. 1. When I was working at Microsoft, people sent me mail at the address "jimsch@microsoft.com", my mailbox name was "jimsch@exhange.microsoft.com". There is no way to determine that these are or are not the same address. While in this case they were they could just have easily been different addresses. 2. Today, the email address that I give people is "jimsch@exmsft.com", but this is not the mail box address that I use. This address forwards mail to a second address where I down-load my mail from. Now either the message is always going to show up for me, or I have a configuration issue to explain to users (and to write UI for). 3. If I receive e-mail because I am on a mailing list (such as this mailing list), either I get the message for all mail to that list, or I have a configureation issue to explain to users (and to write UI for). This becomes even more fun if you look at nested mailing lists. This mailing list address could be contained on one or more other ietf mailling lists thus I get mail indirectly and infrequently from some other entity mailing list that I do not know that I am on. 4. BCC addressing causes massive problems. Either the message always comes up, I lose the concept of BCC because the address is included, or a separate signature operation must be included for every BCC recipeient. (Does the BCC signature still have the list of all non-BCC recipients?). The process of generating addition signature operations is not acceptable in my estimation, and would likely generate lots of interesting problems with signed receipts. 5. What are the correct processing rules to deal with the following situations: - Nested signatures: Does this element in an outer signature remove the requirement for it to be checked on an inner signature? Does it add or change the behavior in some way? - Parallel signature: What does this mean for two different side-by-side signatures, possible with different recipient lists? If I am on either list I don't need to display this warning? - Nested Messages: What happens if I bodily encapsulate an RFC822 message and forward it to you. Do you check for the encapsulating but not the embedded message? Do you check the embedded message for the from address of the encapsulating message? I think that this is an interesting accademic problem, until I see a real world need for a solution I think it should be ignored. jim
- secure sign & encrypt Terje Braaten
- Re: secure sign & encrypt Hal Finney
- RE: secure sign & encrypt Terje Braaten
- Re: secure sign & encrypt vedaal
- RE: secure sign & encrypt Terje Braaten
- Re: secure sign & encrypt Derek Atkins
- Re: secure sign & encrypt vedaal
- Re: secure sign & encrypt Derek Atkins
- Re: secure sign & encrypt vedaal
- Re: secure sign & encrypt Jon Callas
- RE: secure sign & encrypt Terje Braaten
- RE: secure sign & encrypt Terje Braaten
- Re: secure sign & encrypt vedaal
- Re: secure sign & encrypt Derek Atkins
- RE: secure sign & encrypt Terje Braaten
- RE: secure sign & encrypt Terje Braaten
- RE: secure sign & encrypt Hal Finney
- RE: secure sign & encrypt Terje Braaten
- Re: secure sign & encrypt Jon Callas
- RE: secure sign & encrypt Terje Braaten
- Re: secure sign & encrypt Derek Atkins
- Re: secure sign & encrypt Peter Gutmann
- RE: secure sign & encrypt Terje Braaten
- Re: secure sign & encrypt Matthew Byng-Maddick
- RE: secure sign & encrypt Dominikus Scherkl
- RE: secure sign & encrypt Terje Braaten
- Re: secure sign & encrypt Derek Atkins
- Re: secure sign & encrypt Derek Atkins
- Re: secure sign & encrypt Derek Atkins
- RE: secure sign & encrypt Terje Braaten
- RE: secure sign & encrypt Terje Braaten
- Re: secure sign & encrypt David P. Kemp
- Re: secure sign & encrypt Derek Atkins
- Re: secure sign & encrypt Matthew Byng-Maddick
- RE: secure sign & encrypt Terje Braaten
- RE: secure sign & encrypt Dominikus Scherkl
- RE: secure sign & encrypt Dominikus Scherkl
- Re: secure sign & encrypt disastry
- RE: secure sign & encrypt Terje Braaten
- Re: secure sign & encrypt disastry
- Re: secure sign & encrypt Derek Atkins
- RE: secure sign & encrypt Terje Braaten
- Re: secure sign & encrypt Derek Atkins
- RE: secure sign & encrypt Terje Braaten
- RE: secure sign & encrypt Terje Braaten
- Re: secure sign & encrypt Derek Atkins
- Re: secure sign & encrypt Derek Atkins
- RE: secure sign & encrypt Terje Braaten
- RE: secure sign & encrypt Terje Braaten
- Re: secure sign & encrypt Peter Gutmann
- Re: secure sign & encrypt Michael Young
- Re: secure sign & encrypt Paul Hoffman / IMC
- RE: secure sign & encrypt Terje Braaten
- Re: secure sign & encrypt Brian M. Carlson
- Re: secure sign & encrypt Jon Callas
- Re: secure sign & encrypt Adrian 'Dagurashibanipal' von Bidder
- RE: secure sign & encrypt john.dlugosz
- RE: secure sign & encrypt Terje Braaten