[prev in list] [next in list] [prev in thread] [next in thread]
List: cfrg
Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-hpke-00.txt
From: Frederic Jacobs <lists () fredericjacobs ! com>
Date: 2019-08-13 13:40:58
Message-ID: 3DD2D2CE-C7D6-4256-9F8B-B6CD70CAFC0C () fredericjacobs ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hello Richard,
I read it over the weekend and had the following feedback.
Typos:
- Double "the": "The the shared secret produced by the KEM is combined via the KDF \
with information describing the key exchange, as well as the explicit info parameter \
provided by the caller."
- I assume this was supposed to be "authenticated": Authentication Encryption with \
Associated Data (AEAD) Functions
Technical feedback:
- I've noticed that in a previous draft, you had ciphersuites defined that are no \
longer in this version of the document. However, you still refer to a ciphersuite \
identifier in the context octet string definition: context = concat(mode, \
ciphersuite, enc, pkRm, pkIm, len(pskID), pskID, len(info), info)
I assume this becomes the concatenation of the KEM, KDF, Cipher 2-byte values?
- Some of the example use-cases are examples where the size of the payloads should be \
minimal. With some standards (eg. 3GPP), the use of NIST-curves is very important. \
For those cases, could the compact key representation \
<https://tools.ietf.org/id/draft-jivsov-ecc-compact-05.html> be considered?
- About the info string, in a previous document it was defined as opaque \
info<0..255>, which now has been changed to opaque info<0..2^16-1>. While I think \
being able to take longer info, I'm not sure why it's meant to persist like that in \
the HPKContext and from an implementation perspective, having a variable-length info \
buffer complicates things (eg. specifying length in octet string). \
Implementation-wise I think that just taking an arbitrary info argument and hashing \
it using the hash function underpinning the key derivation function (or eventually \
just KDF'ing it) to Nh bytes would make more sense and simplify edge cases in \
implementation.
- As it currently stands, the RFC doesn't define a wire format for the payloads. \
While I think that leaving that possibility is important for adoption in different \
use cases, it could be useful to define a standard way of concatenating for instance \
the enc || encryptedPayload and have that in the spec. Optionally defining \
Elligator-style encoding of the enc to make HPKE payloads less distinguishable.
It's great to (finally!) see an RFC on interoperable ECIES implementations.
Best,
Frederic
> On 4 Jul 2019, at 13:28, Richard Barnes <rlb@ipv.sx> wrote:
>
> Hi folks,
>
> After our presentation in Prague and an adoption call on this mailing list, I'm \
> happy to say that we have posted draft-irtf-cfrg-hpke-00.
> This version has a couple of notable changes from the last individual draft:
>
> - The "setup" logic across the various modes has been united into a single \
> algorithm
> - As a result, we added a "PSK + Auth" mode, where the sender is authenticated to \
> hold both a PSK and an asymmetric key
> - Instead of one monolithic ciphersuite, individual algorithms are signaled \
> independently
> In addition, there were a bunch of clarifications and bugfixes thanks to Dave \
> Cridland.
> We've asked the chairs for some time to discuss this draft in Montreal, so please \
> take a look and let us know what you think!
> Thanks,
> --Richard
>
> On Thu, Jul 4, 2019 at 6:09 AM <internet-drafts@ietf.org \
> <mailto:internet-drafts@ietf.org>> wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Crypto Forum RG of the IRTF.
>
> Title : Hybrid Public Key Encryption
> Authors : Richard L. Barnes
> Karthik Bhargavan
> Filename : draft-irtf-cfrg-hpke-00.txt
> Pages : 17
> Date : 2019-07-03
>
> Abstract:
> This document describes a scheme for hybrid public-key encryption
> (HPKE). This scheme provides authenticated public key encryption of
> arbitrary-sized plaintexts for a recipient public key. HPKE works
> for any combination of an asymmetric key encapsulation mechanism
> (KEM), key derivation function (KDF), and authenticated encryption
> with additional data (AEAD) encryption function. We provide
> instantiations of the scheme using widely-used and efficient
> primitives.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-irtf-cfrg-hpke/ \
> <https://datatracker.ietf.org/doc/draft-irtf-cfrg-hpke/>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-irtf-cfrg-hpke-00 \
> <https://tools.ietf.org/html/draft-irtf-cfrg-hpke-00> \
> https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hpke-00 \
> <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hpke-00>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org \
> <http://tools.ietf.org/>.
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org <mailto:Cfrg@irtf.org>
> https://www.irtf.org/mailman/listinfo/cfrg \
> <https://www.irtf.org/mailman/listinfo/cfrg> \
> _______________________________________________ Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
[Attachment #5 (unknown)]
<html><head><meta http-equiv="Content-Type" content="text/html; \
charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; \
line-break: after-white-space;" class="">Hello Richard,<div class=""><br \
class=""></div><div class="">I read it over the weekend and had the following \
feedback.</div><div class=""><br class=""></div><div class=""><b \
class="">Typos:</b></div><div class="">- Double "the": "<b class="">The \
the</b> shared secret produced by the KEM is combined via the KDF with \
information describing the key exchange, as well as the \
explicit info parameter provided by the caller."</div><div class="">- I \
assume this was supposed to be "authenticated": <b class="">Authentication \
Encryption</b> with Associated Data (AEAD) Functions</div><div class=""><br \
class=""></div><div class=""><b class="">Technical feedback:</b></div><div class="">- \
I've noticed that in a previous draft, you had <i \
class="">ciphersuites</i> defined that are no longer in this version of the \
document. However, you still refer to a ciphersuite identifier in the context octet \
string definition:</div><div class=""><pre class="newpage" style="margin-top: 0px; \
margin-bottom: 0px; break-before: page; caret-color: rgb(0, 0, 0); color: rgb(0, 0, \
0);"> context = concat(mode, ciphersuite, enc, pkRm, pkIm, len(pskID), pskID, \
len(info), info)</pre></div><div class="">I assume this becomes the concatenation of \
the KEM, KDF, Cipher 2-byte values?</div><div class=""><br class=""></div><div \
class="">- Some of the example use-cases are examples where the size of the <i \
class="">payloads should be minimal</i>. With some standards (eg. 3GPP), the use of \
NIST-curves is very important. For those cases, could the <a \
href="https://tools.ietf.org/id/draft-jivsov-ecc-compact-05.html" class="">compact \
key representation</a> be considered?</div><div class=""><br class=""></div><div \
class="">- About the <i class="">info</i> string, in a previous document it \
was defined as <span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" \
class="">opaque info<0..255>, which now has been changed to </span><font \
color="#000000" class="">opaque info<0..2^16-1>. While I think being able to \
take longer info, I'm not sure why it's meant to persist like that in the HPKContext \
and from an implementation perspective, having a variable-length info buffer \
complicates things (eg. specifying length in octet string). Implementation-wise I \
think that just taking an arbitrary info argument and hashing it using the hash \
function underpinning the key derivation function (or eventually just KDF'ing it) to \
Nh bytes would make more sense and simplify edge cases in \
implementation.</font></div><div class=""><font color="#000000" class=""><br \
class=""></font></div><div class=""><font color="#000000" class="">- As it \
currently stands, the RFC doesn't define a <i class="">wire \
format</i> for the payloads. While I think that leaving that possibility is \
important for adoption in different use cases, it could be useful to define a \
standard way of concatenating for instance the enc || encryptedPayload and have \
that in the spec. Optionally defining Elligator-style encoding of the enc to \
make HPKE payloads less <span style="caret-color: rgb(0, 0, 0);" \
class="">distinguishable</span>.</font></div><div class=""><br class=""></div><div \
class=""><font color="#000000" class="">It's great to (finally!) see an RFC on \
interoperable ECIES implementations.</font></div><div class=""><font color="#000000" \
class=""><br class=""></font></div><div class=""><font color="#000000" \
class="">Best,</font></div><div class=""><font color="#000000" class=""><br \
class=""></font></div><div class=""><font color="#000000" \
class="">Frederic</font></div><div><br class=""><blockquote type="cite" class=""><div \
class="">On 4 Jul 2019, at 13:28, Richard Barnes <<a href="mailto:rlb@ipv.sx" \
class="">rlb@ipv.sx</a>> wrote:</div><br class="Apple-interchange-newline"><div \
class=""><div dir="ltr" class=""><div class="">Hi folks,</div><div class=""><br \
class=""></div><div class="">After our presentation in Prague and an adoption call on \
this mailing list, I'm happy to say that we have posted draft-irtf-cfrg-hpke-00. <br \
class=""></div><div class=""><br class=""></div><div class="">This version has a \
couple of notable changes from the last individual draft:</div><div class=""><br \
class=""></div><div class="">- The "setup" logic across the various modes has been \
united into a single algorithm</div><div class="">- As a result, we added a "PSK + \
Auth" mode, where the sender is authenticated to hold both a PSK and an asymmetric \
key</div><div class="">- Instead of one monolithic ciphersuite, individual algorithms \
are signaled independently</div><div class=""><br class=""></div><div class="">In \
addition, there were a bunch of clarifications and bugfixes thanks to Dave \
Cridland.</div><div class=""><br class=""></div><div class="">We've asked the chairs \
for some time to discuss this draft in Montreal, so please take a look and let us \
know what you think!</div><div class=""><br class=""></div><div \
class="">Thanks,</div><div class="">--Richard<br class=""></div></div><br \
class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 4, \
2019 at 6:09 AM <<a href="mailto:internet-drafts@ietf.org" \
class="">internet-drafts@ietf.org</a>> wrote:<br class=""></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><br class=""> A New Internet-Draft is available \
from the on-line Internet-Drafts directories.<br class=""> This draft is a work item \
of the Crypto Forum RG of the IRTF.<br class=""> <br class="">
Title : Hybrid \
Public Key Encryption<br class=""> Authors \
: Richard L. Barnes<br class=""> \
Karthik Bhargavan<br \
class=""> Filename : \
draft-irtf-cfrg-hpke-00.txt<br class=""> Pages \
: 17<br class=""> \
Date : 2019-07-03<br class=""> <br class="">
Abstract:<br class="">
This document describes a scheme for hybrid public-key encryption<br \
class=""> (HPKE). This scheme provides authenticated public key \
encryption of<br class=""> arbitrary-sized plaintexts for a recipient \
public key. HPKE works<br class=""> for any combination of an \
asymmetric key encapsulation mechanism<br class=""> (KEM), key \
derivation function (KDF), and authenticated encryption<br class=""> \
with additional data (AEAD) encryption function. We provide<br class=""> \
instantiations of the scheme using widely-used and efficient<br \
class=""> primitives.<br class="">
<br class="">
<br class="">
The IETF datatracker status page for this draft is:<br class="">
<a href="https://datatracker.ietf.org/doc/draft-irtf-cfrg-hpke/" rel="noreferrer" \
target="_blank" class="">https://datatracker.ietf.org/doc/draft-irtf-cfrg-hpke/</a><br \
class=""> <br class="">
There are also htmlized versions available at:<br class="">
<a href="https://tools.ietf.org/html/draft-irtf-cfrg-hpke-00" rel="noreferrer" \
target="_blank" class="">https://tools.ietf.org/html/draft-irtf-cfrg-hpke-00</a><br \
class=""> <a href="https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hpke-00" \
rel="noreferrer" target="_blank" \
class="">https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hpke-00</a><br \
class=""> <br class="">
<br class="">
Please note that it may take a couple of minutes from the time of submission<br \
class=""> until the htmlized version and diff are available at <a \
href="http://tools.ietf.org/" rel="noreferrer" target="_blank" \
class="">tools.ietf.org</a>.<br class=""> <br class="">
Internet-Drafts are also available by anonymous FTP at:<br class="">
<a href="ftp://ftp.ietf.org/internet-drafts/" rel="noreferrer" target="_blank" \
class="">ftp://ftp.ietf.org/internet-drafts/</a><br class=""> <br class="">
_______________________________________________<br class="">
Cfrg mailing list<br class="">
<a href="mailto:Cfrg@irtf.org" target="_blank" class="">Cfrg@irtf.org</a><br \
class=""> <a href="https://www.irtf.org/mailman/listinfo/cfrg" rel="noreferrer" \
target="_blank" class="">https://www.irtf.org/mailman/listinfo/cfrg</a><br class=""> \
</blockquote></div> _______________________________________________<br class="">Cfrg \
mailing list<br class=""><a href="mailto:Cfrg@irtf.org" class="">Cfrg@irtf.org</a><br \
class="">https://www.irtf.org/mailman/listinfo/cfrg<br \
class=""></div></blockquote></div><br class=""></body></html>
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic