Subject: Re: [Simple] Re-review of draft-ietf-simple-imdn

From: Eric Burger <[email-masked]>
Date: Wed, 14 May 2008 12:20:21 +0800

Inline

On May 4, 2008, at 5:12 AM, Eric Rescorla wrote:

> I originally reviewed version -06 of this document
> (2008-02-8). Examining the diff, it does not appear to me that any of
> my comments from my previous review. Looking back in my mail folder, I
> don't see any reasponses from the authors telling me my review was
> wrong, so I'm retransmitting it here.
>
> -Ekr
>
> $Id: draft-ietf-simple-imdn-06-rev.txt,v 1.1 2008/02/08 18:17:54 ekr  
> Exp $
>
> This document describes a mechanism for IM senders to request status
> notifications for their IMs. The sender attaches a header specifying
> the status conditions he wants to be notified of and intermediaries
> and the receiving UA notify the sender (or someone else of his choice)
> subject to policy constraints.
>
> One thing I'm not clear on is how the recipient determines where to
> send the IMDN. Are they supposed to read the "From" field? One thing
> that I don't get is how the IMDN-Route header interacts here.
> It looks to me like this gets stuffed in the "To" in the IMDN.

You are right - we go on and on about IMDN-Record-Route, but we never  
explicitly say what to do if there is no IMDN-Record-Route.  How about  
the following text, inserted after the IMDN-Record-Route handling  
paragraph:

    If there is no IMDN-Record-Route header field, the IM Recipient
    MUST send the IMDN to the URI in the From header field.

> What happens if someone puts an IMDN-Record-Route that points
> to an IMDN-ignorant UA?

We need to make it clear that an intermediary can only intermediate on  
its own behalf.

How about the following text change in the Intermediary Behaviour  
section:
OLD
An intermediary MAY choose to remain on the path of IMDNs for a  
specific IM. It can do so by adding a CPIM IMDN-Record-Route header  
field as the top IMDN-Record-Route header field and populating it with  
its own address.
NEW
An intermediary MAY choose to remain on the path of IMDNs for a  
specific IM. It can do so by adding a CPIM IMDN-Record-Route header  
field as the top IMDN-Record-Route header field. The value of this  
field MUST be the intermediary's own address.

I was mulling over whether this introduces a security issue.  
Specifically, what if a malicious intermediary wants to perform a DDoS  
attack on an unsuspecting UA? The intermediary could spew a bunch of  
messages towards other UAs, asking them to send IMDNs to DDoS target  
by setting the topmost Record-Route to the target machine. The good  
news is this takes a similar amount of resources as that intermediary  
attacking the target directly. The bad news is the IMDN-Record-Route  
mechanism provides a mechanism for the malicious node to hide its  
identity from the target. The same issue arises if the node simply  
puts in the target node as the From field of the IM and requests an  
IMDN. The only trace would be server logs, which could identify the  
malicious node as the source of the bogus IMDN requests.

How about we add the following to the "threats in the IMDN system"  
list in the Security Considerations section:

    A malicious intermediary or node attempts to flood a target
    node with IMDNs by inserting the target's address in the From
    field or IMDN-Record-Route field

And this text towards the end of the section:

    One way to address the potential for a malicious node to use
    the IMDN system to anonomize attacks is to log all IMDN
    requests on the IM Recipient User Agent.  This allows for tracking
    of attacks, if only after they occur.  Note this also puts a  
burden on
    the IM Recipient User Agent host.  Limited User Agents may not
    be able to preserve much of a log.

> Overall, this document seems pretty well written and clearly lays out
> the security issues.
>
> That said, I'm concerned about the bounce/reflection threats discussed
> in S 14 (where the sender asks for notification to a third party
> victim).  I'm particularly concerned about the "note" field, since a
> natural implementation seems to be to include an excerpt from the
> message you're acknowledging.  This draft identifies the threat but
> doesn't specify any mechanism for ameliorating them. I think some
> suggested mechanisms would be appoprirate here, or at least some
> analysis of what the potential mechanisms were and why they would or
> would not work.

The <note> field is stupid IMHO.  I'm taking that to the list.  Thanks  
for "noting" it, and I am embarrassed it is in the draft at all.

> Other comments: I would avoid the term "non-repudiation" if at all
> possible in S 5.3 and later. It's just so overloaded now that it's
> hard to know what it means.
Fixed

> S 6.5.  A little more explanation of why IMDN-Record-Route is useful
> would help.
Done

> S 7.1.1.1.  Why does Message-ID need any randomness at all as opposed
> to uniqueness?  And if it needs randomness, why is 32 enough?

