[TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps

Christopher Wood <christopherwood07@gmail.com> Tue, 09 October 2018 00:09 UTC

Return-Path: <christopherwood07@gmail.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 E1779130FCE for <tls@ietfa.amsl.com>; Mon, 8 Oct 2018 17:09:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 1_G4xZi_LYSy for <tls@ietfa.amsl.com>; Mon, 8 Oct 2018 17:09:53 -0700 (PDT)
Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 509F0130FA2 for <tls@ietf.org>; Mon, 8 Oct 2018 17:09:53 -0700 (PDT)
Received: by mail-it1-x135.google.com with SMTP id w200-v6so139157itc.4 for <tls@ietf.org>; Mon, 08 Oct 2018 17:09:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Jgx9Ow148ZLbBZbCW5uX8zV0t+3jQdE+BZsVDRLYuDU=; b=vL5tsvbKLpVqasPeezIfiYqBbrfgRs/hzHxdhTjJJ3ru1djMWMXGYYwhaUVjOv6jS0 EWE2ZRnAvRyDQ+a4aLe03AZlJ9E9IY7eEsQlLUYGLiGTGisBFOoC/4mS2TC4ULpE0l/h 6fASAzvc10yiztMk5E/LTUoFylrIMPDlEj5z/U2KfQ0UwdQlwNG0opdI+FvzZImsmkvF 2Mafp6poU8d9YPi+nBzUuYvPepR4BWaaEIV1DDi8K36Qg8kCeKGHhu8xKNsx/CVI0+b3 9QddRKNt+lRnACCOlhgcAq7f8CYoMKkkfvFxrbOR0MxxTbDneF+zW+hIPT12TBeT0OXc hrVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Jgx9Ow148ZLbBZbCW5uX8zV0t+3jQdE+BZsVDRLYuDU=; b=QyD23dTYpflafq7RXeKZPELPcWXkf+Z3gI+G5puAXMou2Ay7o3eiNXulTNa/PScrRg Yd0LNvw3oOgy8dr2wvylXeBTTMPBclSdd0s3unMj6lUDEhznKrsb87fYimxylkMXmGDv Mcba/60vInmpQNhalRgKvMZf1NXBDJcmlmUergH9ZyLIANPSmMjizdsZqRFjzbcZK//w 5o7wgb0Y+ttfL9tCjwhlUJzSVoa6KXc7eJzK0DpH0QMOnIJuBG5c4ZeK7pgt9F+jeRJV 9Z6YU2pOsB3wakbLL9ms8el/Sw4By1EBl+BSZnsrg5joxm4VKEu/txZLPhA+e+jDnzel mZ2g==
X-Gm-Message-State: ABuFfojQAZbU5ykOAnzEYBELWL6WUd5lB5xxacGeBM1HTPtfJqgwNCoz iexZ4nPvc5oIPmhyQEhrHmPaAqd7pNS1qX4DjDRJrVjU
X-Google-Smtp-Source: ACcGV62DrgQaQSGerM9aR92r4B0gZSXpHTkWrlQky8t6MbqhqH++qo1GRelsAVLKla82XfJLVjvQZgZPHRJLxPs6lNk=
X-Received: by 2002:a24:4ac5:: with SMTP id k188-v6mr171080itb.158.1539043792113; Mon, 08 Oct 2018 17:09:52 -0700 (PDT)
MIME-Version: 1.0
From: Christopher Wood <christopherwood07@gmail.com>
Date: Mon, 8 Oct 2018 17:09:40 -0700
Message-ID: <CAO8oSXnv5Gpdw-0c9jXtx1rQqpgwmfrZyiFgHF=Kd5qWZSMPCA@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/9SuDj3gKZx8qTdEjR1U5qtkMd4Q>
Subject: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps
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: Tue, 09 Oct 2018 00:09:55 -0000

Notes from the TLS interim meeting held in September are now online
[1]. To recap, the meeting attempted to focus on three primary
questions:

1. What is the fundamental security issue? What is the purpose of this
extension?
2. Under what circumstances should DNS records received in the
extension be cached and reused for future use?
3. Is pinning required? If so, what is pinned, and at what layer(s)
should it be implemented?

Most of the time was spent on question #1. In an attempt to get to the
root cause of the disagreement amongst participants, we have since
attempted to go back to a clean  slate, gaining an understanding of
the "facts on the ground" that motivate a need for this extension and
how current technologies operate, and move forward from that common
understanding to reach a shared picture of a clear problem statement.
Once a clear problem statement is agreed upon, it should be easier to
analyze proposed solution(s) for whether they solve that problem
statement without introducing unacceptable risks into the broader
ecosystem.

To that end, here are some facts for which there seems to be consensus:

1. DANE provides two major use models. In the first model, it requires
that the server supply a certificate which would pass WebPKI
validation but must also have a CA certificate (usage 0) or EE
certificate (usage 1) which matches the TLSA record. In the second
model, the server may have a certificate or raw public key which need
not pass WebPKI validation, but either must chain to a certificate
which matches the TLSA record (usage 2) or must itself match the TLSA
record (usage 3). In the former model, the server operator still must
participate in the Web PKI, whereas in the latter model, it need not
do so.
2. Currently, DNSSEC failures are common in the last mile. Residential
routers and ISPs, might give out DNS resolvers that fail to deliver
(accurate) DNSSEC records. This makes delivery of DNSSEC (and TLSA)
records difficult. Thus, any client which must work in any network
environment cannot safely fail on DNSSEC failures (whether that
failure is overridable by the user or not) because that would result
in an unacceptable rate of failures. Further, clients have been
reluctant to implement even opportunistic use of DANE records because
of errors and latency concerns.
3. Certificate switching based on ClientHello contents is standard
practice, e.g., as is done for SNI-based certificate selection or for
servers which support multiple algorithms such as RSA and ECDSA. This
may also be used to monitor the deployment rate of this extension.

At risk of discussing a solution to the wrong (or a different)
problem, we should first settle the question about the purpose of this
draft. Once we settle on the problem(s) and determine if the proposal
adequately addresses it, we can then discuss technical details. In the
interest of moving things forward before Bangkok, we plan to timebox
these discussions as follows:

- October 8 through October 19: Discuss the problem statement. In
particular, if anyone feels the problem statement captured in the
draft introduction [2,3] or in the above "facts" is incorrect,
imprecise, or misleading, please say so, and say why (in a succinct
fashion). Questions regarding client pinning of the TLS extension, the
risks involved in doing so, and how server operators can recover from
pin DoS attacks are out of scope for this discussion.
- October 22 through November 2: Discuss the draft [2,3]. The chairs
will circulate a list of concrete questions to address before the
22nd.
- Bangkok: Discuss the draft [2,3] and open issues.
- After Bangkok: Call for consensus to continue iterating on the draft
as a WG item or abandon it, and proceed accordingly.

Best,
Chris, Joe, and Sean

[1] https://datatracker.ietf.org/doc/minutes-interim-2018-tls-01-201809141000/
[2] https://tools.ietf.org/html/draft-ietf-tls-dnssec-chain-extension-07
[3] https://github.com/vdukhovni/dnssec-chain-extension/tree/for-interim