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 "[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
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
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
