[lemonade] Comments on draft-ietf-lemonade-urlauth-07.txt
Randall Gellens <randy@qualcomm.com> Fri, 05 August 2005 09:45 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ylG-0005pl-6o; Fri, 05 Aug 2005 05:45:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ylE-0005mt-2q; Fri, 05 Aug 2005 05:45:04 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29357; Fri, 5 Aug 2005 05:45:01 -0400 (EDT)
Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0zIH-0001aI-SP; Fri, 05 Aug 2005 06:19:14 -0400
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j759iho7010171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 5 Aug 2005 02:44:44 -0700 (PDT)
Received: from [86.255.29.131] (vpn-10-50-16-27.qualcomm.com [10.50.16.27]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j759iduZ024511; Fri, 5 Aug 2005 02:44:41 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p07000c03bf127ddcfd5c@[192.168.1.13]>
X-Mailer: Eudora for Mac OS X v7.0a
X-message-flag: Using Outlook? Upgrade to Eudora: <http://www.eudora.com>
Date: Fri, 05 Aug 2005 02:44:39 -0700
To: iesg@ietf.org, MRC@CAC.Washington.EDU, Lemonade <lemonade@ietf.org>
From: Randall Gellens <randy@qualcomm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Cc:
Subject: [lemonade] Comments on draft-ietf-lemonade-urlauth-07.txt
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe>
Sender: lemonade-bounces@ietf.org
Errors-To: lemonade-bounces@ietf.org
Sorry for the late comments. I think there are some minor fixes/clarifications needed, but these are no big deal. Technical: Section 3, lines 239-241: "Use of either of these access identifiers makes it impossible for an attacker, spying on the session, to use the same URL, either directly or by submission to a message submission entity." The "impossible" depends on the attacker being able to capture the session, but not be able to use the same submission server or to capture the user's authentication credentials (for either the IMAP or submit services). While this seems very obvious, and perhaps not worth saying, it does mean, for example, that an attacker who shares the same submission server can reuse a URLAUTH protected by "submit+", and an attacker who can capture the authorization credentials can of course access arbitrary data belonging to the user. Likewise, if the attacker can capture the submission session, he or she can capture everything sent in that session, including messages sent without using BURL, so the risk the same either way, perhaps less with URLAUTH since the attacker may be thwarted by use of "submit+" or "user+". Section 5, line 300: "case-folding MUST NOT occur" I wonder if it is worth adding a parenthetical note that this applies to the domain portion of the URL as well as the rest of it. There may be implementations which rely on the domain portion of URLs to be case-insignificant, but probably such implementations are rare enough that we're better off not doing anything. May want to add an explanation of why the server would follow the exception in Section 6: In the case of an invalid userid supplied as mailbox access key owner and/or as part the access identifier, the server MAY issue a tagged OK response with a generated mailbox key that always fails validation when used with a URLFETCH command. Editorial: Section 1.4, line 140: "e.g" should be "e.g.," Section 2, line 165: "specific message" should be either "specific messages" or "a specific message". Section 2, line 199, unclear if "must" means "MUST". Section 3, line 236, "requires the session be" should be either "requires that the session be" or "requires the session to be" Section 3, line 244, "level protection" should be "level of protection" Section 6, line 391, "supplied as mailbox access key owner" maybe should be "supplied as the mailbox access key owner" Section 6, line 391-392, "part the access identifier" should be "part of the access identifier". Section9, line 638, "disclosed to anonymous" should probably be "disclosed to anyone". -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. --Albert Einstein _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade
- [lemonade] Comments on draft-ietf-lemonade-urlaut… Randall Gellens
- [lemonade] Re: Comments on draft-ietf-lemonade-ur… Mark Crispin
- RE: [lemonade] Re: Comments on draft-ietf-lemonad… Eric Burger
- RE: [lemonade] Re: Comments on draft-ietf-lemonad… Mark Crispin
- [lemonade] Re: Comments on draft-ietf-lemonade-ur… Randall Gellens
- [lemonade] Re: Comments on draft-ietf-lemonade-ur… Mark Crispin
- [lemonade] Re: Comments on draft-ietf-lemonade-ur… Randall Gellens