On 10/31/2013 01:22 PM, Alexey Melnikov wrote:
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?
I think it might be tricky to get approval for a standard recommending
use of an already-assigned port 465 for mail submission. So I suspect
the right thing to do is to still ask IANA for a new port for Submission
over TLS, but to document (non-normatively) that some implementations
are using port 465 for this purpose.
Note that if an MSP advertises its submission servers using SRV records,
it can use any port(s) it wishes to use.
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.
The note could certainly use rewording. But the basic idea is that either
a) an MSP's SRV records could advertise _smtp._tcp (or _smtps._tcp if
such a thing existed), but not _submissions._tcp, in which case the MUA
should probably assume that that service is the way to submit mail
OR
b) an MSP could document (say on its web pages) that MUAs should be
configured to submit mail to server xxx.example.com at port 25
and in either of those cases the requirements defined for mail
submission by an MUA still apply: e.g. if the configuration says "TLS
required", then the MUA MUST use TLS (whether Implicit TLS or STARTTLS)
and MUST NOT submit mail without using TLS, it MUST use the certificate
verification rules and name matching rules, it MUST NOT blindly trust
SRV records unless they're DNSSEC signed and verified, etc.
I think the _smtps._tcp is just an oversight. I wasn't intending to
propose that we define an smtps service.
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.
I certainly agree that 6125 is not sufficient.
If I recall correctly, I had some questions about
melnikov-email-tls-certs that made me somewhat reluctant to reference it
as normative for my -00 draft. But I'll reread your draft (hopefully
before Monday) and get back to you about it.
I took a stab at writing a profile of 6125 myself, and found it
difficult to write text that clearly described what needed to happen.
There are lots of different error conditions that need to be considered,
and it wasn't clear to me what was the right thing to do for every case.
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.
The DANE/TLSA text in my draft currently doesn't go into anywhere nearly
enough detail, and needs a lot of work. For version -01 I plan to crib
from draft-ietf-dane-smtp-with-dane but I want to double check it to
make sure it makes sense.
Aside: One thing about DANE that I find very dubious is the idea that a
DNSSEC-signed TLSA record is a suitable /replacement/ for a certificate
signed by a CA. I don't know of any reason to assume that the chain of
DNSSEC signatures from the root to the zone that signs the TLSA record
is any more trustworthy than the signature of a well-known CA. Yes, we
know of cases where the latter have proven untrustworthy - presumably
because the CA acted inapporpriately or because its private key was
compromised - but I don't know why this is less likely to happen for
DNSSEC signatures. I'm all for using TLSA records to provide an
additional trust anchor for a server's certificate beyond that provided
by the server's CA - so that the attacker will have to compromise
multiple parties in order to impersonate the server - but doubt that
it's a good idea to say that a signed TLSA record is sufficient by
itself. Relying entirely on signed TLSA records actually appears to
me to be structurally weaker than relying entirely on well-known CAs.
(And I understand that small-scale servers would like to use self-signed
certificates, but I haven't yet figured out how to permit that without
making users vulnerable.... except by allowing MUAs to "pin"
certificates that aren't verifable. And even that seems like shaky
ground, but it's probably needed for testing anyway.)
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?
I would like to clearly separate two conditions:
- during configuration, it's okay to for an MUA to say "This server's
certificate isn't verifable, but if you know for sure that it's valid,
you can configure the account to trust it. If you don't know for sure
that it's valid, you should contact your mail service provider to verify
it."
- during normal mail reading, submission, etc., it's NOT okay to offer
to let the user pin the certificate. IMO, the MUA should report this
to the user as a potential attack and refuse to read/submit mail until
the condition is fixed. The user should probably contact his/her mail
service provider for further instructions.
Now maybe this isn't exactly how things should be implemented. But the
point is, if the user interface makes it too easy for the user to just
'click past' warnings without really understanding what's going on or
verifying that the condition is reasonable, we haven't gained anything
in terms of privacy in exchange for the added complexity - we've only
gained the illusion of privacy.
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.
good catch. thanks.
Keith
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp