Re-review of draft-ietf-simple-imdn
Eric Rescorla <ekr@networkresonance.com> Sat, 03 May 2008 21:10 UTC
Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20F0E3A6E1F; Sat, 3 May 2008 14:10:12 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E3333A6DF1; Sat, 3 May 2008 14:10:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.537
X-Spam-Level:
X-Spam-Status: No, score=-0.537 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olEsCwME3IfQ; Sat, 3 May 2008 14:10:01 -0700 (PDT)
Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 571B83A6E8C; Sat, 3 May 2008 14:08:59 -0700 (PDT)
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 0377B5081A; Sat, 3 May 2008 14:12:33 -0700 (PDT)
Date: Sat, 03 May 2008 14:12:33 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: draft-ietf-simple-imdn@tools.ietf.org
Subject: Re-review of draft-ietf-simple-imdn
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Message-Id: <20080503211234.0377B5081A@romeo.rtfm.com>
Cc: secdir@mit.edu, iesg@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
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 IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
- Re-review of draft-ietf-simple-imdn Eric Rescorla
- Re: Re-review of draft-ietf-simple-imdn Eric Burger
- Re: Re-review of draft-ietf-simple-imdn Eric Rescorla
- Randomness of Message-ID in IMDN Eric Burger
- Re: Randomness of Message-ID in IMDN Eric Rescorla
- Re: Randomness of Message-ID in IMDN Eric Burger
- Re: Randomness of Message-ID in IMDN Frank Ellermann
- Re: Re-review of draft-ietf-simple-imdn Frank Ellermann
- Re: Randomness of Message-ID in IMDN Eric Rescorla
- Re: Randomness of Message-ID in IMDN Frank Ellermann
- Re: Randomness of Message-ID in IMDN Eric Burger