Subject: Re-review of draft-ietf-simple-imdn

From: Eric Rescorla <[email-masked]>
Date: Sat, 03 May 2008 14:12:33 -0700

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.
What happens if someone puts an IMDN-Record-Route that points
to an IMDN-ignorant UA?
       
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.

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.

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

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?

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.

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?

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

S 14.3.  See above comemnts about nonrepudiation

-Ekr

_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

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

Inline

> 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

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.

> analysis of what the potential mechanisms were and why they would or

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.

> hard to know what it means.
Fixed

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

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

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

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

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 14 May 2008 08:42:17 -0700

At Wed, 14 May 2008 12:20:21 +0800,
>     MUST send the IMDN to the URI in the From header field.

That seems reasonable.

> field MUST be the intermediary's own address.

OK.

>     be able to preserve much of a log.

This seems to accurately characterize the situation. I'm not really
ready to offer an opinion on whether this is an acceptable
security situation--that seems like a question for the WG and the
IESG...

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

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?

> combining the two would not be a good thing.

OK. It was just a side note.

> unenforceable. Can this one slide under the radar?

Got me. This seems like the kind of question that comes up whenever
we have schema. Have the Apps ADs taken a position on that.

> Where would one send the IMDN to?

This goes back to my confusion over where the notifications go.

Seems fine with this explanation.

-Ekr

---

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 4, 2008, at 5:12 AM, Eric Rescorla wrote:
[snip]

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 14 May 2008 10:25:56 -0700

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 15 May 2008 18:37:51 +0200

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.

> the Message-ID MUST be selected so that:
   
> colliding within the time period within which an IMDN might be

That is apparently the definition for some UUID versions, but
not for a Message-ID as specified in RFC.ietf-usefor-usefor:

| 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).
 
> it is RECOMMENDED that Message-IDs be generated using a
> cryptographically secure pseudorandom number generator

Please get the terminology right as first priority, what you
are talking about is apparently *NOT* an 2822upd Message-ID
as used in mail, news, APOP, and CRAM-MD5.

 Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 15 May 2008 18:50:12 +0200

>> Examining the diff, it does not appear to me that
>> any of my comments from my previous review.

If the draft still talks about Message-IDs which are
something else I have to say "+1":

http://article.gmane.org/gmane.ietf.general/28657/match=message+id

"As is" (version -07) the draft IMO isn't ready.

 Frank

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 15 May 2008 11:53:34 -0700

At Thu, 15 May 2008 18:37:51 +0200,
> 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.

> 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

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 15 May 2008 21:28:30 +0200

> since, since they're way too short.

Indeed, whatever it is, it is certainly no 2822 Message-ID.

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

Some Message-ID generators I'm aware of use timestamps 
spiced with other ingredients (process number, specific
format per application) for the unique part (left hand
side), and their outcome is predictable to some degree.

Noted in the "security considerations" of corresponding
RFCs as one of several possible issues with Message-IDs.

I'm not sure what this IMDN handle really is, some kind
of magic cookie.

 Frank

---

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.