At Wed, 14 May 2008 12:20:21 +0800, Eric Burger wrote: > > 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. That seems reasonable. > > 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. OK. > 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. 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... > > 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! 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? > > 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. OK. It was just a side note. > > 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? 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. > > S 12.1.1. Why can't anonymous senders request notifications? > > Where would one send the IMDN to? This goes back to my confusion over where the notifications go. Seems fine with this explanation. -Ekr _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf