Re: [TLS] access_administratively_disabled v2

Eric Rescorla <ekr@rtfm.com> Thu, 04 January 2018 14:46 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 120DF12D877 for <tls@ietfa.amsl.com>; Thu, 4 Jan 2018 06:46:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 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_LOW=-0.7] 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 QY-GylX7Vgr0 for <tls@ietfa.amsl.com>; Thu, 4 Jan 2018 06:46:52 -0800 (PST)
Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 D404212D86C for <tls@ietf.org>; Thu, 4 Jan 2018 06:46:51 -0800 (PST)
Received: by mail-yw0-x22c.google.com with SMTP id k80so650739ywe.0 for <tls@ietf.org>; Thu, 04 Jan 2018 06:46:51 -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=pP4SqxalqRvLwEffmugcQGuikbSdr+W36SOVi3SkQ8c=; b=xCRZL30Tt1qe4asi6yAVRL0ZvMs4eVvYZb6K9vkv9ZYQRgB4S+4z5ai5LpVuIf9sM5 26tZQOXSLOdrSrURHvkUFzu5Fd5f7cJ06fS4pkH2jwzWLiO80Wx7iHOlARQ1w2PaVg9P KGXIFc33kTayC8mb8mnxquBjaWj7R3j2TaXMUcW3NcrJ1MB1VXME8DvdY2KE9k3Dk/8e 1mrx3ho9P0Ev05+ZsWjz4zIGZjh2wt4Ovc7GK8SszLTeVXQj2t0Zso+0v7sETJkZFBR1 aMWpXVXqF002SRalZK12KXw4H2CqLW9q+ZgmvmeVAiYCw03yJtHK/5jqPKgIalxn54H5 70Ow==
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=pP4SqxalqRvLwEffmugcQGuikbSdr+W36SOVi3SkQ8c=; b=HSp7ZU2HPCtsk2VYKr9usBKiwuVYB4F4LySS/m9su0u/FF1x22F5TZF4qVCtbHMPtN KtecKYOjLwOKyGUiqbLYrT/9epbDY9Yiygyzb2hsU86C/ude5vhaMp46Wr/fWcbo8k0V tDyWvyDrnKinU33eVj67ygrbx/aQuflMtSSFUvyrCc+qwZgRA6waVARKt06PLMXPdaRJ WpIMGNdAvUJvdsBSDehaAETRXMQ9oUO4lbrtrewRENgWO/jhNNffm1ykCUWhURmyfLfw intiuW0c4Zv0/hbwHEqt4UGKVKHdMI6SXpB3kSL620xg4NSImhy4SmB6Tdffl5TdVQ0m nKPQ==
X-Gm-Message-State: AKGB3mJwSaJH4EpAo0IUCfKRsv+4tfvU501CUYg0FiP5AhFfU5Bfvbvk 9xQJsjANKZ1knQczprxkmhtEXeKaU/5cGjGy0v4M5++H
X-Google-Smtp-Source: ACJfBotJP7SHR4ISS87gYPiCjcMYKWPyc/jth7MBI4CB0CwBXJsnETofDq9Xs9Yay+sG88SUVUVAhpNpMwkSLiu2uv8=
X-Received: by 10.129.154.22 with SMTP id r22mr4238816ywg.296.1515077211024; Thu, 04 Jan 2018 06:46:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.123.132 with HTTP; Thu, 4 Jan 2018 06:46:10 -0800 (PST)
In-Reply-To: <466bac48-539e-a651-2edd-c8d4006c89fe@o2.pl>
References: <60555d44-340d-8aa7-eb45-3a23b758e5d2@o2.pl> <CABcZeBN=JHV3gY_JCkCUHHASEqcUQTUmmpRY5i66Dv53k=Z3Ag@mail.gmail.com> <3685a850-03ec-5162-414b-c2676022d661@o2.pl> <CABcZeBO0nzmfcA+1ujxceDtNKPGUBZQtBg4-yN-OpOSyEJ3bNg@mail.gmail.com> <eb4530ad-2e6e-d5b6-72e7-4f84dae635e3@o2.pl> <5afdbc7f-30bb-4de2-6a72-588b8edc55d8@akamai.com> <235782bf-c26b-12c4-391a-26b654a8b9af@o2.pl> <CABcZeBMtU41cuNw=JGVRe8=7GtAzCL1RsRnm3UKeNgBb5FFicw@mail.gmail.com> <466bac48-539e-a651-2edd-c8d4006c89fe@o2.pl>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 4 Jan 2018 06:46:10 -0800
Message-ID: <CABcZeBP2cuzVODdJRUg0TDaGws2QbHbk5a-gECLjT=eSsYNu6w@mail.gmail.com>
To: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= <mat.jonczyk@o2.pl>
Cc: Benjamin Kaduk <bkaduk@akamai.com>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0bb4e8f876d50561f4669e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/PVm3qjRZ8jse7xkBoYdtRCCreVQ>
Subject: Re: [TLS] access_administratively_disabled v2
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, 04 Jan 2018 14:46:54 -0000

