Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

Ilari Liusvaara <ilariliusvaara@welho.com> Thu, 05 April 2018 09:35 UTC

Return-Path: <ilariliusvaara@welho.com>
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 098501270A7 for <tls@ietfa.amsl.com>; Thu, 5 Apr 2018 02:35:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 38lPoRlUWVbO for <tls@ietfa.amsl.com>; Thu, 5 Apr 2018 02:35:41 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF11812702E for <tls@ietf.org>; Thu, 5 Apr 2018 02:35:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 453B546F98 for <tls@ietf.org>; Thu, 5 Apr 2018 12:35:39 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id JL79wsnr8G4w for <tls@ietf.org>; Thu, 5 Apr 2018 12:35:38 +0300 (EEST)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 8915D73 for <tls@ietf.org>; Thu, 5 Apr 2018 12:35:37 +0300 (EEST)
Date: Thu, 05 Apr 2018 12:35:37 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: TLS WG <tls@ietf.org>
Message-ID: <20180405093537.GA22690@LK-Perkele-VII>
References: <CAOgPGoAhzEtxpW5mzmkf2kv3AcugNy0dAzhvpaqrTSuMSqWqfw@mail.gmail.com> <D04D5EAA-8A05-4D4E-97F8-36CE2DD9F3EE@dukhovni.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <D04D5EAA-8A05-4D4E-97F8-36CE2DD9F3EE@dukhovni.org>
User-Agent: Mutt/1.9.4 (2018-02-28)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/PbXNPH9y3NiMc3SFZ8bsMpbD-Z4>
Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 05 Apr 2018 09:35:44 -0000

On Thu, Apr 05, 2018 at 02:46:12AM -0400, Viktor Dukhovni wrote:
> 
> 
> > On Apr 4, 2018, at 1:50 PM, Joseph Salowey <joe@salowey.net> wrote:
> > 
> > A) Recommendation of adding denial of existence proofs in the chain provided by the extension
> > B) Adding signaling to require the use of this extension for a period of time (Pinning with TTL)
> > C) Both
> 
> Therefore, the real choice before us is (C) or not (C), the choices of (A) alone or (B)
> alone are unsound half-measures.

I agree that both (A) and (B) are bad idea, while (C) is sound idea.
 
> (C) is essentially STS for dane chains over TLS with downgrade protection after first
> contact, and imposes no burden on the present implementors.  If they were willing to
> implement without a pin or denial of existence, they can ignore the pin TTL and never
> transmit denial of existence (which their clients would not expect to process).

If one wants to save bandwidth in "cancel pin" case, one could add
a flag into request that tells the server if it should transmit DoE
or not (if it has actual chain, that should be transmitted anyway).

That way, the cancel would only need to be transmitted once to each
client, instead of potentially multiple times, and clients that do
not support pinning would not waste downstream bandwidth downloading
cancels they would ignore anyway.


-Ilari