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

Eric Rescorla <ekr@rtfm.com> Fri, 13 April 2018 04:51 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 81CE4126DFB for <tls@ietfa.amsl.com>; Thu, 12 Apr 2018 21:51:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 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] 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 wcTu5tdgO0lb for <tls@ietfa.amsl.com>; Thu, 12 Apr 2018 21:51:53 -0700 (PDT)
Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (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 83FAF124239 for <tls@ietf.org>; Thu, 12 Apr 2018 21:51:53 -0700 (PDT)
Received: by mail-ot0-x22a.google.com with SMTP id m22-v6so8536248otf.8 for <tls@ietf.org>; Thu, 12 Apr 2018 21:51:53 -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=QXWbvJdT4f+5hplBJ/9qbieVR8IvT5f/VZTbWwB2DJc=; b=tH7CImft/2JZDKyZ5uuklZdk3fmIJ6Qe5uYT2lkN1UkvIOF+A01jRNuUgbPgACTCXm oAsOVzxWlLf+nu0O8sLeteQHmctta/g6iPHiHNRcYmBfHDx1n7WdL5r+Ia9kNoh9tok1 ndYbiyAAvshub7JbP7qyeigH0oyNJjn2YxDobNWUm86oAqkwZcBd5TWWgLOBARO4suGk ea6fYsfzaaOG02xPP0BL+9AWPmkh4GTBWkeGSVCkpFft3x1o14ydk44jdVjlHjdBKbz3 VRtzUNMqHZzrdymJBjf/87Njznl8QWSC0Psv3sCYZqECZ3G/IvXilxVyTi7j+RdX/NeC 1p+A==
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=QXWbvJdT4f+5hplBJ/9qbieVR8IvT5f/VZTbWwB2DJc=; b=tlUw/+pHnsVHMlUH3QNFjnBmfonZqV/FNVASYM8op6K4CkrYfo42ThVCKsIUnaehp+ +w4ltNN7LYH6+Km0YuCowPE6vugDGjzRR/IXIEbdbMRXZEoII2wwt/pG/e/DnFzl+OGd fTdEVcrRB6IUtgb2AeOqzSCK1L4aRy8l+2SziI7iBMBWKgd7dayMkkfrqPtBrwcKH1v9 sLoYiw9y4lE7iDh80nx0Glc8O9JURZBSzK/Mqdz31wRb432xUd+qg+CPWGII7vuiJ/Jz 1p4gA30MyvkeB38apikcwmffGuBKKgBRCJSPrHf7Nt2fKd3rSvgcjGyzgSAKXEIMUtIV OGKQ==
X-Gm-Message-State: ALQs6tAW58aoON12G0v8Wtnj58S6DXW7AfrpRRX77KjWFR2kqHNQ+9sb pkWkAFcHzCReL4qjytvm9PqG1fIn7cVhKEsO9Q1lW90o
X-Google-Smtp-Source: AIpwx48dYqTerK5Nkay/iDpngG9eX2fiL92XMxI3lCRFxIwNae+7b/iGfj30hMzUMfrQBVmFaO3p3fl3a+sj4x3oBmw=
X-Received: by 2002:a9d:e06:: with SMTP id c6-v6mr2741885otc.371.1523595112539; Thu, 12 Apr 2018 21:51:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.138.18.130 with HTTP; Thu, 12 Apr 2018 21:51:12 -0700 (PDT)
In-Reply-To: <095DDF77-F2E6-4522-AFA1-B77710B1BC98@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> <CABcZeBPJY1tsnCTYFbLoFSUX8pdVE7ZCi-+7kWsZkx8vwR_0YA@mail.gmail.com> <57382E5B-3562-426F-8E1D-58E140296DBC@dukhovni.org> <a1e1258b-f002-f162-ba05-fd8b728ac2cd@nomountain.net> <095DDF77-F2E6-4522-AFA1-B77710B1BC98@dukhovni.org>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 12 Apr 2018 21:51:12 -0700
Message-ID: <CABcZeBO3koFfCE1Z=fK0oh8iKOeE8qinVbSvu0CfUaF-grogZw@mail.gmail.com>
To: TLS WG <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000076fd500569b3a10c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/tOpgJsvhwhrTNDRVcNNp5hOypxI>
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: Fri, 13 Apr 2018 04:51:56 -0000

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

>
> > On Apr 13, 2018, at 12:07 AM, Melinda Shore <
> melinda.shore@nomountain.net> wrote:
> >
> > I'm okay with putting denial-of-existence in there as a should,
> > but I do feel strongly that pinning belongs in a separate document.
> > As I  said earlier, I have a problem with putting features in protocols
> > that  nobody intends to use.  It's bad enough when it happens by
> > circumstance but doing it deliberately strikes me as a bad idea.
>
> The great irony of the situation, is that present draft already
> describes pinning:
>
>    If TLS applications want to mandate the use of this extension for
>    specific servers, clients could maintain a whitelist of sites where
>    the use of this extension is forced.  The client would refuse to
>    authenticate such servers if they failed to deliver this extension.
>
> And I've seen no discussion or working group consensus to *prohibit*
> such pinning, only observations that it would be rather fragile in
> general.
>

Thanks for pointing this out. I agree that this text is likely to cause
interop problems and should be removed or at least scoped out in
the case where client and server are unrelated. I regret that I didn't
catch it during my IESG review.

-Ekr