[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