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

[Leif Johansson <[e-mail]>]

On 2015-08-06 15:51, Alexey Melnikov wrote:
> 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

OK it sounds to me like these are small enough so we don't need another
WGLC. We'll ship it upstairs with these changes.

	Cheers Leif