MessageID wording paranoia

[Thomas Roessler <roessler@xxxxxxx>]

The current draft states the following on the generation
of Message-IDs:

>    - "MessageID", a 32-character string of printable
>    characters.  The string must be the same for all parts of
>    a multi-part message that uses the "PART X" Armor Header.
>    MessageID strings should be unique enough that the
>    recipient of the mail can associate all the parts of a
>    message with each other.  A good checksum or cryptographic
>    hash function is sufficent.

>    The MessageID should not appear unless it is in a
>    multi-part message. If it appears at all, it MUST be
>    computed from the message in a deterministic fashion,
>    rather than contain a purely random value.  This is to
>    allow anyone to determine that the MessageID cannot serve
>    as a covert means of leaking cryptographic key
>    information.

I consider this to be a dangerous approach, since it may
let _plaintext_ information leak to the public: Consider
some (broken) implementation using an SHA1 hash of the
message - to "prove" that some suspected plaintext is
actually the one you have, you only need to have a look at
the Message ID.

Even worse, an implementation which uses some part of the
plain text, encrypted with a symmetric algorithm, could
use this stuff to leak known plaintext while still being
compliant to the standard, while an implementation using
random values would _not_ comply.

As a solution, I'd suggest to mandate the use of a certain
hash (sha1?) of the armored text, i.e., the _encrypted_
message. (Most probably it's meant that way, but let's
make the text unambiguous.)

tlr
-- 
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
     2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1