Re: [Uta] I-D Action: draft-ietf-uta-email-tls-certs-03.txt

[Viktor Dukhovni <[e-mail]>]

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 "[e-mail]" 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.

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.

-- 
	Viktor.