[ietf-smtp] Review of draft-moore-email-tls-00.txt

[Alexey Melnikov <[e-mail]>]

Hi Keith,
I am glad to see your draft. Some specific comments:

2.1.  Mail Server Requirements

    The following requirements apply to IMAP, POP, and Submission server
    implementations:

    All IMAP, POP, and Submission servers MUST be configurable to support
    the use of TLS and the Implicit TLS mechanism when communicating with
    MUAs.

While reading your document I was wondering where the secure submission
is defined. Then I finally found a request for a new port in the IANA
considerations section.

Several MUAs and multiple MSPs implement secure submission on port 465.
This was never document and is not registered. (I think this was a Microsoft
invention, but I don't know exact history.) The port is officially
assigned to another protocol.

There are a couple of problems with that. One is trying to register 
unofficially used 465.
Alternatively, we can try to register a new port, but what are the 
chances of people
actually migrating to the new default for secure submission?


2.2.  Mail User Agent Requirements

    This section describes requirements on Mail User Agents (MUAs) using
    IMAP, POP, and/or Submission protocols.

    Note: Requirements pertaining to use of Submission servers are also
    applicable to use of SMTP servers (whether on port 25 or on another
    port as advertised by a SRV record with _smtp._tcp or _smtps._tcp
    label) for mail submission.

This note seems a bit out of place, as you already mentioned elsewhere
that MTA-to-MTA SMTP is out of scope for this document. Plus you are sort
of trying to register smtps here, but you really don't.


2.2.8.  Requirements for MUA use of TLS

    MUAs MUST use the procedure defined in [RFC6125] to determine whether
    a server's TLS certificate contains an identifier which matches the
    DNS name to which the MUA is attempting to connect, and MUST abort
    the TLS session if the server's certificate does not present an
    identifier that matches one of the MUA's predetermined reference
    identifiers for that server.

    It is important to avoid using DNS names obtained from SRV records
    (rather than from explicit user configuration) as reference
    identifiers when comparing with presented identifiers in TLS server
    certificates, unless those SRV records were signed with DNSSEC and
    the signatures were verified by the MUA.

    Note in Draft: [I-D.melnikov-email-tls-certs] describes a profile of
    [RFC6125] for use in MUA checking of presented identifiers in TLS
    server certificates.

Not surprisingly, I think that you should delete the second quoted paragraph
(my draft already includes it) and update the first paragraph to reference
[I-D.melnikov-email-tls-certs]. This would also make 
[I-D.melnikov-email-tls-certs]
normative.

The problem with your first paragraph is that just referencing RFC 6125 is
not enough to get interoperability, because any use of RFC 6125
needs to describe use or non use of several parameters, like SRV-ID, 
CN-ID, etc.


2.2.12.  Use of DANE by MUAs

   o  TLSA record exists and has a valid DNSSEC signature, and the
       public key specified in a TLSA record matches the public key in
       the X.509 certificate presented by the server.  However, the
       server certificate is not signed by a trusted certificate
       authority,

I think this might not be relevant, depending on the TLSA record type used.

       nor has the MUA been explicitly configured ("pinned")
       to accept that particular certificate.  In this case the
       connection MUST gracefully terminate the session with the server
       without attempting to authenticate or request services.

Isn't this the case for asking the user to pin the certificate?

3.3.  TLS Server Certificate Requirements

    MSPs MUST maintain valid server certificates for all servers. Those
    server certificates MUST present DNS-IDs and SRV-IDs conforming to
    [RFC6125] and which will be recognized by MUAs meeting the
    requirements of this memo.  In addition, those server certificates
    MAY provide other DNS-IDs, SRV-IDs, or CN-IDs needed for
    compatibility with legacy MUAs.

Again, I think this should reference [I-D.melnikov-email-tls-certs].


    [RFC4409]  Gellens, R. and J. Klensin, "Message Submission for Mail",
               RFC 4409, April 2006.

This was obsoleted by RFC 6409, so there is no need to reference both 
Normatively.