Re: [dane] DANE for MX host via insecure MX RR?

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 10 September 2015 16:53 UTC

Return-Path: <ietf-dane@dukhovni.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 83F821A0383 for <dane@ietfa.amsl.com>; Thu, 10 Sep 2015 09:53:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 AF0toLHBhVzU for <dane@ietfa.amsl.com>; Thu, 10 Sep 2015 09:53:38 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 436A11B37A9 for <dane@ietf.org>; Thu, 10 Sep 2015 09:53:38 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 97FC9284B70; Thu, 10 Sep 2015 16:53:37 +0000 (UTC)
Date: Thu, 10 Sep 2015 16:53:37 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20150910165337.GZ21942@mournblade.imrryr.org>
References: <D976ACCE-8F15-448C-A5E4-B8D1FD329A8B@frobbit.se> <20150824031926.GF9021@mournblade.imrryr.org> <55F1B075.5060809@stroeder.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <55F1B075.5060809@stroeder.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dane/tCHZCzpnlYdvKV2YqUluCxZDBhc>
Subject: Re: [dane] DANE for MX host via insecure MX RR?
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 10 Sep 2015 16:53:40 -0000

On Thu, Sep 10, 2015 at 06:31:49PM +0200, Michael Ströder wrote:

> > If you want to propose an update that requires SMTP clients to
> > employ DANE TLSA verification of MX hosts in signed zones even when
> > the MX RRset was not "secure", read the previous discussion of this
> > question in the list archives (yes, it has come up before) and make
> > a clear-cut proposal with as solid a rationale as you can.  
> > 
> > I am not sure this can get enough support to reach "rough consensus",
> > but I'm open to the possibility.
> 
> Without a signed MX there's no cryptographically secured binding between the
> recipient domain (right address part) and the public key used for TLS authc.
> 
> So I'm strictly against this possibility and the developers of a MTA I spoke
> with today are also strongly against this.
> 
> @Patrik: Deploying DNSSEC/DANE at large scale is not an easy job. If you drop
> the requirement for signed MX RRs DANE would not be worth the effort to be
> implemented.

Note, the hypothetical proposal would not weaken DANE in any way,
nor would it "drop" the requirement to pay attention to the security
status of the MX RRset, in particular "bogus" replies or other DNS
errors in MX resolution would still result in deferral of mail.

All that would hypothetically happen, is that even when the MX
RRset is "insecure" (verifiably from an unsigned zone) but the
target MX host is in a signed zone and has "secure" TLSA records,
DANE authentication might be "SHOULD" or "MUST", rather than the
current "MAY".

    https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-2.2.1

       Since the protocol in this memo is an "opportunistic security"
       protocol ([RFC7435]) the SMTP client MAY elect 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.  Deliveries via the provider's SMTP servers
       will not be subject to active attacks when sending SMTP clients elect
       to make use of the provider's TLSA records (active attacks that
       tamper with the "insecure" MX RRSet are of course still possible in
       this case).

I think the current "MAY" is sufficient for now, but if that proves
to be a valuable feature of the protocol, an a short update BCP
RFC upgrading the "MAY" to a "SHOULD" or "MUST" might be possible
in the future.

So long as such sessions are not reported as secure, and are not
accepted when DANE authentication is mandatory (e.g. Postfix
"dane-only" TLS security level), the proposal does not in any
way reduce the security of DANE as specified.

The main risk is with reliability.  Perhaps only those customers
of a service provider that operate DNSSEC signed domains are willing
to accept service availability risk in case of DANE authentication
failure, and the customers with unsigned zones want service
availability above all else.  If the proposal is formalized, then
all customer domains suffer if the TLSA records are ever wrong,
even those whose domains are unsigned.  

Of course service outages happen for operational reasons beyond
incorrect TLSA record updates (or failure to update).  And the
sending domains that elect the "MAY" policy will defer email even
for the unsigned domains.

So the proposal is not obviously damaging, just possibly premature.
We'll know more once there is more deployment and people either
learn (or don't learn) to operate their TLSA records correctly.

-- 
	Viktor.