Re: [TLS] TLS interim meeting material

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 14 September 2018 15:34 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5D6130EEB for <tls@ietfa.amsl.com>; Fri, 14 Sep 2018 08:34:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 wYb5nOx5FVCe for <tls@ietfa.amsl.com>; Fri, 14 Sep 2018 08:33:58 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 772B3130EA3 for <tls@ietf.org>; Fri, 14 Sep 2018 08:33:58 -0700 (PDT)
Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id EA1C4308C57 for <tls@ietf.org>; Fri, 14 Sep 2018 11:33:56 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CAL02cgRfOF1Y_XC-=oPqB59RV97=O9_9BJHg2cE2mx3Rk0m26g@mail.gmail.com>
Date: Fri, 14 Sep 2018 11:33:54 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: "<tls@ietf.org>" <tls@ietf.org>
Message-Id: <D29B3688-76C6-4A91-9C22-5B0C2601FB19@dukhovni.org>
References: <alpine.LRH.2.21.1809121721300.5141@bofh.nohats.ca> <CAL02cgRfOF1Y_XC-=oPqB59RV97=O9_9BJHg2cE2mx3Rk0m26g@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/O3noIuhpi1MQVWXAy-xjJryRkAU>
Subject: Re: [TLS] TLS interim meeting material
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Sep 2018 15:34:14 -0000

I'm afraid the below is a strawman hypothetical.  Please stop.

DNSSEC lookups either return the truth or explicitly
*FAIL*, they don't just return "neutral" results.

As, for example, explained in RFC7672, when TLSA lookups fail the
mail delivery is deferred, and may ultimately bounce if the condition
persists beyond the message queue lifetime.

The same is repeated in RFC7673:

   https://tools.ietf.org/html/rfc7673#section-3.4

   o  If the TLSA response is "bogus" or "indeterminate" (or the lookup
      fails for reasons other than no records), then the client MUST NOT
      connect to the target server (the client can still use other SRV
      targets).

Indeed in RFC6698 (base DANE specification) the state machine in Appendix B.2
is:

  https://tools.ietf.org/html/rfc6698#appendix-B.2

   (TLSArecords, ValState) = DNSSECValidatedLookup(
     domainname=_[port]._[transport].[name], RRtype=TLSA)

   // check for states that would change processing
   if (ValState == BOGUS) {
     Finish(ABORT_TLS)
   }
   if ((ValState == INDETERMINATE) or (ValState == INSECURE)) {
     Finish(NO_TLSA)
   }
   // if here, ValState must be SECURE

   ...

> On Sep 14, 2018, at 11:18 AM, Richard Barnes <rlb@ipv.sx> wrote:
> 
> One other bit of context here: DANE itself doesn't prevent these "downgrade" attacks in its native form, to say nothing of TLS.

This is simply false.

-- 
	Viktor.