At Thu, 15 May 2008 00:25:38 +0800,
Eric Burger wrote:
Thanks for your very, very quick review! On the one open item for
discussion, Message-ID, I would offer (1) it is not a do-or-die
situation but that (2) using a cryptographically secure random number
generator. achieves the same result with better properties. Again, I
will defer back to you: I know the work group will push back strong if
a cryptographically secure random number generator is a resource hog.
Are there memory / CPU efficient cryptographically secure random
number generators?
Yes. For instance, the NIST SP 800-90 PRNG requires order
256-512 bits of internal state and two hash operations for
every hash-sized (160-512 bits) chunk of output. I would
just use OpenSSL's cryptographically secure PRNG myself :)
Should we give guidance to the range of numbers
(i.e., 32-bits, 512-bits, 6 digits, etc.)?
As I understand the situation, the sender the only person who has
to rely on the uniqueness of this header, right?
I would suggest instead of recommending a given number you explain
what the issues are and why this has to be unpredictable. Perhaps
something like this:
Because the Message-ID is used by the sender to correlate IMDNs with
their respective IMs, the Message-ID MUST be selected so that:
(1) There is a minimal chance of any two Message-IDs accidentally
colliding within the time period within which an IMDN might be
received.
(2) It is prohibitive for an attacker who has seen one or more valid
Message-IDs to generate additional valid Message-IDs.
The first requirement is a correctness requirement to ensure correct
matching. The second requirement prevents off-path attackers from
forging IMDNs. In order to meet both of these requirements, it is
RECOMMENDED that Message-IDs be generated using a cryptographically
secure pseudorandom number generator (see [RFC 4086] and contain at
least 64 bits of randomness, thus reducing the chance of a
successful guessing attack to n/2^64, where n is the number of
outstanding valid messages. Another potential approach is to combine
a sequence number (providing uniqueness) with a cryptographic MAC
for unforgeability.
Cheers,
-Ekr
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf