[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