[secdir] SECDIR review of draft-daboo-srv-email-02

[Chris Lonvick <[e-mail]>]

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