Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

Paul Wouters <paul@nohats.ca> Tue, 03 July 2018 15:56 UTC

Return-Path: <paul@nohats.ca>
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 1C0B0130E66 for <tls@ietfa.amsl.com>; Tue, 3 Jul 2018 08:56:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 dx4atgdq2KjG for <tls@ietfa.amsl.com>; Tue, 3 Jul 2018 08:56:16 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C714130EAC for <tls@ietf.org>; Tue, 3 Jul 2018 08:56:10 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 41Kpd422R1zCqj; Tue, 3 Jul 2018 17:56:08 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1530633368; bh=Gunc9kZZIsxIz5exwq65EeO2N+tGbyGEqc6n6K311fo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=MqqLnIv/D/fqER46hOD0+cytrVIWhRw4gu6F63/mfN7qBBT5ZV3xl06tSN3QmURfy NdfixoH3atzXGddYLSvkP3nbFqvIgMx+RjcPOAa+0O9QYGnuInHlG9UPu1g9bhbxIh /KlNw4u2UyD/8KjtsryhNKiITe2cnm/Nk7HeACt8=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id SMSC3Shx0RnE; Tue, 3 Jul 2018 17:56:06 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 3 Jul 2018 17:56:05 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 0B3D43A3EC1; Tue, 3 Jul 2018 11:56:04 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 0B3D43A3EC1
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id F346A45755C1; Tue, 3 Jul 2018 11:56:04 -0400 (EDT)
Date: Tue, 3 Jul 2018 11:56:04 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Allison Mankin <allison.mankin@gmail.com>
cc: Joseph Salowey <joe@salowey.net>, "<tls@ietf.org>" <tls@ietf.org>, Benjamin Kaduk <bkaduk=40akamai.com@dmarc.ietf.org>
In-Reply-To: <CAP8yD=vdpdw3=_O5u_zPxVWiVTYj=CA+k-ZHNTyqkU+_KkH4CA@mail.gmail.com>
Message-ID: <alpine.LRH.2.21.1807031143370.7932@bofh.nohats.ca>
References: <CAP8yD=vdpdw3=_O5u_zPxVWiVTYj=CA+k-ZHNTyqkU+_KkH4CA@mail.gmail.com>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Iicb4NcXQZ2rw9kZ8c-sUm8kBko>
Subject: Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.26
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: Tue, 03 Jul 2018 15:56:19 -0000

On Tue, 3 Jul 2018, Allison Mankin wrote:

> 2.  Do you support the reserved bytes in the revision for a future pinning mechanism?
> 
> ​Reserving the bytes without a mechanism is not a good idea, so no.  I think the method for modifications or another approach is
> something to be worked on in future too.

Reserved bytes are always under specified, that is why they are reserved.

For instance, yesterdy ekr filed a draft for encrypted SNI with this:

 	 struct {
 	           uint8 checksum[4];
 	           KeyShareEntry keys<4..2^16-1>;
 	           CipherSuite cipher_suites<2..2^16-2>;
 	           uint16 padded_length;
 	           uint64 not_before;
 	           uint64 not_after;
 	           Extension extensions<0..2^16-1>;
 	       } ESNIKeys;

 	 extensions  A list of extensions that the client can take into
 	      consideration when generating a Client Hello message.  The format
 	      is defined in [I-D.ietf-tls-tls13]; Section 4.2.  The purpose of
 	      the field is to provide room for additional features in the
 	      future; this document does not define any extension.

So there is a whole extension block with no specification and no idea
even if it would ever be needed. That is much weaker then the need for
TLS extension pinning.

Additionally, let me remind you of the direction that the solution
would take if this is punted completely to a new document:

https://tools.ietf.org/html/draft-asmithee-tls-dnssec-downprot-00

The smithee draft is a terrible idea. We can do better.

Paul