Re: Randomness of Message-ID in IMDN

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@ietf.org
https://www.ietf.org/mailman/listinfo/ietf