Re: [dane] Barry Leiba's Discuss on draft-ietf-dane-smtp-with-dane-17: (with DISCUSS and COMMENT)

Mark Andrews <marka@isc.org> Tue, 26 May 2015 00:03 UTC

Return-Path: <marka@isc.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8061A020B; Mon, 25 May 2015 17:03:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.511
X-Spam-Level:
X-Spam-Status: No, score=-0.511 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLDIe6IPVBIY; Mon, 25 May 2015 17:03:46 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8D6A1A01F0; Mon, 25 May 2015 17:03:45 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 6E75134940D; Tue, 26 May 2015 00:03:42 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id B501B160087; Tue, 26 May 2015 00:04:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id A284D160089; Tue, 26 May 2015 00:04:07 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3JADM3PsGw9h; Tue, 26 May 2015 00:04:07 +0000 (UTC)
Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id 24798160087; Tue, 26 May 2015 00:04:07 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id D70AC2F50D87; Tue, 26 May 2015 10:03:38 +1000 (EST)
To: Olafur Gudmundsson <ogud@ogud.com>
From: Mark Andrews <marka@isc.org>
References: <20150524204121.31745.72546.idtracker@ietfa.amsl.com> <20150525020430.GK17272@mournblade.imrryr.org> <841AFD92-8615-43BF-98B4-48770FA72235@ogud.com>
In-reply-to: Your message of "Mon, 25 May 2015 19:17:09 -0400." <841AFD92-8615-43BF-98B4-48770FA72235@ogud.com>
Date: Tue, 26 May 2015 10:03:37 +1000
Message-Id: <20150526000338.D70AC2F50D87@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dane/IvQxSl5gUS5OfJOvzG4M78BMVNw>
Cc: draft-ietf-dane-smtp-with-dane@ietf.org, The IESG <iesg@ietf.org>, dane WG list <dane@ietf.org>
Subject: Re: [dane] Barry Leiba's Discuss on draft-ietf-dane-smtp-with-dane-17: (with DISCUSS and COMMENT)
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 May 2015 00:03:47 -0000

In message <841AFD92-8615-43BF-98B4-48770FA72235@ogud.com>, Olafur Gudmundsson 
writes:
> >> 2. Section 2.2.1 says this:
> >> 
> >>   That said, the protocol in this memo is
> >>   an "opportunistic security" protocol, meaning that it strives to
> >>   communicate with each peer as securely as possible, while maintaining
> >>   broad interoperability.? Therefore, the SMTP client MAY proceed to
> >>   use DANE TLS (as described in Section 2.2.2 below) even with MX hosts
> >>   obtained via an "insecure" MX RRSet.? For example, when a hosting
> >>   provider has a signed DNS zone and publishes TLSA records for its
> >>   SMTP servers, hosted domains that are not signed may still benefit
> >>   from the provider's TLSA records.
> >> 
> >> That makes sense. Why doesn't the same thing apply for insecure TLSA
> >> records?  Section 2.2 says that when TLSA records are insecure, you 
> don't
> >> use them, and SHOULD use pre-DANE security.  Please explain why they
> >> shouldn't use insecure TLSA records for opportunistic encryption.
> > 
> > If I recall correctly, the working group was concerned about diluting
> > the otherwise clear position that TLSA should not be used without
> > DNSSEC.
> 
> Barry, the working went down this path at one point and it turns quickly 
> into a quicksand of special cases. 
> For that reason we are not in base documents allowing TLSA w/o DNSSEC, 
> Same goes for Service Records (SRV + MX) as if those are forged there is 
> no value in TLSA for the forged 
> servers. 
> IMHO we should hold SRV and MX records to the same standard and IESG has 
> blessed the SRV doc with
> DNSSEC MUST, so I will object strongly to any attempt to lower the 
> requirements. 

In addition it is just plain pointless to do the lookup.

If the A/AAAA is insecure the TLSA lookup will be insecure due to
there being not DNSSEC trusted path the TLSA node.  You can't prove
whether the server was supposed to offer STARTTLS or not.  Faked
answers can "prove" either assertion.

You don't get a viable trust anchor if you do get back a TLSA record
as the answer will be insecure.  SMTP servers can already be
configured to accept CERTS where you don't have a trust anchor for
that server if you just want to have a encrypted stream to stop
casual snooping of traffic and the server happens to say it supports
STARTTLS.

> > In the context this draft alone, the main reason to avoid using
> > TLSA records from insecure zones, is that lookups of such records
> > are prone to failures (with long timeouts while trying all NS
> > records) against "bare-bones" nameservers that support neither
> > DNSSEC nor TLSA records.

The main reason for not doing the lookup is that it is pointless
(see above).  The very much secondary reason for not doing the
lookup is that there is a very small percentage of servers that
mishandle TLSA lookups.  SMTP servers are going to have to handle
these broken servers once they get secure A/AAAA responses.

draft-andrews-dns-no-response-issue is looking at the issues of
servers that don't respond or respond incorrectly.

> > When the MX RRset is secure, but the A/AAAA records are insecure,
> > no TLSA lookup takes place.  I think that proceeding with (soft-fail)
> > TLSA lookups when the MX RRset is insecure invites implementation
> > errors.
> 
> +1 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org