Re: [Cfrg] Review of draft-irtf-cfrg-hpke-02

John Mattsson <> Wed, 18 December 2019 14:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7506A120020 for <>; Wed, 18 Dec 2019 06:21:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cLDmVrsSUu_C for <>; Wed, 18 Dec 2019 06:21:02 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 856B312007A for <>; Wed, 18 Dec 2019 06:21:02 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=Gv6j5oiYmef+KOQbapZWRWKnhlS50qy3sHT+BU6adP8B+3dxrQRtANqrN26QzeqvTAsov3fyZRlg6KPPBvWaYSWfLTvOPyDZrFYOeO9eqPbBf8D5iXXi/NUhyFKVH8duDJb8MmQI2AO6iDBDoc7CcW3CI5KnKmUpFRXULuXMwyUpWODEvcV+GCx5p+M26C1qEdEx3Ssv9qeYxamgbdE0wpc2xJzzbsQewWSEe+v8xCn3GqnQuh5RL5eDu/muSMqrDpYGLccRtrTkaR8/ez4XOfNVeGpS4QZ5BkAiZSBvFNG9MvgEjSpatyaDVzDULN8PRvgXbfNROJ1A7XWUFO5RGw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=G0tWYahoN4mTDtj5egpxoPYSKFKbadNMC58lggWsSkw=; b=Qd+q55DXHDS5H5g6kO1naBT4RmRngAZV8wWg3OCtGAIuO8LaL4G7tgrsZOIHxRGgkES2k8CSE7XSnDFJN79H/vc6SGbkiLdExkkGzXb0F5gZMbLAkYNjtNVMn6Xc1FsF/D54HPmDWrDqOftM955yekH60EedGF9JLH1lfVuoGjzRMgKFziFRF95/lzVPvE5ph6p8Q7py3sp0d5zMVEGVpgTfv2f0z/LyrhvMKbCZGEbAEntkwnbJTIZJLvGfzQSZYoU4gmIqrzhbfV9lAhVcPTtQ6xNNZnatxdRYtRlUBLpOz39fB52G7mrubfy8mml4omvZsRqmOLdP0fpbxiH6IA==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=G0tWYahoN4mTDtj5egpxoPYSKFKbadNMC58lggWsSkw=; b=cUc7wkkZHBHum5sLjEQ3/lAvf8287y5O6k9mYk4s1EiXQ85xOzOQp/VWvBkBe9NykFoRA+d7NNV4xv+CuXfX6rQMrz4mw0aT0D2Km2/2Og7loWcjoSXUvQH6PKe207z+51/682j8WpFWsfrvA5KnRbY5tywJSWLHRLx4Dt2TXrY=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.8; Wed, 18 Dec 2019 14:20:59 +0000
Received: from ([fe80::1986:9afa:b0a0:5636]) by ([fe80::1986:9afa:b0a0:5636%7]) with mapi id 15.20.2559.012; Wed, 18 Dec 2019 14:20:59 +0000
From: John Mattsson <>
To: Stephen Farrell <>, "" <>
CC: "" <>
Thread-Topic: [Cfrg] Review of draft-irtf-cfrg-hpke-02
Thread-Index: AQHVtaZ+ubaWbeS2ekONZfcHJDIjk6e/5fcAgAAcPIA=
Date: Wed, 18 Dec 2019 14:20:59 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-GB
user-agent: Microsoft-MacOutlook/10.1f.0.191110
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d0e341ea-ba06-4025-41f5-08d783c58169
x-ms-traffictypediagnostic: HE1PR07MB3084:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0255DF69B9
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(366004)(376002)(346002)(396003)(199004)(189003)(13464003)(6486002)(86362001)(66946007)(66476007)(64756008)(66556008)(4326008)(5660300002)(2616005)(44832011)(6512007)(186003)(6506007)(66446008)(91956017)(76116006)(26005)(2906002)(53546011)(966005)(71200400001)(36756003)(33656002)(110136005)(81156014)(8676002)(8936002)(478600001)(81166006)(296002)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3084;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: JomJHqSZ0oD+Xx61FGQjNaTW6XqFqZ8qRlUFJ7j3Ip9EYQevXFeNDmcSCW4jItzkHvCNoFZlT2BX1VSTUzbCdpbNrrH1FuphiX9Dbq1R4rq3FqsM5nJeLBhhXeqS1YqogrSQxrjnL1iRXjPF89CUoNl4k1J2ouFQ0QM+u/iBhd8NWXkFxAinYuNNIvK/0q6ahoh305sBTkOo7k/s8gpbbVcm8DiDA7402zG6K99TD06hE3ZVdUCtBNvGnuhc3J095DRLEylpagbovHhkG3HDk9lh07B1Q67qUmMtXfIWoQOj0xlpi5VglWBoQQRH4lM5nNCj1ksj3kB+DQND33KhyHPXQrQ5wIfg70qFao5FBoZW+LRzRk9+nc4omCdpwrbucH/cVZ8lBU9bLfJXeOb4Oml81qYyaGceC2aUxYHZSy86URCWA6UCveLCKL7fZpmepDRJPDBf8gJbxFLe0qr/xnehAgxfuIxR+IVHWmLuUok93q0jwuvvSttMMZ0Vu29cMK6+Xtewg460/ugSe1Gud4ZvlipX4xIbOGjLWn7v/qs=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d0e341ea-ba06-4025-41f5-08d783c58169
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2019 14:20:59.7970 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 0h5DW1/w9Is6l+xMifVzRSD/0HEJxvYx7uqaoSOI5x7waBGcM6e7xQzwHTs+2AQunSg0aBgRZ9Z3z848FaNJXQgh2FVpeG5yl5AcZ6tVMog=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3084
Archived-At: <>
Subject: Re: [Cfrg] Review of draft-irtf-cfrg-hpke-02
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Dec 2019 14:21:07 -0000


