Subject: Interop grill-off

From: Jon Callas <[email-masked]>
Date: Mon, 19 Sep 2005 14:05:19 -0700

I think it would be good for us to have some sort of interoperability  
test and event. Putting on my PGP Corporation hat, I'm happy to  
sponsor it. However, it doesn't *have* to be a physical event. Does  
anyone else think it would be a good idea? Does anyone want to help  
put it on, come up with test cases, that sort of thing?

     Jon

---

From: [email-masked] (Daniel A. Nagy)
Date: Tue, 20 Sep 2005 08:53:46 +0200

> put it on, come up with test cases, that sort of thing?

How about simply posting test cases with descriptions here, and testing on
various OpenPGP implementations, also posting the results to the mailing
list. Then you (or someone else) could post a summary here and/or to some
webpage.

I'm also wondering what are you more after: unusual data conforming to
RFC2400 (or RFC2440bis) or slight (but logical) deviations, extensions?

I guess, many of us have already identified interoperability problems. Would
it make sense to collect them first, before going into testing questionable
cases?

Here's my list of problematic cases that I have encountered:
(offenders: HushMail, PKS, SKS, GnuPG)

1. HushMail's idea of signed and encrypted messages is encrypting a
clearsigned message as canonical text, including the message boundary and
the armored signature. Other applications usually don't verify the
signature, though, of course, it's easy to do "by hand" (by running a second
pass). In the other direction, it's worse: HushMail decrypts the properly
signed and encrypted message, but keeps silent about the one-pass signature
within the encrypted payload; the message is identified as encrypted but not
signed.

2. Some keyservers omit canonization before hashing the key packet. If the
key packet is shorter than 256 bytes (typically the case for 1024-bit RSA
keys) and uses the shortest possible packet header with a one-byte length,
the fingerprint and the key IDs are mis-calculated. PKS is guilty of this.

3. Some keyservers do not return matching keys, if searched by the long
(16 byte) key ID of a subkey. SKS is guilty of this.

4. Some implementations give up before trying all possible ways of
decrypting a message. For example, GnuPG gives up if it encounters a
passphrase-derived symmetric key specifier and the entered passphrase is
wrong, even if it is followed by an asymmetrically encrypted symmetric key
for which it does have access to the corresponding private decryption key.

-- 
Daniel

---

From: Werner Koch <[email-masked]>
Date: Tue, 20 Sep 2005 10:06:36 +0200

> for which it does have access to the corresponding private decryption key.

There are actually two problems: 

There is no way to cancel the input of a passphrase when using the
CLI, so that gpg can continue with other keys.  When using the
gpg-agent, this is possible but a bug inhibited this - I just fixed
that one.

The other problem is that we can't reliable decide whether the
passphrase is correct.  The only way to do this is by looking at the
algorithm byte to check whether this gives a valid algorithm.  This is
far form being reliable. Due to gpg's streaming based design with only
a very limited look-ahead we can't do a test decryption and roll back
if it does not work out.

A way to check early that the decryption worked would be needed to
solve the problem - I am not sure whether this is really needed given
the security implications of such a check.

Salam-Shalom,

   Werner

---

From: [email-masked] (Daniel A. Nagy)
Date: Tue, 20 Sep 2005 10:39:56 +0200

> gpg-agent, this is possible but a bug inhibited this - I just fixed

I never thought of this as a problem, but maybe you're right.
 
> a very limited look-ahead we can't do a test decryption and roll back

I would suggest a completely different approach: try extracting a key from
each ESK (be it password-derived, password-encrypted or
asymmetcially encrypted), and use the one which inspires most confidence:

An asymmetrically decrypted key has an approx. 1 in 17 million chance of
being incorrect, symmetrically encrypted keys have a roughly 1 in 20 chance
of being incorrect, while there's absolutely no indication wheter a
passphrase-derived secret key is correct or not.

Thus, deriving a decryption key from a passphrase and then merrily
proceeding to the decryption of the encrypted content is incorrect. A
correct implementation should try to extract a key from each ESK, and in
case of success (asymmetric decryption with leading 0 and correct checksum,
symmetric encryption with valid algorithm id or any passphrase-derived key)
replacing the tentative decryption key, if the new key inspires more
confidence than the previous tentative key. Eventually, the last tentative
key should be used for decryption.
 
> the security implications of such a check.

Yes, that's somewhat hazardous, indeed (although only in non-interactive
applications). But it's not necessary, as explained above.

-- 
Daniel

---

From: [email-masked] (Daniel A. Nagy)
Date: Tue, 20 Sep 2005 10:47:57 +0200

On Tue, Sep 20, 2005 at 10:06:36AM +0200, Werner Koch wrote:

