IETF Logo Mail Archive

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

Eric Rescorla <ekr@rtfm.com> Sun, 04 March 2018 03:22 UTC

Return-Path: <ekr@rtfm.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 88E8A1200C1 for <tls@ietfa.amsl.com>; Sat, 3 Mar 2018 19:22:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 TOek6619sAy8 for <tls@ietfa.amsl.com>; Sat, 3 Mar 2018 19:22:35 -0800 (PST)
Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 920B712426E for <tls@ietf.org>; Sat, 3 Mar 2018 19:22:33 -0800 (PST)
Received: by mail-qt0-x236.google.com with SMTP id j4so16632707qth.8 for <tls@ietf.org>; Sat, 03 Mar 2018 19:22:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zhlFziHo2Ui8ei1ViNWQuvs19B6iNDwv+DszGKgxVCk=; b=JCFB2jCi/Xn2qV6UmLVqKARGzCJucamhKR8N2pU7B97PNH7DfjBBCvR9q+5kno217R t2IL1K9H1kpgzqJ/P9Tqfq/UCG7ybx95xW6l1oToKVUfqYQFu1bvv+UIQG60BcK8QfXt Q9cXO+TjCEgrmcaRmOKekdjRSeerOOidR1T1zAVhhLyFIZ0iAVsCXNfaJ0udB5PenMBz rW9iSijrceWECJigqQB6LPrUwYko0qcaB7XqoGjUz7HYNOThrWTZGMbAgS8kY5DekG+Q re7mmxZ/1JpLCJETaPJ21H+bEAoN8EhNLACURhGixFvK+c6T7tCE2JdFGfJc7KeE/TvK aqJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zhlFziHo2Ui8ei1ViNWQuvs19B6iNDwv+DszGKgxVCk=; b=fyaAZUTR0UEgEwV1J4Q7grI9NB+bo82aHUT3Byy6UIM35xTN6ZTBy+M9SY8u+9F9VL TS0sD2FN568oIHYV3+6/i368kmMWlrFA3zyij8OWVMJq5A/zYJieSw1zNvbfh+9tM5Qg aK7bShsBDdyX5HiN8FUBGsLtIvjnETgX/mN1mEdnuyOS5YCNJO4darJAQI7yLpxCIwIF UmaWBbnC8ytOg9gyg45Vru/YaHwIeY3mnAHXOkLxfiKr0XCmqAyBqCMvn7WUvvk0K9wP mSJ3YN3KjTFbvvj0g2qIs7ja4cyh3IMNogjK90s2kDA6TUE4sgxvVu5uzXYn5W/xipI6 51Gw==
X-Gm-Message-State: AElRT7G8THz37haELC2MPJ7JvyMy1FWohoFzXyalStKQ9WCeqgefmhhb GwtmwXKIjUffEJMM87TddWKeeWVsS0DO1IzkBDtK7g==
X-Google-Smtp-Source: AG47ELs/zxMSVJ63QWENEXqMTfdTj98vNPPnk3N5GFyxI7LVgMGGgncyVxFkTgJ0zyEYc3LZ3TClQ7hm9vlugriSKv4=
X-Received: by 10.200.7.77 with SMTP id k13mr16042556qth.165.1520133752649; Sat, 03 Mar 2018 19:22:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.37.176 with HTTP; Sat, 3 Mar 2018 19:21:52 -0800 (PST)
In-Reply-To: <alpine.LRH.2.21.1803032202100.15664@bofh.nohats.ca>
References: <CABcZeBOST2X0-MH2hhzpPJaUkbY++udsUV1bMnMhH2V2wQRPmA@mail.gmail.com> <CAHPuVdUs7mUJiqZjFjLDCNmHHGR9AP-g5YaLLbJj-zkDKd=_-w@mail.gmail.com> <alpine.LRH.2.21.1802211425260.7767@bofh.nohats.ca> <CAHPuVdX=_6b5g572-T-9Ccwek-WwL11KdTVwV9oNC9LaO5=0=Q@mail.gmail.com> <alpine.LRH.2.21.1802260913290.9977@bofh.nohats.ca> <70D42B5C-7FF9-49C1-95D4-13FDC611FF96@dukhovni.org> <CAHPuVdU8boBpYO3QutJgawH-54fKD+R9PaaT-5yWE+y2t+BwwA@mail.gmail.com> <CAHPuVdWhEnYxcLUzs-zbnKiN0zj+WO-7_cK2EobS1Gipurk7CQ@mail.gmail.com> <20180227233610.GD8921@localhost> <20180227233854.GE8921@localhost> <20180228200707.GF8921@localhost> <CAHPuVdUOZ1J+us4QfS+AedMvRzTGBRMGHvu5jpOdYr6mENGKXw@mail.gmail.com> <alpine.LRH.2.21.1803032202100.15664@bofh.nohats.ca>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 03 Mar 2018 19:21:52 -0800
Message-ID: <CABcZeBP0vzjU5Jf=ZL4WZY56=Lvnn5Ur4gcb3oCb5+M7_CFD-g@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Cc: Shumon Huque <shuque@gmail.com>, Viktor Dukhovni <viktor@dukhovni.org>, draft-ietf-tls-dnssec-chain-extension@ietf.org, tls-chairs <tls-chairs@ietf.org>, The IESG <iesg@ietf.org>, Nico Williams <nico@cryptonector.com>, TLS WG <tls@ietf.org>
Content-Type: multipart/alternative; boundary="f403043a8c74568f7a05668db867"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/CByPwY_JXankTNzkx8_WfqgAqSM>
Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
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: Sun, 04 Mar 2018 03:22:37 -0000

Hi folks,

This is way outside the range of my DISCUSS, so maybe we should change the
thread title.

Paul, can you walk me through the security value of a proof of nonexistence
here? Perhaps describe an attack that it stops.

-Ekr


On Sat, Mar 3, 2018 at 7:09 PM, Paul Wouters <paul@nohats.ca> wrote:

> On Thu, 1 Mar 2018, Shumon Huque wrote:
>
> I do not know if the draft authors and/or WG have an appetite to do the
>> much
>> more major change suggested by Viktor (i.e in-protocol pinning TTL
>> commitment
>> and requiring subsequent denial of existence proof if DANE is removed).
>>
>
> I think it is worth discussing in London and/or some people meeting up
> to talk about this and bring something to the list/WG.
>
> The original idea of this extension I believe (and one of my reasons
> behind writing RFC 7901) was to provide an alternative path for DNS
> that couldn't be blocked or broken and that provides DNS answers without
> additional latency. To me, that always included proof of non-existence,
> as it would come in as the answer to a DNS chain-query via TLS headers
> as the transport.
>
> I don't know why this got turned into something that is almost like DNS
> but not quite DNS. I think that is a mistake.
>
> The TLS extension should be nothing more (and nothing less) than
> stappled DNS suitable for a DNS routines.
>
> Paul
>
>

v2.23.0 | Report a Bug | By Email