On Thu, Jan 4, 2018 at 6:43 AM, Mateusz Jończyk <mat.jonczyk@o2.pl> wrote:

> W dniu 04.01.2018 o 15:22, Eric Rescorla pisze:
> >
> >
> > On Thu, Jan 4, 2018 at 2:46 AM, Mateusz Jończyk <mat.jonczyk@o2.pl
> > <mailto:mat.jonczyk@o2.pl>> wrote:
> >
> >     W dniu 03.01.2018 o 18:05, Benjamin Kaduk pisze:
> >     > On 01/03/2018 10:17 AM, Mateusz Jończyk wrote:
> >     >> Judging from TLS1.3's problems with middleboxes, content
> filtering isn't so
> >     >> rare, especially in the corporate world.
> >     >>
> >     >> The provider of filtering services (for example OpenDNS) /
> middlebox
> >     >> manufacturer would have to recognize if the client supports this
> mechanism.
> >     >> Having support for TLS1.3 could be one such flag.
> >     >
> >     > Cherry-picking this one part just for enhanced clarity: I do not
> think
> >     > support for TLS 1.3 can or should be such a flag -- there does not
> seem
> >     > sufficient reason to block TLS 1.3 finalization for this proposal.
> >
> >     I would like to ask You to add just this one flag:
> >     access_administratively_disabled to TLS 1.3. This will allow
> graceful upgrade to
> >     full proposed functionality of the access_administratively_disabled
> mechanism.
> >
> >
> > I am not in favor of this change at this time.
> >
> > I suspect I'm not in favor of the mechanism, but i'm definitely not in
> favor of
> > adding a placeholder alert for some mechanism which isn't specified.
> >
> OK, but what about this change considered separately? I have changed the
> semantics slightly:
>
> +access_denied_by_intermediary
> +: The access was denied by a network intermediary - i.e. a server other
> +  than the client or the desired server, for example by an Internet Sevice
> +  Provider.
>
> Justification:
>         Network intermediaries (for example ISPs) may block traffic by
> using
>         e.g. access_denied anyway. Make it more explicit by adding
>         access_denied_by_intermediary.
>
>         This will make censorship more transparent.
>

Sorry, no, I'm not persuaded. It's not clear to me that this is a benefit,
and certainly
not clear enough to merit a last minute change to 1.3.

-Ekr


> Greetings,
> Mateusz
>
>
> > -Ekr
> >
> >     I will try to submit an Internet Draft for the full mechanism till
> the end of
> >     this week.
> >
> >     Greetings,
> >     Mateusz Jończyk
> >
> >     >
> >     > -Ben
> >     >
> >
> >     _______________________________________________
> >     TLS mailing list
> >     TLS@ietf.org <mailto:TLS@ietf.org>
> >     https://www.ietf.org/mailman/listinfo/tls
> >     <https://www.ietf.org/mailman/listinfo/tls>
> >
> >
>
>