ietf-smtp
[Top] [All Lists]

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

2013-10-31 12:22:20
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.

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp