I think the proposed wording is excellent. Unless there is objection (PLEASE take it to the SIMPLE list if one does, or wish to +1 it), I would offer we use this language exactly. On May 15, 2008, at 1:25 AM, Eric Rescorla wrote: > 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf