Subject: mail client implementations problem? bcc and encrypting to multiple recipients

From: [email-masked]
Date: Tue, 22 Aug 2000 13:33:57 +0900

through some testing of existing mail clients, Terje Elde
<[email-masked]>, other members of the [email-masked]
mailing list, and i have noticed that bcc-ed recipient key id
information can be leaked to non-bcc-ed recipients.

it's probably obvious what the problem is, but for the sake of clarity:

  for the purposes of sending a message to a group of recipients, some 
  mail clients create a single encrypted message body which is sent
  out to all recipients, including bcc-ed recipients.

  since this means that each recipient receives a message containing a 
  public key encrypted session key packet for each recipient, each recipient
  is able to tell who all of the recipients were (assuming no use of
  speculative key ids) -- or at least all key ids.

  even if speculative key ids were to be used, a recipient would likely
  be able to tell that there were other recipients than those implied
  in the headers of a message.  also, afaik, nai pgp doesn't support
  speculative key ids, so in terms of interroperability it's not a great
  option at this point.

we've found 5 mail clients that suffer this problem so far, so it
seems like it may be a common implementation "choice".

[ we have also received reports that at least a couple of mail clients
actually encrypt to each recipient separately and thus do not suffer
this problem. ]

---

From: "L. Sassaman" <[email-masked]>
Date: Tue, 22 Aug 2000 00:43:16 -0700 (PDT)

Why don't we make the "wild card" or "speculative" key id support a
SHOULD? I at least want to see all the client's being able to properly
decrypt messages that use this feature.

> actually encrypt to each recipient separately and thus do not suffer

__

L. Sassaman

Security Architect             |  "We all want many things,      
Technology Consultant          |   but some of those are bottomly
                               |   destructive of all desires."
http://sion.quickie.net        |               --Vernor Vinge

---

From: Erron Criddle <[email-masked]>
Date: Tue, 22 Aug 2000 16:43:43 +0800

At 01:33 PM 22/08/2000 +0900, [email-masked] wrote:

<snip>

>   speculative key ids, so in terms of interroperability it's not a great

