Hi Viktor,
On 18/06/2015 17:02, Viktor Dukhovni wrote:
On Wed, Jun 17, 2015 at 11:53:02AM +0100, Alexey Melnikov wrote:
Filename : draft-ietf-uta-email-tls-certs-03.txt
I believe this version addresses WGLC comments. Let me know if I've missed
anything.
Sorry, I've been away from the UTA list for a while, too few cycles
to keep up with everything.
So while I did not raise this during WG LC (which may be over), I am
concerned about the first example in Section 6, namely:
Consider an IMAP-accessible email server which supports both
IMAP and IMAPS (IMAP-over-TLS) at the host "mail.example.net"
servicing email addresses of the form "[email protected]" and
discoverable via DNS SRV lookups in domain "example.net" (DNS
SRV records "_imap._tcp.example.net" and "_imaps._tcp.example.net").
A certificate for this service needs to include SRV-IDs of
"_imap.example.net" (when STARTTLS is used on the IMAP port)
and "_imaps.example.net" (when TLS is used on IMAPS port). See
[RFC6186] for more details. (Note that unlike DNS SRV there is
no "_tcp" component in SRV-IDs) along with DNS-IDs of "example.net"
and "mail.example.net". It might also include CN-IDs of
"mail.example.net" for backward compatibility with deployed
infrastructure.
I improved the example by splitting it into 2 parts (only server
hostname is used and server hostname + RFC 6186 discovery procedure). I
also fixed partial sentences that you spotted.
I also corrected/expanded text in Section 3 which talks how different
"reference identifiers" are constructed. I discovered that the text was
not as clear as it should have been.
The concern is that when this service is "discovered" via ordinary
DNS (i.e. no DNSSEC) the server name is not obtained securely, and
and any use of TLS authentication based on an insecurely obtained
reference identifier is "too late" to protect the user against MiTM
attacks. This is not discussed in sufficient detail.
In my view the "Security Considerations" section (6 coincidentally)
of RFC6186 places an unreasonable burden on the user to make subtle
security decisions:
A malicious attacker with access to the DNS server data, or able
to get spoofed answers cached in a recursive resolver, can
potentially cause MUAs to connect to any IMAP, POP3, or submission
server chosen by the attacker. In the absence of a secure DNS
option, MUAs SHOULD check that the target FQDN returned in the
SRV record matches the original service domain that was queried.
If the target FQDN is not in the queried domain, MUAs SHOULD
verify with the user that the SRV target FQDN is suitable for
use before executing any connections to the host. Alternatively,
if TLS [RFC5246] is being used for the email service, MUAs MUST
use the procedure outlined in Section 6 of [RFC6125] to verify
the service.
In the "SMTP security via opportunistic DANE TLS" draft, in section 7
https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-7
I note that when SRV records are used to locate submission services,
similar conclusions to those reached in the MTA-to-MTA documention
ought to apply and DANE may well be the right security model once
one trusts DNS to handle service indirection:
We note that the SMTP protocol is also used between Message User
Agents (MUAs) and Message Submission Agents (MSAs) [RFC6409]. In
[RFC6186] a protocol is specified that enables an MUA to dynamically
locate the MSA based on the user's email address. SMTP connection
security considerations for MUAs implementing [RFC6186] are largely
analogous to connection security requirements for MTAs, and this
specification could be applied largely verbatim with DNS MX records
replaced by corresponding DNS Service (SRV) records
[I-D.ietf-dane-srv].
However, until MUAs begin to adopt the dynamic configuration
mechanisms of [RFC6186] they are adequately served by more
traditional static TLS security policies. Specification of DANE TLS
for Message User Agent (MUA) to Message Submission Agent (MSA) SMTP
is left to future documents that focus specifically on SMTP security
between MUAs and MSAs.
So now that you're specifically advocating support for RFC6186 and
DNS based dynamic configuration/redirection, perhaps it is time to
flesh out the discussion with a more complete security model (i.e.
DANE).
At the very least, more text is needed to explain that just forging
ahead and trusting insecure SRV records is problematic, but once
DNSSEC *is* trusted, then there no downside to "in for a penny for
a pound" and using DANE keying also, and I believe there are real
advantages to doing so.
I added a new paragraph in the Security Considerations:
TLS Server Identity Check for Email relies on use of trustworthy DNS
hostnames when constructing "reference identifiers" that are checked
against an email server certificate. Such trustworthy names are
either entered manually (for example if they are advertised on a Mail
Service Provider's website), explicitly confirmed by the user (e.g.
if they are a target of a DNS SRV lookup) or derived using a secure
third party service (e.g. DNSSEC-protected SRV records which are
verified by the client or trusted local resolver). Future work in
this area might benefit from integration with DANE [RFC6698], but it
is not covered by this document.
As we also discussed, I am happy to co-edit with you a document that
describes how to use DANE TLSA + DNSSEC for email server TLS identity
verification.
Best Regards,
Alexey
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
