Re: Opsdir last call review of draft-ietf-httpbis-expect-ct-07
Emily Stark <estark@google.com> Tue, 30 October 2018 17:50 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C60127333 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 30 Oct 2018 10:50:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.252
X-Spam-Level:
X-Spam-Status: No, score=-10.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 g6RSbeVtG0XK for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 30 Oct 2018 10:50:18 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42391130D7A for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 30 Oct 2018 10:50:17 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1gHY74-0004Lt-4N for ietf-http-wg-dist@listhub.w3.org; Tue, 30 Oct 2018 17:47:34 +0000
Resent-Date: Tue, 30 Oct 2018 17:47:34 +0000
Resent-Message-Id: <E1gHY74-0004Lt-4N@frink.w3.org>
Received: from titan.w3.org ([2603:400a:ffff:804:801e:34:0:4c]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <estark@google.com>) id 1gHY72-0004L5-5J for ietf-http-wg@listhub.w3.org; Tue, 30 Oct 2018 17:47:32 +0000
Received: from mail-yb1-xb2e.google.com ([2607:f8b0:4864:20::b2e]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <estark@google.com>) id 1gHY70-0001QU-7W for ietf-http-wg@w3.org; Tue, 30 Oct 2018 17:47:31 +0000
Received: by mail-yb1-xb2e.google.com with SMTP id 131-v6so5398153ybe.12 for <ietf-http-wg@w3.org>; Tue, 30 Oct 2018 10:47:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M/0IP+J1/oJ5EfWH15g/0pghyux8ZN5QyvpWJM2zhkI=; b=Dem6sSAjX4v9PvftElwS//aoFCaVWHadqfiwG44FdcOoyU6yJcX65joaIzuqvgzyyS 9N0mHpBNo9DpKV5JV8rjREyn2VPzxbaEqjKwOjOdRgPxUPE+nh8T6y07papvdAOY05F/ Ag0M6Qxe0xnQ+gaxnsEXQp01K4Q5hR6LlbHKSBmsnGEIcCf6UdBGzk7xqxCjG1MKNXwN aeYpubhgO7B6/TXS3qJb4gRjAXJpIu5sf5sJOCp3j31eJyT7TPqKlVENoXnUDSYZVlD3 6MMBXlddW3wQtjG+Xwt8mU+zsRk9OfBR4qY8us60Z4sz8/ydt5H2raX0rNf5OVmExOo8 TWCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=M/0IP+J1/oJ5EfWH15g/0pghyux8ZN5QyvpWJM2zhkI=; b=OZoEqd5avAspkSe0e/sWOLHk5UUbMoxPmKJOlq05wxNLwefsKdGW+JRcnM4ZO6tUoP lb95zR5F7IL0EjmhHa1QE76WdTv12Krj5701I/+9bghDx6HNWX/ZzpOUR5V5pXx9C2pW Ovsfp2lzYDVoprQplggTybowHrRrxFDnjo76MWN+sGw8zemm5/a0PK0+Oj3P/rfx6voq jJ5u8NRPDOM1DPDDzeNsJ8h46c4E+tc30SGqSD8c77mCYobixyrtGIo8wovbxz/m5OeK XCFhMdI2FXyYIzpBP7Im9/4tGnzhbSeODVYTNFWFWIe1hog6TLJwmjgIRJAtlAuZBdBz Ctvw==
X-Gm-Message-State: AGRZ1gLlr8XR0lLjmhUcwqqETV7LX4x7xOnNLF3bOo7kqxY7l8bZ+x1q QtolrYXC9w9nI3/aQmRiT00aubcrLji9agBBSyy/EQ==
X-Google-Smtp-Source: AJdET5d5JrfvxrFMsHzLEIcokEMwqSXlGjfn3gKwB/sh4cbX04pUoPQfyblBfR3w85eCBeICMAu7EDpcz9NfKPrBb+s=
X-Received: by 2002:a25:1385:: with SMTP id 127-v6mr19099332ybt.368.1540921628657; Tue, 30 Oct 2018 10:47:08 -0700 (PDT)
MIME-Version: 1.0
References: <153370878002.2230.9699894334788236121@ietfa.amsl.com>
In-Reply-To: <153370878002.2230.9699894334788236121@ietfa.amsl.com>
From: Emily Stark <estark@google.com>
Date: Tue, 30 Oct 2018 10:46:56 -0700
Message-ID: <CAPP_2SauzEn5+sggg51Drj13S+xK=qv9c6o77TsUUWJ584iJ9A@mail.gmail.com>
To: bill.wu@huawei.com
Cc: ops-dir@ietf.org, draft-ietf-httpbis-expect-ct.all@ietf.org, ietf@ietf.org, httpbis <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="0000000000004e030e057975c681"
X-W3C-Hub-Spam-Status: No, score=-21.5
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1gHY70-0001QU-7W a8e7e4cdf07311ad19e9bea956f8d7ad
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Opsdir last call review of draft-ietf-httpbis-expect-ct-07
Archived-At: <https://www.w3.org/mid/CAPP_2SauzEn5+sggg51Drj13S+xK=qv9c6o77TsUUWJ584iJ9A@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36003
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Thanks for the comments! I've addressed these in https://github.com/httpwg/http-extensions/commit/50c233544c746ed826b9b2b778ace17e0b65f66b, with some replies inline. On Tue, Aug 7, 2018 at 11:13 PM Qin Wu <bill.wu@huawei.com> wrote: > Reviewer: Qin Wu > Review result: Ready > > I have reviewed this document as part of the Operational directorate's > ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written with the intent of improving the operational aspects > of > the IETF drafts. Comments that are not addressed in last call may be > included > in AD reviews during the IESG review. Document editors and WG chairs > should > treat these comments just like any other last call comments. > > This document defines"Expect-CT" response header field. It can be used by > server to indicate that UAs should evaluate connections to the host > emitting > the header field for CT compliance. I believe this document is ready for > publication. However I have a few comments which I like authors of this > document can consider: 1.Section 1, Introduction,3 paragraph said: "Web > host > operators are > advised to deploy Expect-CT with caution, by using the reporting > feature and gradually increasing the interval where the UA remembers > the host as a Known Expect-CT Host. > " > To consistent with the next sentence in paragraph 3, s/caution/precautions > I believe this interval is related to max-age, if the answer is yes, I > would > suggest to change interval into waiting time or hold on time, in addition, > change remembers into regards > > 2.Section 2.1 Expected-CT field syntax > Not sure Response header field name should use upper case. > I'm not sure what this is referring to -- the only capitalized bit I see is the section name, which is capitalized like all the other section names. > > 3.Section 2.1.2 said: > "When both the "enforce" directive and "report-uri" directive > (as defined in Figure 2) are present, the configuration is referred > to as an "enforce-and-report" configuration" > > Section 3, failure-mode said: > " > o "failure-mode": the value indicates whether the Expect-CT report > was triggered by an Expect-CT policy in enforce or report-only > mode. The value is provided as a string. The UA MUST set this > value to "enforce" if the Expect-CT metadata indicates an > "enforce" configuration, and "report-only" otherwise. > " > I am wondering how these two quoted text related to each other? Why > failure-mode doesn't support enforce-and-report mode? "enforce-and-report" mode is implicit when a report is sent with "failure-mode" set to "enforce"; if it were enforce only mode without reporting, a report wouldn't be sent. > 4.Section 3.1 s/reporting > server/report server 5.Section 4.1 Section 4.1 said UA experience denials > of > service. Section 7 said: " 7. Usability Considerations > > When the UA detects a Known Expect-CT Host in violation of the UA's > CT Policy, users will experience denials of service. It is advisable > for UAs to explain the reason why. > > " > Section 5 last paragraph said: > "Because Expect-CT causes remotely-detectable behavior, it's advisable > that UAs offer a way for privacy-sensitive users to clear currently > noted Expect-CT hosts, and allow users to query the current state of > Known Expect-CT Hosts. > " > I am wondering who experience denials of service, who are users referred in > section 7? Expect-CT hosts or report server? Who are privacy-sensitive > users in > section 5? UA? From where can the user query the current state of Known > Expect-CT Hosts? Report server or Server? Does this document define > mechanism > which allow user to get access to the current state of known expected-ct > hosts? > > 6. Section 7 said: > " > It is advisable for UAs to explain the reason why. > " > Explain the reason why to who? Web client or webserver? If it is the > latter,Isn’t violation report defined in section 3.2 and 3.3 doing this > job? If > it is former,does this introduce security risk? > "Users" is meant to refer to end users in these sentences, so I've clarified that in the text. It's advised that the user can query the current state of Known Expect-CT Hosts via the UA, e.g. the UA provides a debugging or configuration functionality where the user can view the hosts that the UA has noted as Known Expect-CT Hosts, but the document doesn't define the exact mechanism for how this is done.