[secdir] SECDIR review of draft-daboo-srv-email-02
Chris Lonvick <clonvick@cisco.com> Fri, 04 September 2009 21:33 UTC
Return-Path: <clonvick@cisco.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B32EF3A6821; Fri, 4 Sep 2009 14:33:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.572
X-Spam-Level:
X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 XK8+0Q2knhef; Fri, 4 Sep 2009 14:33:31 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id BD4B33A6873; Fri, 4 Sep 2009 14:33:31 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAOMkoUqrR7PD/2dsb2JhbADBSYhBAZA8BYI4gWOBXQ
X-IronPort-AV: E=Sophos;i="4.44,334,1249257600"; d="scan'208";a="202077007"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 04 Sep 2009 21:33:39 +0000
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n84LXdpO008071; Fri, 4 Sep 2009 14:33:39 -0700
Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n84LXcbF016914; Fri, 4 Sep 2009 21:33:38 GMT
Date: Fri, 04 Sep 2009 14:33:38 -0700
From: Chris Lonvick <clonvick@cisco.com>
To: iesg@ietf.org, secdir@ietf.org, cyrus@daboo.name
Message-ID: <Pine.GSO.4.63.0909041326580.18544@sjc-cde-011.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3571; t=1252100019; x=1252964019; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20<clonvick@cisco.com> |Subject:=20SECDIR=20review=20of=20draft-daboo-srv-email-02 |Sender:=20; bh=tO9QjXf9/0CHKwMkWa41qNHtlvdum4n4vxuT7sid+LU=; b=JW5h6EBYepcqqau4vXJXeiqtcquqBcrCtjrdhsDLZYofCo3P0j1lYybMD3 XRsV6w0bzMDik/4S73l0ftfeVDdMRHPGFJHEPYsskC5MdZd/Y5frKIVSCp7i dDXBkdrtGf;
Authentication-Results: sj-dkim-3; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; );
Cc: secdir-secretary@mit.edu
Subject: [secdir] SECDIR review of draft-daboo-srv-email-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Sep 2009 21:33:32 -0000
Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Overall, this looks like a good document and I don't have any concerns with it. I do have a few nits that you may want to look at. In the Introduction, s/miniml/minimal/ I think that you're missing a comma in the last paragraph: Perhaps it should be (with second comma added): This specification defines new SRV service types for the message submission, IMAP and POP3 services, to enable simple auto configuration of email clients. Also, the Introduction does not seem to flow very well. If I may suggest the following, which is just a rearrangement of the content: SUGGESTED: --- Internet Email protocols include SMTP [RFC5321], IMAP [RFC3501] and POP3 [RFC1939]. Both IMAP and POP3 are mail access protocols used by email clients to manipulate email messages after delivery. [RFC2782] defines a DNS-based service discovery protocol that has been widely adopted as a means of locating particular services within a local area network and beyond, using SRV RR records. [RFC5321] defines the MX RR record type to locate SMTP services for a domain. However, [RFC4409] defines a "profile" of the SMTP service that is specifically used for message submission - which is of direct relevance to email clients which typically don't use MX records. Typically email clients have required users to enter host name and port information for the services they need. This is not ideal as the way in which server information is specified can differ from client to client, and can be confusing to users, leading to errors when inputting the details. A better approach would be to require minimal information to be entered by a user which would result in automatic configuration of appropriate services for that user. The minimal information entered would be the user's email address. This specification defines new SRV service types for the message submission, IMAP and POP3 services, to enable simple auto configuration of email clients. --- The last sentence in the 4th paragraph of Section 4 is: When using transport layer security in this way, clients SHOULD use the TLS Server Name Indication [RFC4366] and include the service domain name used in the SRV record lookup as the name. Perhaps to fully qualify this, it should be: When using transport layer security in this way, clients SHOULD use the TLS Server Name Indication [RFC4366] and include the service domain name used in the SRV record lookup as the name of the server it is contacting. In most cases the term "server" references the email server, in much the same way that "client" refers to the email client. However, there are some cases of "TLS Server" and "DNS Server". It might be good to qualify that. Perhaps a statement in Section 2 to say, "If not otherwise qualified, the term server refers to hosts offering the POP3 or IMAP service." I'm curious as to why you're not asking for an IANA registry be created for this. A quick search shows that there is for IM SRV labels. http://www.iana.org/assignments/im-srv-labels Regards, Chris
- [secdir] SECDIR review of draft-daboo-srv-email-02 Chris Lonvick
- Re: [secdir] SECDIR review of draft-daboo-srv-ema… Alexey Melnikov