[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