4 ms·
> HPKE is not tolerant of lost messages. [1] This seems a severe limitation for certain applications (e.g. VPNs) which tunnel traffic which already has an orde
by colanderman 2y ago
> HPKE is not tolerant of lost messages. [1]
This seems a severe limitation for certain applications (e.g. VPNs) which tunnel traffic which already has an ordering mechanism (such as TCP) [2]. This is not a limitation of, e.g., Noise [3], one of the existing hybrid protocols HPKE seems intended to replace.
[1] https://www.rfc-editor.org/rfc/rfc9180.html#name-message-order-and-message-l https://www.rfc-editor.org/rfc/rfc9180.html#name-message-ord...
[2] https://openvpn.net/faq/what-is-tcp-meltdown/ https://openvpn.net/faq/what-is-tcp-meltdown/
[3] https://noiseprotocol.org/noise.html#out-of-order-transport-messages https://noiseprotocol.org/noise.html#out-of-order-transport-...
- ramchip 2y agoHPKE is only comparable to the one-way handshake variants of Noise. For a VPN you'd want an interactive handshake to get forward secrecy on both sides, like Wireguard.
- ekr____ 2y agoThe way to think about HPKE is really as a primitive building block for use in other protocols, rather than as a protocol on its own. For example, in TLS Encrypted Client Hello (ECH) [0], the server publishes a public key which is then used by the client to encrypt the ClientHello message. That encryption is performed using HPKE. Similarly, MLS uses HPKE as part of its inner core. [0] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
- amluto 2y agoI wish the HPKE RFC had an introduction that clearly and concisely described what an HPKE is and what its API is. It took me a somewhat silly amount of reading to figure out what HPKE is, and I even hang out on the relevant mailing list.