Stephen Farrell wrote:

>"Urgh. Why do we always need to define every possible option even though there's no real demand?

While TLS 1.2 definitely have too many cipher suites, I think some recent specifications like RFC 8032 have hardcoded too much. Having an IANA registry with specification required  and some well-chosen initial values is a good approach.

>We (CFRG) could punt on this by using existing IETF IANA registries instead of creating new ones. 

I also like the idea to reuse IANA registries more. I made a similar comment regarding draft-ietf-emu-aka-pfs a month ago. There are for example many IANA registries for groups/curves. I really like the new TLS IANA registry with specification requires and a Recommended column that requires Standards Action.

>result in the hpke RFC having only one MUST implement kem, kdf and aead.

Does HPKE currently have any MUST implement kem, kdf and aead? And should it have? My picture of the future HPKE RFC is that is a framework where nothing is mandatory to implement and where the IETF protocol using HPKE defines a mode and algorithms that are mandatory-to-implement. A RECOMMENDED mode and set of algorithms would however be good, and maybe text stating that implementations are not expected to support them all.


-----Original Message-----
From: Cfrg <> on behalf of Stephen Farrell <>
Date: Wednesday, 18 December 2019 at 14:40
To: John Mattsson <>rg>, "" <>
Cc: "" <>
Subject: Re: [Cfrg] Review of draft-irtf-cfrg-hpke-02

    On 18/12/2019 13:24, John Mattsson wrote:
    > The PR looks good. 
    Assuming you mean [1]...
    Since I didn't get a substantive response on the list,
    I'll repeat:
    "Urgh. Why do we always need to define every possible
    option even though there's no real demand? There are
    already far too many combinations of modes and suites
    in hpke."
    Having more or less finished my implementation now, I
    feel more strongly that additional combinatoric mess
    is a bad plan. Removing options/simplifying would be
    far better.
    We (CFRG) could punt on this by using existing IETF
    IANA registries instead of creating new ones. There is
    an almost fine match between what we need and some
    existing registries (if one squints just a little;-)
    that'd remove all this wrangling from our plate and
    that could result in the hpke RFC having only one MUST
    implement kem, kdf and aead. Additional options could
    then be haggled over in the IETF each time someone
    claims a need before subsequently being ignored by
    almost all implementers and an even higher proportion
    of deployments;-)