As far as I'm concerned the Key ID is a complete waste of time unless a 
lookup is being made on a server that is automatically decrypting each 
message. This is OK here because you can configure the database to store 
the Key ID and that makes lookups easier (if there are no duplicate Key 
ID's). From my understanding of the Public and Private Keyring structures, 
you can only have a Key ID for the highest level key (self sig.) and cannot 
store the Key ID's for the subkeys.

For our client software, we are not doing lookups via the Key ID (as it 
isn't stored in the public/private keyrings), however the server version 
will support lookups via Key ID's.

We have found it better just to do lookups via the User ID - at least you 
can store that within the private /public keyring structures.

If anyone can tell me otherwise regarding the storage of Signing and 
Encryption Key ID's within the private/public keyrings, it would be great.

Cheers.

Regards

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009
Australia

Fax: 08 9386 9473
Tel: 08 9386 9534

http://www.comasp.com
[email-masked]

---

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 22 Aug 2000 13:03:23 -0500

In <[email-masked]>, on 08/22/00 

>ID's). From my understanding of the Public and Private Keyring
>structures,  you can only have a Key ID for the highest level key (self
>sig.) and cannot  store the Key ID's for the subkeys.

>Encryption Key ID's within the private/public keyrings, it would be

    IMHO using the userID is *not* the way to go. While userID lookups can be used the first time you are encrypting a message to a new e-mail address precautions need to be made. A dialog between the user should be established to verify that this is the actual key that should be used (anyone can create a key with any userID, multiple keys with the same userID may be present, ...ect). Key lookups need to be based on the 64bit keyID, it's the only way to insure that you are getting the correct key (for signature verifications it is the only way to find the key). Once a user has selected a key to use for a new e-mail address the application should store the 64bit keyID & the e-mail address in a table. For subsequent encryptions to that address the application should lookup the e-mail address in the table and then extract the PGP public key from the keyring using the corresponding keyID.

    Now granted the keyID is not stored in the key itself, this is not really that big of an issue. I can currently process a 1Gb keyring, calculating all the keyID's, in a couple of mins. For an average size keyring the processing time is less that a second. If you find your application needs to work with large keyrings maintaining a simple external index on the keyring by keyID will greatly improve performance.

-- 
---------------------------------------------------------------
William H. Geiger III      http://www.openpgp.net  
Geiger Consulting    

Data Security & Cryptology Consulting
Programming, Networking, Analysis
 
PGP for OS/2:               http://www.openpgp.net/pgp.html
E-Secure:                   http://www.openpgp.net/esecure.html
---------------------------------------------------------------

---

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 22 Aug 2000 13:20:19 -0500

In <[email-masked]>, on 08/22/00 

>decrypt messages that use this feature.

I don't have a problem with the speculative keyID support but it does not address the underlying problem: Implementors not understanding basic concepts of e-mail encryption. I came across the issue of KeyID leakage back in '96 and documented it at:

http://www.openpgp.net/pgpemail_5.html

Automated PGP processing can be a powerfull tool but there are complex issues involved and an application developer needs to spend the time at the design stage to do it properly.

---

From: "L. Sassaman" <[email-masked]>
Date: Tue, 22 Aug 2000 12:44:57 -0700 (PDT)

Your point is valid, but in some cases requires that the authors of the
email programs do The Right Thing as well as the authors of the OpenPGP
program/plugin. (For instance, I don't believe that the PGP Outlook plugin
could be written in such a way that multiple single recipient messages
were sent out. That's an Outlook limitation.)

The speculative key-id feature would be something over which the OpenPGP
implementors could have full control (in just about all cases).

- --Len.

__

L. Sassaman

---

From: [email-masked]
Date: Wed, 23 Aug 2000 12:16:40 +0900

From: "William H. Geiger III" <[email-masked]>
Subject: Re: mail client implementations problem?  bcc and encrypting to multiple recipients
Date: Tue, 22 Aug 2000 13:20:19 -0500
Message-ID: <[email-masked]>

> I don't have a problem with the speculative keyID support 

same here, though i think when this issue was brought up once before
there were some valid concerns brought up.  

imo, one context in which i think speculative key ids support "SHOULD"
exist, is one which is user-driven -- if a user receives a message
that contains public key encrypted session key packets that contain
speculative key ids, the user should be able to have an openpgp
implementation attempt to decrypt the pk esk packets w/ the user's
secret key(s).  the user shouldn't have to perform surgery on the pk
esk's (inserting key ids) and attempting to decrypt repeatedly.

in other contexts (e.g. processing by a script on a mail gateway), i
was given to understand that there were valid reasons (e.g. computing
resource limitations) not to want to support the feature.

the discussion i am referring to took place in january of this year.
it starts at:

  http://www.imc.org/ietf-openpgp/mail-archive/msg02691.html

> but it does not address the underlying problem: Implementors not
> understanding basic concepts of e-mail encryption.

i agree w/ this as well.  

i would like to have a document i could point mail client developers
at that had some kind of "official" status -- like an ID, RFC, or
standard.  i don't think RFC 2440 (or bis) is the place for it (it's
too big already).

> I came across the issue of KeyID leakage back in '96 and documented
> it at:
>

nice!  perhaps this can be converted into an ID or portions of it
adapted to become an ID?

---

From: Erron Criddle <[email-masked]>
Date: Wed, 23 Aug 2000 11:47:52 +0800

At 01:03 PM 22/08/2000 -0500, "William H. Geiger III" <[email-masked]> 
wrote:

<snip>

>     IMHO using the userID is *not* the way to go. While userID lookups 
> can be used the first time you are encrypting a message to a new e-mail 
> address precautions need to be made. A dialog between the user should be 
> established to verify that this is the actual key that should be used 
> (anyone can create a key with any userID, multiple keys with the same 
> userID may be present, ...ect).

Agreed that User ID's provide the encryptor (user) options as to which key 
to use for encryption.

>  Key lookups need to be based on the 64bit keyID, it's the only way to 
> insure that you are getting the correct key (for signature verifications 
> it is the only way to find the key).

A 8 octet lookup of the Key ID for sigs. is definitely the only way to go 
(you can obtain the Key ID from the self sig. of the signature key). A 
lookup via a Key ID with a PKESK is only good if you are not using 
speculative Key ID's.

>  Once a user has selected a key to use for a new e-mail address the 
> application should store the 64bit keyID & the e-mail address in a table.

Agreed.

>  For subsequent encryptions to that address the application should lookup 
> the e-mail address in the table and then extract the PGP public key from 
> the keyring using the corresponding keyID.

That's where my dilemma starts - how do you store the Key ID of encryption 
subkeys on a keyring? I think this should be made possible somehow.

>Now granted the keyID is not stored in the key itself, this is not really 
>that big of an issue. I can currently process a 1Gb keyring, calculating 
>all the keyID's, in a couple of mins. For an average size keyring the 
>processing time is less that a second. If you find your application needs 
>to work with large keyrings maintaining a simple external index on the 
>keyring by keyID will greatly improve performance.

Yes, that's what we are doing - creating an index that links key ID's to 
email addresses - it certainly speeds things up.

Regards

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009
Australia

Fax: 08 9386 9473
Tel: 08 9386 9534

http://www.comasp.com
[email-masked]

---

From: Terje Elde <[email-masked]>
Date: Wed, 23 Aug 2000 10:34:15 +0200

> esk's (inserting key ids) and attempting to decrypt repeatedly.

The user *will* have to decrypt multiple secret keys if such exist. Perhaps a
recommendation that non-encrypted keys be tried first is an idea?

Actually, this might be of some concern. You could effectively send a email
using speculative KeyID, which would make the user decrypt all his key in
turn, thus providing a attacker with access to keyboard with passphrases to
*all* his KeyID's, including keys the user might have made to be extra secure,
and not for normal use (root keys etc).

Recommending some way of managing this, by specifying the order in which keys
are tried, or even marking keys as not to be used with spec keyid's is a
possible fix to this problem.

> resource limitations) not to want to support the feature.

I'm one who has raised such concerns, although not in the discussion you
refer to. I don't see how the fact that use of spec keyid's isn't appropriate
in every situation should put breaks on making it a should. Sure, it'll force
admins of major mailing lists to have to think first, act later, but isn't
that always the case when you have to admin a mailing list which is using
encrypted emails to such a number of user that that's a concern?

> > understanding basic concepts of e-mail encryption.

The question is, how would you like to solve the problem?

I don't see any quick fix for this. You can't force people to not write crypto
applications until they've been certifies in their field. You can't force
people to want to educate themselves.

I think the only thing one can do is offer help whenever possible, and view
everything with a critical eye, as well as publishing information about
potential problems, to help lesser skilled users from getting bitten.

Just my $0.02

Terje

---

From: [email-masked]
Date: Wed, 23 Aug 2000 17:48:24 +0900

From: Terje Elde <[email-masked]>
Subject: Re: mail client implementations problem?  bcc and encrypting to multiple recipients
Date: Wed, 23 Aug 2000 10:34:15 +0200
Message-ID: <[email-masked]>

...

> I don't see any quick fix for this. 

i don't see a quick fix either.

> You can't force people to not write crypto applications until
> they've been certifies in their field. You can't force people to
> want to educate themselves.

i agree.

> I think the only thing one can do is offer help whenever possible,
> and view everything with a critical eye, as well as publishing
> information about potential problems, to help lesser skilled users
> from getting bitten.

i would hesitate to claim uniqueness ("the only thing"), but w/o too
much further thought, i agree w/ the rest.

imo, part of "publishing information about potential problems" is to
address such issues in relevant ID/RFC/STDs.  so, for starters, i
think we should either create another draft or try to incoporate the
substance of this into an existing document.

---

From: Terje Elde <[email-masked]>
Date: Wed, 23 Aug 2000 11:22:31 +0200

> much further thought, i agree w/ the rest.

Obviously you're right. I should have went more along the lines of "the only
thing I can come up with".

> substance of this into an existing document.

A big part in the reason why I registered openpgp.org is that I intend to try
to make it a resource for developers and users alike. One of the things I want
to focus on in addition to such basic things as pointing the visitors at other
resources is to help by providing information on best ways to solve problems,
and pointing out what the problems might be in the first place.

This will range from helping users by suggesting secure ways of avoiding loss
of keyrings (pub and priv) to helping programmers by pointing out issues such
as the bcc problem, and ways to fix it.

I hope noone at the IETF-OpenPGP working group feels offended by me
registering the domain.

Terje

---

From: "L. Sassaman" <[email-masked]>
Date: Wed, 23 Aug 2000 12:29:01 -0700 (PDT)

> recommendation that non-encrypted keys be tried first is an idea?

I actually would like to see the default key tried first, since that makes
more sense in my mind... but now we're in the realm of specific
implementation methods.
 
> and not for normal use (root keys etc).

You could automatically try the default key, and then give the user the
list of keys remaining to try, and he can pick which ones.

And you can always have a "disable speculative key" option.

- --Len.

__

L. Sassaman

---

From: Terje Elde <[email-masked]>
Date: Thu, 24 Aug 2000 11:31:24 +0200

> more sense in my mind... but now we're in the realm of specific

True.

Giving a few notes for authors to reflect over isn't a bad thing though, is
it?

Trying to use the default key first isn't a bad idea. It's the one that's got
the better chance of being a hit. Un-encrypted keys take no time to check
however, and you can spare the user from having to enter the passphrase.

I also thing that the places you'll be using speculative KeyID's are also the
places where the chances of encrypting to a key with no passphrase are
highest, as many will simply want to get the mail securely from sniffers, and
not have to decrypt ever single message.

Just a thought...

> And you can always have a "disable speculative key" option.

Both great ideas. :)

Terje