> Due to gpg's streaming based design ...

By the way, what does gpg do given the --try-all-secrets option, if there's
more than one ESK? Does it try all of them with all the private keys, or
just the first one?

-- 
Daniel

---

From: Werner Koch <[email-masked]>
Date: Tue, 20 Sep 2005 11:07:09 +0200

> asymmetcially encrypted), and use the one which inspires most confidence:

Makes sense.  We have not seen many pubkey/symkey encrypted messages
in the wild thus the way we handle them is straightforward.  Need to
look at it closer.

Thanks,

  Werner

---

From: Werner Koch <[email-masked]>
Date: Tue, 20 Sep 2005 11:39:11 +0200

> more than one ESK? Does it try all of them with all the private keys, or

--try-all-secrets applies only to PKESK to assume wildcard key IDs.

Shalom-Salam,

   Werner

---

From: David Shaw <[email-masked]>
Date: Tue, 20 Sep 2005 11:17:05 -0400

> the fingerprint and the key IDs are mis-calculated. PKS is guilty of this.

This is a good one.  I've seen this mistake made more than once, and
not just in PKS.  Incidentally, that bug in PKS was fixed quite a
while ago.  PKS had many problems, including miscalculating v4 RSA
fingerprints, mangling keys with more than one subkey, discarding
attribute ID packets, etc.  Most of the worst have been fixed, but the
point may be moot as so far as I know, PKS is not being developed any
longer.

> (16 byte) key ID of a subkey. SKS is guilty of this.

Isn't this a just SKS feature request?  Nothing in the draft says
anything about how keyservers work, or even that a UI must allow
particular ways to search.

David

---

From: [email-masked] (Daniel A. Nagy)
Date: Tue, 20 Sep 2005 17:50:02 +0200

> --try-all-secrets applies only to PKESK to assume wildcard key IDs.

Right, but what if there are more of these (multiple recipients)?

-- 
Daniel

---

From: [email-masked] (Daniel A. Nagy)
Date: Tue, 20 Sep 2005 18:04:57 +0200

> particular ways to search.

No, it isn't. This becomes a major interoperability issue, when you use
signature subkeys. It's not quite clear from RFC2440 wether the 8-byte
signatory field sould point to the main key or the subkey, but in several
implementations it points to the subkey, which actually made the signature
(and this is the right behavior, IMHO).

In this case, databases of keys, be it local keyrings or remote keyservers
MUST be indexed by subkey IDs as well, otherwise such signatures cannot be
verified. For example, this SKS deficienci breaks interoperability (namely
yautotmatic key retrieval) with GnuPG (and very possibly PGP), if signature
subkeys are used.

Signature subkeys have many uses, and although they are less popular than
encryption subkeys (because of the default settings of pgp and gpg) their
use is an important security measure allowing for changing the regularly
used signing key without losing all certificatitons on the main key. They
are also useful if the same user wishes to make signatures from different
computers without risking too much.

-- 
Daniel

---

From: Werner Koch <[email-masked]>
Date: Tue, 20 Sep 2005 18:14:32 +0200

> Right, but what if there are more of these (multiple recipients)?

Yes, it tries all of them with all available secret keys.

Salam-Shalom,

   Werner

---

From: David Shaw <[email-masked]>
Date: Tue, 20 Sep 2005 13:12:47 -0400

> (and this is the right behavior, IMHO).

I don't know of *any* implementations that set the issuer subpacket to
anything other than the key that made the signature, as specified in
the RFC.  Doing otherwise would be an absurd thing to do - the signing
equivalent of putting the main key ID into a PKESK packet when
encrypting to a subkey.  If you can point to a single implementation
that does this wrong, I'll immediately concede the point.

David

---

From: [email-masked] (Daniel A. Nagy)
Date: Wed, 21 Sep 2005 01:53:39 +0200

On Tue, Sep 20, 2005 at 01:12:47PM -0400, David Shaw wrote:

> the RFC. 

You mean the actual subkey, right? Where is it specified in the RFC?
The formulation "the key that made the signature" is a bit ambiguous, IMHO,
but, of course, the sensible thing to do is obvious.

> Doing otherwise would be an absurd thing to do - the signing

Of course, I can't. This is why I am saying that SKS has an important
interoperability problem. It EXPECTS the wrong behavior, while nobody
actually does it.

-- 
Daniel

---

From: David Shaw <[email-masked]>
Date: Tue, 20 Sep 2005 21:10:53 -0400

> interoperability problem. It EXPECTS the wrong behavior, while nobody