The randomness property makes it more difficult for malicious nodes  
guessing Message-IDs and thus being able to pass IMDNs through  
filtering mechanisms.

IYHO, is 32-bits enough? You're the expert; I'm just guessing!

> S 7.1.3.  Note that you can pack the state into the messageid if
> you're willing to make large message ids and hte stte is small.

Message-ID could be used for tracking in addition to IMDN, so  
combining the two would not be a good thing.

> S 11.1
>
>   An IMDN Payload is an XML document [6] that MUST be well formed and
>   MUST be valid according to schemas, including extension schemas,
>   available to the validater and applicable to the XML document.  The
>   IMDN Payload MUST be based on XML 1.0 and MUST be encoded using
>   UTF-8.
>
> Is this a requirement that the receiver validate the XML?

On the one hand, I suppose it is. On the other hand, that is totally  
unenforceable. Can this one slide under the radar?

> S 12.1.1.  Why can't anonymous senders request notifications?

Where would one send the IMDN to?

> S 14.3.  See above comemnts about nonrepudiation

Fixed.

> -Ekr
_______________________________________________
Simple mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/simple

---

From: Eric Burger <[email-masked]>
Date: Thu, 15 May 2008 00:25:38 +0800

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? Should we give guidance to the range of numbers  
(i.e., 32-bits, 512-bits, 6 digits, etc.)?

On May 14, 2008, at 11:42 PM, Eric Rescorla wrote:

> At Wed, 14 May 2008 12:20:21 +0800,
> Eric Burger wrote:
>>
>> Inline
>>
[snip]
> So, unsurprisingly, it depends.
>
> Is your mental model that you have a list of n valid message-ids
> "outstanding" at once and you want the probability of an attacker
> guessing one to be sufficiently small? With a 32-bit space,
> the chance is n/2^32. So, if you're just treating this as a
> sort of spam filter, then it's probably fine. But if a single
> bad message getting through is fatal, then, no, it's not.
>
> The other thing I would say is that if you want ids to be
> unguessable, then you probably want to say that they should
> be generated with a cryptographically secure random number
> generator. There are lots of PRNGs that produce uniform distributions
> but that are predictable and that won't do here, right?

---

From: Eric Burger <[email-masked]>
Date: Thu, 15 May 2008 07:00:20 +0800

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:
>> 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
> 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
>
>
>
>

---

From: Eric Burger <[email-masked]>
Date: Fri, 16 May 2008 18:24:19 -0400

Please piss on me, not the other Eric.  All he was doing was reviewing  
the draft.  It's not his fault.  Please don't punish him for doing good.

It is my fault that I did not copy the response to your comments  
directly to you.  The message is here:
http://www.ietf.org/mail-archive/web/simple/current/msg07855.html

You are absolutely correct: Message-ID *is* supposed to be like RFC  
2822 Message-ID, which means that it is supposed to be globally  
unique, which means the text is under specified and I need to fix  
that.  Thanks for catching that one.

On May 15, 2008, at 2:53 PM, Eric Rescorla wrote:

> At Thu, 15 May 2008 18:37:51 +0200,
> Frank Ellermann wrote:
>>
>> Eric Rescorla wrote:
>>
>>> As I understand the situation, the sender the only person
>>> who has to rely on the uniqueness of this header, right?
>>
>> Hi, I have not the faintest idea what you are talking about,
>> but if it is in any way related to the 2822upd concept of
>> a Message-ID "worldwide unique forever" is no nonsense as
>> soon as a Message-ID passes mail2news gateways, and/or is
>> used in an Archived-At URL.
>
> I admit that I only spent a little while examining this, so
> perhaps Eric Burger can give a more definitive answer. However,
> looking at the examples in -07, it sure looks to me like
> message ids are not intended to be globally unique forever,
> since, since they're way too short.
>
>
>> | The Message-ID header field contains a unique message identifier.
>> | Netnews is more dependent on message identifier uniqueness and fast
>> | comparison than Email is
>> [...]
>> | The global uniqueness requirement for <msg-id> in [RFC2822]
>> | is to be understood as applying across all protocols using
>> | such message identifiers, and across both Email and Netnews
>> | in particular.
>>
>>> (2) It is prohibitive for an attacker who has seen one or more
>>> valid  Message-IDs to generate additional valid Message-IDs.
>>
>> That would match pseudo-random number, but a "worldwide unique
>> forever" Message-ID can boil down to timestamp @ domain (plus
>> magic to avoid collisions for various Message-ID generators
>> for a given domain or subdomain).
>
> I'm not sure I get the point you're trying to make here. Yes,
> if you want to have unforgeability this is a stronger requirement
> than worldwide uniquness.
>
> -Ekr
>
>
>
>
> IETF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf