Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT)

Shumon Huque <shuque@gmail.com> Thu, 22 February 2018 15:59 UTC

Return-Path: <shuque@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 228AC12D7F4; Thu, 22 Feb 2018 07:59:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 d9AyWW0p3TbD; Thu, 22 Feb 2018 07:59:57 -0800 (PST)
Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 6666512741D; Thu, 22 Feb 2018 07:59:57 -0800 (PST)
Received: by mail-io0-x230.google.com with SMTP id e7so6525773ioj.1; Thu, 22 Feb 2018 07:59:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nTa68OWoQSWYpfv8028TFTTK/3MJzzzeMYCV4NHAcgs=; b=obpSab7A8/I3Sgn9IgN97uyfzGfoj5rzjsyWQ4RSGEHueAvBnyKfd+0y8e2csE/bZ2 YA7WE0I64xlkC22outMFlooDn5adW9SgtBw7l/2IjqLnUJ4JXwPrm+bCXOwXUOoirwoS Na2Usn3cvJLSNAXfuf3pICOjfc5dm7eafLlCZyEfMmvbNhM6qcyTDIPy96kBPakLFIM9 JUxPO2ZmyPBdYJKw94s50esEwLfXETabGkhyHsGycEjnpfLzIIyNTL0kFlVECBwuQ9qp SJZq8ggabfSQQPGRKzi95p0KuG0xbTcjz2r+mpzTgviBDeaPBQloUPyibh0qkEpUQ8BB s15A==
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=nTa68OWoQSWYpfv8028TFTTK/3MJzzzeMYCV4NHAcgs=; b=jT7t0RurGXMtSxi2W+2Fia9hFGg9SK73TuUsvgydnIEMd48t4XNRMoV6n2VZ/4jnM2 v1+/GgA/DnaoMGtup+dGwQwGpuHyJWKiBSff1oz0FrHL5VoiuWX0RyBgHA+cuFDsCH61 6LpnPC1rx5/r5+aFnEDeKxEIucg0kawdf+cPQXG5TCVEhkN0Dm2vZwq91Bz+6qiDXcOc xS2MHsQHQatiN2QpilSM0cofHiw0rH73A/yfBGKkb3O2xOJ+HyDz3KrRymhffRxULf+d WWp0zP5roJEBhuZkv7UAg4XH1VUJx9uGE09kxppGT08Yv/tRJUc7uqmwfS0UXqfaK+AT g6ng==
X-Gm-Message-State: APf1xPBR22cDKRkimelBPCB274sAjFlOlxVGmjjPAyz9Ks1nILon924N bg2N3uXKSHIqhVIKTINUBla971WN1iVPQVpWYqw=
X-Google-Smtp-Source: AG47ELsO30tqzVfgaBVpGEPHM8QvYjnxtA9Gtcxg98NUK81ees5UYnk99uZ2aQVXD546j106parevYzlY/kdPwyPh+0=
X-Received: by 10.107.137.104 with SMTP id l101mr9337839iod.179.1519315196730; Thu, 22 Feb 2018 07:59:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.79.201.198 with HTTP; Thu, 22 Feb 2018 07:59:56 -0800 (PST)
In-Reply-To: <0FA4B497-4B9A-421B-A9A6-2FEB62D3E41A@dukhovni.org>
References: <151800968634.4877.12510609339415982154.idtracker@ietfa.amsl.com> <CAHPuVdWO1LqNBK_f4xxcgP5PLQGDw1OMJiymf3jWXSDftP07+A@mail.gmail.com> <4c90bb83-5ba1-8193-df67-38e25f76caf8@nlnetlabs.nl> <CAHPuVdUVrzwNZDYktnztxuWQ-6yt+vT1aU76D1mL9rm3N3PJFw@mail.gmail.com> <CAHbuEH7aoiBK3vbH77Qdmiu6+ULS5VyefNydpkwM6MV=SmHdEA@mail.gmail.com> <CABkgnnXk7GNSHDZexSrryF6bepG3Zu5FZi6Nzi+gFxbh39-saw@mail.gmail.com> <CAHPuVdXW3avaLVOcsBJXU+P0-Ow+60mKbs1OjLswBZdAAEFNzA@mail.gmail.com> <0FA4B497-4B9A-421B-A9A6-2FEB62D3E41A@dukhovni.org>
From: Shumon Huque <shuque@gmail.com>
Date: Thu, 22 Feb 2018 10:59:56 -0500
Message-ID: <CAHPuVdX_0Df29d7E+cQEmyOa==y41tJZAqT1e7ck_q5ca9RJmg@mail.gmail.com>
To: Viktor Dukhovni <viktor@dukhovni.org>
Cc: TLS WG <tls@ietf.org>, tls-chairs <tls-chairs@ietf.org>, draft-ietf-tls-dnssec-chain-extension@ietf.org, The IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="001a113eb1349a85440565cf22ca"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/EIYA63zGNwOVGCGvNRJLvWIwGw8>
Subject: Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-dnssec-chain-extension-06: (with 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: Thu, 22 Feb 2018 15:59:59 -0000

On Wed, Feb 21, 2018 at 1:49 PM, Viktor Dukhovni <viktor@dukhovni.org>
wrote:

>
>
> > On Feb 21, 2018, at 11:00 AM, Shumon Huque <shuque@gmail.com> wrote:
> >
> > On Tue, Feb 13, 2018 at 5:50 PM, Martin Thomson <
> martin.thomson@gmail.com> wrote:
> > On Wed, Feb 14, 2018 at 4:07 AM, Kathleen Moriarty
> > <kathleen.moriarty.ietf@gmail.com> wrote:
> > > What's the behavior when the middlebox is a proxy, let's say existing
> > > a managed network?  I presume from from section 3.1 that this
> > > negotiation doesn't work in that instance unless sites configured for
> > > this are not subject to the proxy as is often done for financial site
> > > access from corporate networks.  It would be good to know if it does
> > > work and that is addressed with the text Mirja calls out for her #1
> > > question.  Having this clarified could be helpful.
> >
> > If there is a MitM, then this extension simply isn't negotiated.
> > That's pretty well understood.  I don't see why that requires special
> > mention.
> >
> > Yeah, I agree Martin .. this is the same as with any other extension.
>
> Actually, I don't think it is quite the same.


I meant same in the sense that if any extension is blocked then it
can't be used. What the effect of that is depends obviously on what
functionality the extension is providing. The TLS client can at least detect
such blocking/stripping, and alert the application or fallback to something
else.

Have other TLS extension specs gone into the details of middlebox
impacts?


>   This extension may
> be naïvely expected to provide a different peer authentication
> mechanism than the traditional WebPKI.  Users who might expect this
> extension to protect them from WebPKI compromise via DANE TLSA
> records, need to understand that such protection only exists when
> DANE is enforced (mandatory) by the client.
>
> The absence of DANE TLSA records, which is downgrade-resistant
> when the client has access to DNSSEC authenticated denial of
> existence (makes its own DNSSEC lookups) is no longer downgrade-
> resistant when delivered via this extension if the client
> is willing to accept just WebPKI in the (apparent) absence of DANE
> TLSA records.
>

Some of this is already discussed or at least implicit in the draft.
If you want to propose specific text to add or modify, please do so ..

Shumon.