Re: [dane] Digest Algorithm Agility discussion

Viktor Dukhovni <viktor1dane@dukhovni.org> Mon, 24 March 2014 15:33 UTC

Return-Path: <viktor1dane@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 94DD71A01C6 for <dane@ietfa.amsl.com>; Mon, 24 Mar 2014 08:33:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 FBYbifsKwTAv for <dane@ietfa.amsl.com>; Mon, 24 Mar 2014 08:33:48 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 416E21A01B9 for <dane@ietf.org>; Mon, 24 Mar 2014 08:33:48 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 110BD2AB250; Mon, 24 Mar 2014 15:33:46 +0000 (UTC)
Date: Mon, 24 Mar 2014 15:33:46 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140324153345.GF13649@mournblade.imrryr.org>
References: <20140323174205.63C6111B2111@rock.dv.isc.org> <20140323182106.GX24183@mournblade.imrryr.org> <20140323185718.7A84711B2CB8@rock.dv.isc.org> <20140323191037.GA1469@anguilla.noreply.org> <20140323192557.7716111B342A@rock.dv.isc.org> <20140323200008.GB1469@anguilla.noreply.org> <20140323202831.GB13649@mournblade.imrryr.org> <20140323230125.EF23411B4816@rock.dv.isc.org> <20140323235727.GC13649@mournblade.imrryr.org> <alpine.LFD.2.10.1403241052240.18937@bofh.nohats.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.LFD.2.10.1403241052240.18937@bofh.nohats.ca>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/H8zy4padM1fCV9IwNstrFkC_m2c
Subject: Re: [dane] Digest Algorithm Agility discussion
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: <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: Mon, 24 Mar 2014 15:33:50 -0000

On Mon, Mar 24, 2014 at 10:54:35AM -0400, Paul Wouters wrote:

> On Sun, 23 Mar 2014, Viktor Dukhovni wrote:
> 
> >when the TLSA records are entirely unusable, and in keeping with Tony's
> >original work on the SRV draft, the client reverts to legacy
> >mandatory (practically always unauthenticated) TLS.
> 
> That's unfortunate. Perhaps it depends on the definition of "unusable",
> but if all TLSA records for instance fail the RRSIG validation, I would
> hope that Postfix would abort delivery attempts and definitely _not_
> fall back to unauthenticated TLS.

Unusable is quite different from "fails validation".  When "usable"
records are found, but none match (all fail validation), delivery
is aborted.

The "unusable" case is when at least one of the TLSA *parameters*
is unsupported, the digest value has an impossible length, or a full
value is malformed:

    example.com. IN TLSA ???(50) SPKI(1) SHA2-512(2) {hex for 64-byte blob}
    example.com. IN TLSA DANE-EE(3) ???(2) SHA2-512(2) {hex for 64-byte blob}
    example.com. IN TLSA DANE-EE(3) SPKI(1) ???(3) {hex for 64-byte blob}
    example.com. IN TLSA DANE-EE(3) SPKI(1) SHA2-512(2) {hex for 32-byte blob}
    example.com. IN TLSA DANE-EE(3) SPKI(1) Full(0) {not ASN.1 of SPKI}
    example.com. IN TLSA DANE-EE(3) Cert(0) Full(0) {not ASN.1 of X.509 cert}

If all records are "unusable", Postfix falls back to unauthenticated TLS.

The administrator may be in a position to configure Postfix to
"test-drive" "DANE TLS" in a mode where validation failures are
tolerated and logged (DANE audit rather than enforcement), but
that's quite different from ignoring validation failures.

The default (when DANE TLS is enabled) is "enforce".  Support for
"audit" mode is under development, and is not DANE TLS specific.
It supports audited fallback from all verified (authenticated) TLS 
policies to either enforced unauthenticated TLS, or even just plain
opportunistic TLS (with cleartext fallback).  In all cases failure
to arrive at the desired security state is logged.

-- 
	Viktor.