HPKE (draft-irtf-cfrg-hpke) support for ESNI
Categories
(NSS :: Libraries, enhancement, P2)
Tracking
(Not tracked)
People
(Reporter: kjacobs, Assigned: kjacobs)
References
Details
Attachments
(1 file)
The latest ESNI draft [0] relies on HPKE [1] to create the encrypted CH. This bug tracks implementation of the latter.
[0] https://tools.ietf.org/html/draft-ietf-tls-esni-06
[1] https://tools.ietf.org/html/draft-irtf-cfrg-hpke-02
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 1•5 years ago
|
||
I've started an implementation of this in cryptohi which would use individual PK11 functions, mechanisms, and keys as necessary (similar to the TLS13 key scheduling). It was brought to my attention that HACL* has an implementation that would push this down into freebl, at the cost of plumbing it through PK11 with custom mechanisms.
Bob, do you have a strong opinion on which path we take?
Comment 2•5 years ago
|
||
So it looks like HPKE is built on basic crypto primitives without directly accessing the underlying CSPs (that is you don' need to actually extract a key). PKCS #11 already has all the primitives it needs except the generic KEM interface. It might be worth exploring defining the KEM basic API for PKCS #11 (C_GenerateKeyPair () for GenerateKeyPair, maybe wrap/unwrap for Marshall, unmarshal, derive for encap/decap, etc), and mechanisms for KEM. I don't hink the entire HPKE should be pushed to the PKCS #11 layer.
Upshot, ideally we should pushd the KEM under PKCS #11. For now you can probably just implement a pk11wrap interface for KEM and we can look into pushing KEM lower at a later data. Probably implement HPKE at the pk11wrap layer itself because it's likely to have other users than tls.
bob
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 3•5 years ago
|
||
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 4•4 years ago
|
||
Description
•