While it is true that SKS doesn't do long keyid searches for subkeys,
and I agree this is suboptimal behavior, understand that this is not
connected to what clients put in the issuer key ID subpacket.  There
has never been a client that put anything other than the signing key
ID in the subpacket, and the SKS behavior is not based on some
misreading of that point in the draft.

Even if SKS started supporting long subkey ID searches tomorrow, it
would not resolve this problem, as GnuPG doesn't provide long key IDs
when speaking to any HKP-ish keyserver because there are still old PKS
servers out that that just won't die.  I believe PGP does the same
thing.  If you want long key ID searches, you need to use LDAP.

Note that even those PKS servers that don't blow up completely on long
key ID searches don't really do them either: they just pretend to, and
ignore the upper 32 bits - try searching for 0x99242560 and
0x1111111199242560.  PKS doesn't do subkey searches at all.

I'm all for getting these problems fixed, but we stand a better chance
of doing by working the actual problem.  By all means, add some
clarifying text to the text for the issuer key ID subpacket, but
understand that won't change the keyserver situation.  It's just two
different problems.

David

---

From: [email-masked] (Daniel A. Nagy)
Date: Wed, 21 Sep 2005 11:44:26 +0200

> understand that won't change the keyserver situation.  It's just two

Oh, there seems to be a misunderstanding between us, for which I should
probably apologize. I never for a moment suggested that SKS's bad behavior
was the result of the wording in RFC2440, though reading back, it might have
indeed come across like I did.

I simply listed interoperability problems that I have encountered that in my
opinion resulted from not anticipating less obvious, yet perfectly
RFC-compliant behavior. In this particular case, I have noted a minor
possible ambiguity in the standard text, which, I repeat, should be obvious
for anyone giving it a little thought. As an implementer myself, I have
resorted to the same workarounds: canonizing public key packets before
uploading to keyserver and using short key IDs.

Also, I totally agree with you that clarification in the standard is not the
way to fix this problem, but listing it as a known interoperability issue in
the mailing list archive or even on some webpage dedicated to
interoperability between OpenPGP applications (is that what Jon aims to do?)
might help in two ways: culprits may eventually fix their bugs, and
meanwhile others might avoid running into them.

For example, if such a list existed when I coded the relevant parts of
ePointPGP, it would have saved me a lot of time. I think, Jon's idea of an
interop grill-off is an excellent opportunity for assembling such a list of
known interoperability issues, before venturing into testing unknown,
suspected ones.

That said, SKS is by far the most standards-compliant HKP-compatible
keyserver that I have seen. Others do horrible things to keys and search
results. Since keyservers are (correctly) considered outside of security
perimeters and should be treated as untrustworthy in any case, they tend to
be the least carefully written and maintained applications in the OpenPGP
world. That's just a fact of life, I guess, that we need to cope with.

And again, apologies in case I have unintentionally offended someone.

-- 
Daniel

---

From: Ian G <[email-masked]>
Date: Wed, 21 Sep 2005 12:00:52 +0100

Jon Callas wrote:
> test and event. Putting on my PGP Corporation hat, I'm happy to  sponsor 
> it. However, it doesn't *have* to be a physical event.

Physics is fun, but net chemistry also works.  I've
had some degree of success in testing cross-platform
code using a "webservice" approach.  Basically, build
a server that offers a number of actions over HTTP **.

The basic action is an echo service that forms part of
a read/write cycle to prove serialisation.  It works
roughly this way:

1.  Create a garbage packet.
2.  Serialise it into its network form.
3.  Send it off to the other implementation
     over some sort of server protocol.
4.  The echo server sits there and waits for packets:
     a. read a packet in,
     b. parse it, objectise it,
     c. write it out again in network form,
     d. return it as the response to the request.
5.  The original sender reads back the response,
     recovers it and then compares it internally
     with the original packet it sent.

This means that there needs to be two routines
added to every packet:  create a garbage packet,
and compare two packets for equality.

Once that basic architecture is defined, many
variants are possible....

> Does  anyone else 
> think it would be a good idea? Does anyone want to help  put it on, come 
> up with test cases, that sort of thing?

It's definately a good idea.  The main thing
above would be to define a list of the minimal
packets that should be echoed:

    public key packet with basic feature set
         and only the MUST algorithms
    encrypted message,
    signed message, cleartext and binary
    encrypted + signed binary

Start with the absolute minimum.  (Obviously
encrypted and signed messages will involve
some state ....)

iang

PS:  To add in another buzzword, I'd do it in
REST format, which basically means do it as a
simulated web server, and have the client and
server deal with HTTP POST requests with some
form of application binary data.  This avoids
most of the complications of defining ones own
transport protocol, avoids having to talk to
the firewall people, and for most languages
means you don't have to run a server at all,
just slot it in as a CGI into Apache.