That would assume deploying dnssec on Gmail.com is somehow easier than on
Google.com :-)
On Sep 6, 2013 8:50 AM, "Viktor Dukhovni" <[email protected]> wrote:
> On Fri, Sep 06, 2013 at 09:17:20AM -0400, James Cloos wrote:
>
> > The idea of using the existence of an unsecured tlsa rr as a hint that
> > tls must be used was, IIRC, discussed in the early days of this wg.
>
> This is largely impractical for SMTP. SMTP TLSA RRs are of course
> tied to MX hosts (transport destinations), not email domains. An
> MITM can bypass any such cached RRs by sending malicious MX replies.
>
> The TTLs on MX records are often relatively short (gmail.com is 1H)
> so attacks don't require the attacker to wait long and for smaller
> destination domains which don't receive a steady stream of traffic
> from all senders, or when intercepting a low-volume sender, the
> target MX RRset is often already expired from the cache due to
> infrequent mail transmission.
>
> Also any insecure data with a remotely specified TTL is a golden
> opportunity for cache poisoning attacks. Just set a very long TTL
> with a bogus certificate association and the MITM attacker is set
> for a long time. In the mean time log entries show happily
> authenticated connections, nobody is any the wiser unless they are
> logging the underlying digests and looking for malicious changes.
>
> I understand that it would be convenient if security could be
> obtained more easily. Sadly, there is a lower bound on the cost.
>
> > Doing MX+TLSA queries as soon as the destination(s) are known so as to
> > indicate the possibility of TLS (Trusted, Untrusted or Verified) can be
> > a good idea.
>
> What should an MTA do differently when insecure TLSA records are
> found for one or more MX hosts, and why?
>
> > But it tlsa existance is to be the key, it does seem best to demand that
> > it be secured.
>
> On this we agree.
>
> > But please do publish the tlsa sooner rather than later. Even though
> > they likely will not get used in practice until the zones are signed,
> > tests can still be done to ensure accuracy, and there won't have to be
> > any delays post-signing.
>
> A better test is to use non-production MX hosts in a signed zone.
>
> dane-test.gmail.com. IN MX 0 mx.dane-test.gmail.com.
> mx.date-test.gmail.com. IN A 192.0.2.1
> mx.date-test.gmail.com. IN TLSA 2 1 1 {sha256 pubkey hash}
>
> then one can test verified connections to dane-test.gmail.com before
> publishing TLSA RRs for the production zone.
>
> --
> Viktor.
> _______________________________________________
> dane mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dane
>
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
