Re: [CFRG] Spencer Dawkins' No Objection on draft-irtf-cfrg-hpke-09: (with COMMENT)

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Mon, 05 July 2021 22:53 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513863A091D; Mon, 5 Jul 2021 15:53:42 -0700 (PDT)
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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 PDETntpyysdB; Mon, 5 Jul 2021 15:53:37 -0700 (PDT)
Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (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 481313A091C; Mon, 5 Jul 2021 15:53:37 -0700 (PDT)
Received: by mail-yb1-xb31.google.com with SMTP id g5so31290556ybu.10; Mon, 05 Jul 2021 15:53:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7SSeyrG1CQw5FuJTxVzqFYUNfQT8gyrqnuOpZ0GxqWg=; b=TmCwP79tTPXA7wN3/Ge+nJWTuRJXCS4hIiHsCiEG0X6sF28957/Ivtg4nURcU/Stsj 02ZAwqc+uxB3OE/+NPnzOGuEPIATQteteJ3WzOO3l8L826JpfQ1nfaHM28IdrqimATMQ JQejQtRIP4P1AvcMzL6GT0puDfESVusL1vIEDcCJZnEZlD7MWMy/drwYVuhtCIDRRLZU //3BQ0zopjGGE29gW4lc7sxD40o0QGUDGFQAr4O2DkZPP0xSjXsk89G3WU2G7Ra5dBF2 HSS7daqZO5ZuPjK/OhFliG9r4E8PlI8S34uFmBhOd6QCLOqdyLYUv7qGDrMZIninR2OJ zCGQ==
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=7SSeyrG1CQw5FuJTxVzqFYUNfQT8gyrqnuOpZ0GxqWg=; b=ifzSiCeFAnlZp/EeBUWWz75xr6LKCsw6HaFVSp2yEeowSTZovNgCuZ7y2VhERhGbL2 2j7mgIu7vPAn1u7iDDnbjFe3rnoGPYHL21tSgRBx15LaixWm1lZFvzW/cEHJCmzdAeI5 e/Z1UXYgKjJkMQabrknnZvbQsr1yumRjNyljdOHZIpOXeDvR6Ia2OJZBP09/Q1uHGWD2 QxLfI1zXdxPi5gki8nMlA+vx0Hs8R5IlOuEcDe+zsC600mlaMnzeG80xBaR4Yox1Yg/i uXdPD6SxGiSgljH6bEFcLeW/GKdF8OR1TMAt+YAUiFe7wSL6LpgBt6muKjApwUsTlEXc UHyA==
X-Gm-Message-State: AOAM533sA/FKpMcZCR9CxW2pdmq4dcapvrvzoCufzJYlZHTaQGYq/t1F k/c5mVfv/1dR9SUXDxpaAaP8mPyyrxYINQTIydE=
X-Google-Smtp-Source: ABdhPJwWQPjdMYPtpvTNffuVcesm2pFSRYclUCSvj+OOzpyxt9SahXn1+C2H9ta4wYVy9MuAPK/Pk8Tn21G9jYCK154=
X-Received: by 2002:a05:6902:1106:: with SMTP id o6mr20036929ybu.380.1625525615707; Mon, 05 Jul 2021 15:53:35 -0700 (PDT)
MIME-Version: 1.0
References: <162403552387.29040.7069216010328580026@ietfa.amsl.com> <e15afc2b-4a41-42ca-a564-1d1162dab128@www.fastmail.com>
In-Reply-To: <e15afc2b-4a41-42ca-a564-1d1162dab128@www.fastmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Mon, 5 Jul 2021 17:53:09 -0500
Message-ID: <CAKKJt-eN3aaAcpQu19JDa5syLsd7s391UgMo45WcwgNwjdyEag@mail.gmail.com>
To: Christopher Wood <caw@heapingbits.net>
Cc: The IRSG <irsg@irtf.org>, draft-irtf-cfrg-hpke@ietf.org, cfrg-chairs@ietf.org, cfrg@ietf.org, "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000e5cb6a05c6682cde"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/Ov54pmAMw26pYOzjsxwRE1QBdlY>
Subject: Re: [CFRG] Spencer Dawkins' No Objection on draft-irtf-cfrg-hpke-09: (with COMMENT)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Jul 2021 22:53:43 -0000

Hi, Christopher,

On Tue, Jun 29, 2021 at 7:59 AM Christopher Wood <caw@heapingbits.net>
wrote:

> Thanks, Spencer! I wrote the following PR to address these comments:
>
>    https://github.com/cfrg/draft-irtf-cfrg-hpke/pull/230


These changes look fine to me. Thank you for considering my comments.

Best,

Spencer


> Best,
> Chris
>
> On Fri, Jun 18, 2021, at 9:58 AM, Spencer Dawkins via Datatracker wrote:
> > Spencer Dawkins has entered the following ballot position for
> > draft-irtf-cfrg-hpke-09: No Objection
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-irtf-cfrg-hpke/
> >
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > This isn't even remotely a topic I'm smart about, but the document was
> clearly
> > written, and I can imagine using it as an implementer. I do have some
> nits, so
> > please Do The Right Thing.
> >
> > At the bottom of Section 5, this sentence, "The procedures described in
> this
> > session are laid out in a Python-like pseudocode", and that's the only
> > occurence of "session" in the document. I don't know what "this session"
> is
> > intended to refer to - I can guess, but I'd be guessing. Is it something
> like
> > "in the following *sections*"?
> >
> > In this text, "This assurance is based on the assumption that
> AuthDecap(enc,
> > skR, pkS) produces the correct KEM shared secret only if the
> encapsulated value
> > enc was produced by AuthEncap(pkR, skS), where skS is the private key
> > corresponding to pkS", is "assumption" the right word? "Assumption"
> makes me
> > look for some mention of evidence that would support that assumption, but
> > reading further, I'm led to believe that this is a fundamental property,
> not an
> > assumption.
> >
> > In this text, "In many cases, applications encrypt only a single message
> to a
> > recipient's public key", is "to the recipient's public key" the right
> way to
> > say this? I was guessing this meant "In many cases, applications encrypt
> only a
> > single message using a recipient's public key"
> >
> > In this text, "The precise likelihood of DeriveKeyPair() failing with
> > DeriveKeyPairError depends on the group being used, but it is negligibly
> small
> > in all cases", is there any obvious action that an implementer could
> take if
> > this DOES happen?
> >
> > I wonder if Section 7.1.5. KEM Key Reuse should appear in the security
> > considerations section, or perhaps even just be mentioned there, with a
> > reference to its current location. Perhaps even in Section 9.2? But just
> having
> > this appear in Section 7 without a mention in Section 9 seems
> counterintuitive.
> >
> > Hmmm. Section 5.3 says this: “Applications that do not use the
> encryption API
> > in Section 5.2 can use the export-only AEAD ID 0xFFFF when computing the
> key
> > schedule. Such applications can avoid computing the key and base_nonce
> values
> > in the key schedule, as they are not used by the Export interface
> described
> > above”, but Section 7.3 says “The 0xFFFF AEAD ID is reserved for
> applications
> > which only use the Export interface; see Section 5.3 for more details”.
> Would
> > saying “Applications that do not use the encryption API in Section 5.2
> can use
> > the export-only AEAD ID 0xFFFF when computing the key schedule” in
> Section 7.3
> > be accurate? If so, it would be more obvious that these two statements
> apply in
> > the same conditions if they use the same phrasing.
> >
> > I may be going blind (and that would be a pity, since I had cataract
> surgery
> > earlier this year), but I can’t see the difference between what’s said
> about
> > DHKEM in
> >
> > Extract() and Expand() (in DHKEM): Extract() can be modeled as a random
> oracle.
> > Expand() can be modeled as a pseudorandom function, wherein the first
> argument
> > is the key.
> >
> > and what’s said about “elsewhere” in
> >
> > Extract() and Expand() (elsewhere): Extract() can be modeled as a random
> > oracle. Expand() can be modeled as a pseudorandom function, wherein the
> first
> > argument is the key.
> >
> > Is there a difference? I see text in Section 9.5 that looks like it
> might be
> > related, but I just don’t have the background to know for sure.
> >
> > In 11.1. KEM Identifiers, “The "HPKE KEM Identifiers" registry lists
> > identifiers for key encapsulation algorithms defined for use with HPKE.
> These
> > are two-byte values, so the maximum possible value is 0xFFFF = 65535”,
> These
> > “might” be clearer as “These identifiers” (same comment in 11.2 and
> 11.3).
>