Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

Eric Rescorla <ekr@rtfm.com> Thu, 12 April 2018 23:47 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 4B4DE126CBF for <tls@ietfa.amsl.com>; Thu, 12 Apr 2018 16:47:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 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, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 dv5IF88m43mL for <tls@ietfa.amsl.com>; Thu, 12 Apr 2018 16:47:51 -0700 (PDT)
Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (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 4D8D9124D6C for <tls@ietf.org>; Thu, 12 Apr 2018 16:47:51 -0700 (PDT)
Received: by mail-ot0-x22e.google.com with SMTP id d9-v6so7981085oth.10 for <tls@ietf.org>; Thu, 12 Apr 2018 16:47:51 -0700 (PDT)
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; bh=aIIyGqKSVL07bELv1qlABK4F4rSK68JETLz0dX9YklM=; b=oKRnSjuQJj3V9eoGPXaoaeiE0tZWCFPg5V8b621KEKuKWXp8ozW/XT+IA/iBq3ydEf qfvfVgBt4k5r2Ns/QuCFstINoT7u8sv/14yIpmqbUzR5rsrUDdAWsKeJ/Oo0E/hRQzUd sf1udyAzHr3xaYFOsgo0ug6KSAf6KLka/OtOSOjb+lTkGBGInm1hxP8zKBegz9DSCJW0 +ca54A8GcL+kea9kJPYrqhwy+1vtrAvTwcYw/n8YzMeW/VjqoZPzV2Viv7xLFCl5okqR VrA6uaqlFYZjzG98nCkfX6PY20iSulbjvy3wUuZ+pGAzw+wWgSDvws1sBuAFAxUQN4iv PX/w==
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; bh=aIIyGqKSVL07bELv1qlABK4F4rSK68JETLz0dX9YklM=; b=WHL7h3xIvSY8CvsOYjlTbQIk43aUo6yt8Q7zCwkkVyxU5VgDy8uL73LVWcPvA8njOv cwltmDieyjtPZ/Dh9dG3jx7b3/8ltWW4BINfRPXk0BIVLOGw4vzFEhBsIc+JWDMnfHtl NduH8QH45Z+ojYLcZNZlz+gz9UNr7SMuxuTDVvvMwt0v28e5d+sPWFy0rOPmVADxnmcl NdnfmA1sMLaY8EbDjNFNdtZNElDJA65yDjtZEeKYqQ5Vcay9FC5/djgXO/rP/FVuFop8 ZZ/OZZJDlIAoUGuZSFu7tqGWrjv4Olxj8IkvG5dSr0NYsUTDJlKCWnGxYNopjRgL/GQW /YDw==
X-Gm-Message-State: ALQs6tCs81WOHBTXbichugtIhSaRnYQ3kS2Mhib1UKL1ovlaV65Sx4nQ qur9gX0RrAtxP0V1G4vJxmXQmuiCUoCh/HJrnJrch5fi
X-Google-Smtp-Source: AIpwx4+4MHXWcWgrWxrE1dTonGL9mW1bkn6ZgYTvpsHQhcqFQ7Dq/jO8xpDGXTq1Q5dLef5pXPn4iedphBTvz/2hVTQ=
X-Received: by 2002:a9d:5919:: with SMTP id t25-v6mr2120791oth.217.1523576870528; Thu, 12 Apr 2018 16:47:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.138.18.130 with HTTP; Thu, 12 Apr 2018 16:47:10 -0700 (PDT)
In-Reply-To: <702DDD4B-4609-476C-9BAA-6AA05978135F@dukhovni.org>
References: <CAOgPGoAhzEtxpW5mzmkf2kv3AcugNy0dAzhvpaqrTSuMSqWqfw@mail.gmail.com> <CAHPuVdXfVQ5ZYL+dTvFeTfOaz2NNPrqxvnWuqJkxu0aaKDF_Sg@mail.gmail.com> <20180410235321.GR25259@localhost> <20180411173348.GP17433@akamai.com> <alpine.LRH.2.21.1804120438460.24369@bofh.nohats.ca> <CAL02cgSuTOaT_NwnpXaa8DPhNJhzqZwepRL+J29BzcBfCTDtHw@mail.gmail.com> <CAHbuEH78KNyk8fnHThRkCERKPjZzYppi1uhkDx6kL_t448q0_g@mail.gmail.com> <20180412175441.GD20782@akamai.com> <6db83a59-1f0f-f552-0d48-6e2a8d43f602@nomountain.net> <CABkgnnUwOjkY1_KejV-YOw3YRqjFfzaYurEY1OpZ8phQVhcWLg@mail.gmail.com> <114FE78D-F340-4752-BEF0-459FE1548A80@dukhovni.org> <aa7ca33a-4acd-c770-a43c-df7a1f66c782@nlnetlabs.nl> <E3918F11-9AD7-4C06-9173-5175ECACD16B@dukhovni.org> <CABcZeBP6-7_NNmC+7iVnNXbQw7p3jJH4eC1-EjY4C4CwdWWNcg@mail.gmail.com> <702DDD4B-4609-476C-9BAA-6AA05978135F@dukhovni.org>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 12 Apr 2018 16:47:10 -0700
Message-ID: <CABcZeBPJY1tsnCTYFbLoFSUX8pdVE7ZCi-+7kWsZkx8vwR_0YA@mail.gmail.com>
To: TLS WG <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000027fd6f0569af62fa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/lN9OhdiwfZ5avJ7KLva8lJX0Cg4>
Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
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: Thu, 12 Apr 2018 23:47:53 -0000

On Thu, Apr 12, 2018 at 4:14 PM, Viktor Dukhovni <ietf-dane@dukhovni.org>
wrote:

>
>
> > On Apr 12, 2018, at 7:10 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> >
> > The difficulty here is what the server knows about the clients behavior.
> > Specifically, if the server serves TLSA records and then ceases doing
> > without serving authenticated denial of existence, then it is unable to
> > determine if this would cause clients to fail because it doesn't know if
> > the client implements the text in the final paragraph. One could argue
> > that current clients could pin, but that's totally extratextual, as
> opposed
> > t having a noninteroperable behavior in the document.
>
> How exactly does telling the client the truth (conveying correct
> DNS state about the TLSA records) harm interoperability???
>
> Please explain the scenario in which something now fails???
>

I already did this in my previous email, but I'll try again.

In the current document, there is no expectation that clients will pin the
server's use of TLSA and therefore the server can safely stop using
TLSA (or run a mixed server farm). However, because this text implies
that the client *could* pin, in order to ensure interoperability the server
would have to provide authenticated denial at the risk of connection
failure with such clients. However the text also does not require that
the server do so. Thus, a conformant client and a conformant server
can fail if the server just stops using TLSA.

-Ekr


> --
>         Viktor.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>