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