[TLS] TLS interim meeting material

Paul Wouters <paul@nohats.ca> Wed, 12 September 2018 21:40 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 E7DE0130EA9 for <tls@ietfa.amsl.com>; Wed, 12 Sep 2018 14:40:13 -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 GJLEjBdbx_lr for <tls@ietfa.amsl.com>; Wed, 12 Sep 2018 14:40:11 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.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 67806130DFA for <tls@ietf.org>; Wed, 12 Sep 2018 14:40:11 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 429ZvF0GRrz9qD for <tls@ietf.org>; Wed, 12 Sep 2018 23:40:09 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1536788409; bh=AoZhJ2AolQVPFv0FsGw1D8Hi6xkkltiplQyw/1nmw60=; h=Date:From:To:Subject; b=h9OT4tw1WQkNdBu1J9hG8KzIfrob9nX70yI6B2i5fxC/vys65C5TsVe/BH+EJ2hek dfceteaOyFiMY/zJXe2AQ+Q+efs2ulVxOamRBb5xqw0fkyUsnQadI1bYVzPPoyx3lK OGvQ8sPNTS3CSuX4nfhBA780nqEazgRiYESTxfnw=
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 YZJOwkofAByb for <tls@ietf.org>; Wed, 12 Sep 2018 23:40:07 +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 for <tls@ietf.org>; Wed, 12 Sep 2018 23:40:06 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 4AEBD940; Wed, 12 Sep 2018 17:40:05 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 4AEBD940
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 44F5240BEF3A for <tls@ietf.org>; Wed, 12 Sep 2018 17:40:05 -0400 (EDT)
Date: Wed, 12 Sep 2018 17:40:05 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: tls@ietf.org
Message-ID: <alpine.LRH.2.21.1809121721300.5141@bofh.nohats.ca>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/dYa42nkRuthn9ISS2rO31jZGxJk>
Subject: [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: Wed, 12 Sep 2018 21:40:15 -0000

Hi,

We have made available what we believe is a good starting point for
further discussion regarding tls-dnssec-chain draft.

While I thought we had reached some additional consensus in a side
meeting at IETF 102 that every use case was per definition restrictive,
and that thus downgrade protection was mandatory for this document,
not everyone then present still seems to agree with that.

Nevertheless, we included the text we believe should go into the document.

We can further discuss the preventing of downgrade attacks at the
meeting if people have better ideas or _specific_ concerns about our
current approach.

Paul, Viktor and Nico


Repository https://github.com/vdukhovni/dnssec-chain-extension/tree/for-interim

Diff Commits:
https://github.com/tlswg/dnssec-chain-extension/compare/0664d5a608bc2cd82967370160fd4b837dba8fab...vdukhovni:for-interim

The following changes were drafted

* Mandatory Denial of Existence (DoE) or TLSA data (no empty extension data)
   This prevents a downgrade attack and gives a method to "clear pinning")

* Add two byte SupportLifetime to the extension and define the behaviour
   of TLS client and TLS server with respect to this extension. This
   prevents downgrade attacks.

* Explain that receiving validated DoE data implies setting SupportLifetime to 0
   (AKA it "clears the pin")

* Describe how to phase out using the TLS extension without causing problems

* Mandate use of SNI

* Added port information to the extension_data to support TLS servers
   behind NAPT that cannot determine the original port of the origin
   based on the received packet.

* Do not mandate DNS record ordering, it is complicated with CNAME/DNAME
   (the reverse order would actually make more sense for implementors)

* Describe behaviour when a TLS server receives an SNI it does not expect
   (and has no extension data for)

* Describe that TLS clients can obtain TLSA data directly from DNS or
   via this extension and that TLS clients can omit the extension
   completely if they have a non-expired cached TLSA RRset already.

* Clarify TLS servers don't need to do DNS queries themselves, but can
   depend on an external process to get fresh DNS data for populating
   the extension.

Still to do:

* Describe the interaction of TLSA records with CNAME and DNAME as a
   TLSA record can have a CNAME/DNAME at the beginning of the chain or
   at the end. (RFC7671 CNAME chasing does not work well)

* Provisioning TLSA chains with virtual hosting and cname constraints
   (eg domain owner points to Hoster's webfarm via CNAME)