Subject: Re: processing of "speculative" key ids: MAY -> SHOULD�MUST

From: [email-masked]
Date: Thu, 20 Jan 2000 10:17:01 -0500 (EST)

[email-masked] wrote on Thu, 20 Jan 2000 00:56:26 +0900:

 >  An implementation MAY accept or use a Key ID of zero as a "wild card"
 >  or "speculative" Key ID. In this case, the receiving implementation
 >  would try all available private keys, checking for a valid decrypted
 >  session key. This format helps reduce traffic analysis of messages.
 >
 >i think the use of MAY here seriously undermines the usefulness of the
 >"speculative" key id.  i think it would be better if implementations
 >SHOULD (or even better MUST) process "speculative" key ids.

I vote for staying with the current wording. The suggested change
might be only a small overhead for a program like PGP or GnuPG,
but the change (especially with a "MUST") creates a major
performance penalty for "wrapper" programs in mail-servers.

One of my programs is a mail-server with automatic
encryption/decryption. To avoid having to "re-invent the wheel",
I use PGP resp. GnuPG (depending on the customer's wishes) for
the actual en-/decryption.

To be able to do automatic decryption of incoming mails, the
mail-server "knows" all secret key ids and their PGP passwords
(stored in secure memory, of course). It scans the incoming mail
for the recipient ids and then calls PGP/GnuPG with the
appropriate password for the actual decryption.

If zero key ids become obligatory, it has to test all keys on the
secret key ring (potentially containing a _lot_ of keys for a
major city administration). While this testing might be an
acceptable overhead for PGP/GnuPG, it is a much bigger overhead
for the "wrapper application" which can only test 1 key per
PGP/GnuPG call.

Speculative key ids are only helpful when used together with
nym-servers (as otherwise the mail headers would permit the
traffic analysis that the sender wants to avoid). Using
nym-servers in a proper way, however, can avoid traffic analysis
even with "normal key ids". So the "speculative key id" feature
does not really gain anything new.

Therefore, let us not create performance penalties to gain "just
another way of doing something we could have done already all
along".

- Wolfgang Redtenbacher

---------------------------------------------------------------------
Redtenbacher Software                Tel.:   +49 7159 17046
Roemerstr. 11/1                      Fax:    +49 7159 17047
D-71272 Renningen                    e-mail: [email-masked]
---------------------------------------------------------------------

---

From: [email-masked]
Date: Fri, 21 Jan 2000 01:16:05 +0900

wolfgang> I vote for staying with the current wording. The suggested change
wolfgang> might be only a small overhead for a program like PGP or GnuPG,
wolfgang> but the change (especially with a "MUST") creates a major
wolfgang> performance penalty for "wrapper" programs in mail-servers.

hmm, for the case of "MUST", i agree w/ you.  you are right.  i see
that "MUST" may cause performance problems for this type of case.

wolfgang> If zero key ids become obligatory, it has to test all keys on the
wolfgang> secret key ring (potentially containing a _lot_ of keys for a
wolfgang> major city administration). While this testing might be an
wolfgang> acceptable overhead for PGP/GnuPG, it is a much bigger overhead
wolfgang> for the "wrapper application" which can only test 1 key per
wolfgang> PGP/GnuPG call.

then perhaps "SHOULD" is in order, and not "MUST".  in the current
state, speculative keyids are not very useful/practical for endusers
because of the lack of support in pgp (unless all parties are using
gnupg).

another way to deal w/ this would be for gnupg (and other
implementations) to be able to make certain key ids speculative
(i.e. key ids for gnupg users) and to leave others alone (i.e. key ids
for pgp users).  at least interoperability would be obtained this way
-- but it doesn't change the sad state that pgp users are easier to
"spy on" so-to-speak.  but it seems silly for gnupg to implement
selective keeping or throwing of key ids for a (imo) deficiency in pgp
(i have yet to verify this on all versions so if someone knows
otherwise, please let me know).

is it possible to recommend (or require) the inclusion of support for
processing of speculative key ids in the case of implementations for
enduser software such as pgp and gnupg (what would be an appropriate
term to distinguish this class of software from the type you have
implemented?)?

i think there should at least be some mention in the rfc of potential
interoperability problems in enduser-to-enduser situations if
speculative keyids are not supported on both ends.

wolfgang> Speculative key ids are only helpful when used together with
wolfgang> nym-servers (as otherwise the mail headers would permit the
wolfgang> traffic analysis that the sender wants to avoid). Using
wolfgang> nym-servers in a proper way, however, can avoid traffic analysis
wolfgang> even with "normal key ids". So the "speculative key id" feature
wolfgang> does not really gain anything new.

i don't agree that they are only useful in this case.  further there
are problems w/ nym servers as is -- nym servers as they currently
exist are not adequate for certain purposes.

let's not get into a discussion of nym servers here though.  (i hope
you didn't mean "anonymous remailer" when you mentioned "nym-server",
because to me those two are not the same.)

speculative key ids can be useful in the context of a mailing list
that has its own keypair plus the public keys of all recipients.  it
can prevent people from finding out who all of the subscribers are via
the interception of a single message -- yes, it would be possible to
generate a message per person, but as you have mentioned, performance
will suffer.  this kind of setup combined w/ anonymous remailers
(preferably something like type-ii or better) would be quite useful.

also, openpgp doesn't have to be used only for mail.

i think the burden of proof of uniqueness of usefulness is not on me
;-)

thanks for your comments!

---

From: Werner Koch <[email-masked]>
Date: Fri, 21 Jan 2000 10:59:10 +0100

> I vote for staying with the current wording. The suggested change

me too.

> (stored in secure memory, of course). It scans the incoming mail

How do you get the passphrases in the secure memory?  I see no way to
do this without manual operator action - and this prevents automatic
restart of machines after power failure etc.  

-- 
Werner Koch at guug.de           www.gnupg.org           keyid 621CC013
  
     Boycott Amazon!  -  http://www.gnu.org/philosophy/amazon.html

---

From: Kent Crispin <[email-masked]>
Date: Sat, 22 Jan 2000 05:44:17 -0800

On Fri, Jan 21, 2000 at 01:16:05AM +0900, [email-masked] wrote:
[...]
> will suffer.

Do you have some quantification of the performance hit? I'm not sure it
is such a big deal to send an individual message to each list member --
note that some popular list managment packages will put the address you
are subscribed from at the bottom of a message, which means, I believe,
that they are sending a different message to each list member. 

-- 
Kent Crispin                               "Do good, and you'll be
[email-masked]                           lonesome." -- Mark Twain