[secdir] Secdir last call review of draft-ietf-ohai-ohttp-05
Alexey Melnikov <alexey.melnikov@isode.com> Thu, 08 December 2022 14:02 UTC
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09639C1526F0; Thu, 8 Dec 2022 06:02:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y_x7sAyCNIro; Thu, 8 Dec 2022 06:02:17 -0800 (PST)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 18182C1526F2; Thu, 8 Dec 2022 06:02:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1670508135; d=isode.com; s=june2016; i=@isode.com; bh=VmTT1aKdAIJjdVUTll7PKtb3qikQOR+ANmoLAkZ4fMY=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=NbGykID7G+f3dDXG/RyMhgNEHW5s5y5em/55n8huKFPsmL0qp79RDF4I4BJwFjqF8qI917 VU0/xd+Pr9KMumfwexQECPyFsgRTRzOeVxtkrF9CwizbDOj6eOxE5eYxiUtwjcHTVEpQf3 9hQAhrq2YxmBuOFZIc411ge4l7I/l/M=;
Received: from [192.168.1.222] (host31-49-219-67.range31-49.btcentralplus.com [31.49.219.67]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <Y5HuZgBS6KwP@waldorf.isode.com>; Thu, 8 Dec 2022 14:02:15 +0000
Message-ID: <d303c4e3-ca0f-4915-4240-8ecf96ef01cc@isode.com>
Date: Thu, 08 Dec 2022 14:02:14 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.3.2
From: Alexey Melnikov <alexey.melnikov@isode.com>
To: secdir@ietf.org, draft-ietf-ohai-ohttp@ietf.org
Cc: last-call@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/KR0DyhrodGdX68k3gSHBiKeoOYc>
Subject: [secdir] Secdir last call review of draft-ietf-ohai-ohttp-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2022 14:02:21 -0000
Reviewer: Alexey Melnikov Review result: Ready with nits Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This is a well written document and it was a pleasure to read. The Security and Privacy Considerations sections are extensive, and trust relationships between actors are clearly explained. Some nits/comments: It looks that the term "server" sometimes means the target server and sometimes the Oblivious Gateway. I think this creates a bit of confusion when reading the document. |4.4. Encapsulation of Responses | | Given an HPKE context context, a request message request, and a I wish the document used a convention for variables/fields to make reading of paragraphs like this a bit easier. Maybe put them in quotes? | response response, servers generate an Encapsulated Response | enc_response as follows: | | 1. Export a secret secret from context, using the string "message/ | bhttp response" as context. The length of this secret is max(Nn, | Nk), where Nn and Nk are the length of AEAD key and nonce | associated with context. Note: Section 4.6 discusses how | alternative message formats might use a different context value. 6.7. Post-Compromise Security This design does not provide post-compromise security for responses. A Client only needs to retain keying material that might be used Nit: "to" missing after "used"? compromise the confidentiality and integrity of a response until that response is consumed, so there is negligible risk associated with a Client compromise. In Section 7: Client privacy depends on having each configuration used by many other Clients. It is critical prevent the use of unique Client Nit: I think "to" is missing before "prevent" configurations, which might be used to track of individual Clients, but it is also important to avoid creating small groupings of Clients that might weaken privacy protections. The following comment is with my Media Type reviewer hat on and it applies to all 3 section 9.1, 9.2 and 9.3. Using section 9.3 as an example: 9.3. message/ohttp-res Media Type The "message/ohttp-res" identifies an encrypted binary HTTP response. This is a binary format that is defined in Section 4.4. The above should be included into the "Applications that use this media type" field of the registration template, as it helps to distinguish 3 nearly identical Media Type registration requests, if one only sees the extracted IANA registration templates and not this document. Type name: message Subtype name: ohttp-res Required parameters: N/A Optional parameters: None Encoding considerations: only "8bit" or "binary" is permitted You can't limit which encodings are used in a registration. As the format is binary, you should just include a single choice "binary" here. Security considerations: see Section 6 Interoperability considerations: N/A Published specification: this specification Applications that use this media type: Oblivious HTTP and applications that use Oblivious HTTP Best regards, Alexey
- [secdir] Secdir last call review of draft-ietf-oh… Alexey Melnikov
- Re: [secdir] Secdir last call review of draft-iet… Martin Thomson