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

[Alexey Melnikov <[e-mail]>]

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 "[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.
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