[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, 08 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
- [TLS] Interim notes and draft-ietf-tls-dnssec-cha… Christopher Wood
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Tom Ritter
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Viktor Dukhovni
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Nico Williams
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Daniel Kahn Gillmor
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Viktor Dukhovni
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… John Levine
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Benjamin Kaduk
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Viktor Dukhovni
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Paul Wouters
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Viktor Dukhovni
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Eric Rescorla
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Benjamin Kaduk
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Sean Turner
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Viktor Dukhovni
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Eric Rescorla
- Re: [TLS] Interim notes and draft-ietf-tls-dnssec… Benjamin Kaduk