Re: [CFRG] Fixing the multi-shot API of HPKE

[Dan Harkins <[e-mail]>]

   Hi Richard,

On 2/15/21 8:31 AM, Richard Barnes wrote:
> Hi Dan,
>
> HPKE is not intended to be a full network protocol; it is supposed to 
> be embedded in an application that assures properties such as those 
> you mention.  Section 8.6, "External Requirements / Non-Goals" [1] has 
> some text on this.  If you think we can be clearer in these 
> disclaimers, suggested text / PRs would be welcome.

   Right, it's designed to be a fairly low-level primitive. Section 8.6 is
describing the non-goals of HPKE. It's basically, "if you want this feature
you need to handle this on your own", which is perfectly understandable. No
need to be clearer there.

   But this is the other way around. This is an expectation that HPKE places
on any high-level protocol that might want to use it. It might be nice to
have a (sub-)section formally devoted to this instead of burying the
requirement in a discussion of how the sequence number is managed inside of
an opaque HPKE context where its importance could easily be missed.

   Actually since this is an external requirement, you could make the 
title of
8.6 just be "External Requirements", make the current content of 8.6 be a
sub-section 8.6.1 entitled "Non-Goals" and then make an 8.6.2 entitled
"Requirements on Upper-Layer Protocol" that says this requirement formally:

     A high-level protocol that uses HPKE's stateful API MUST provide
     for guaranteed in-order delivery of packets to ensure that all
     ciphertexts are presented to ContextR.Open() in the order in which
     they were generated by ContextS.Seal().

     A high-level protocol MUST be able to detect packet loss and to
     abandon any HPKE state that becomes unsynchronized as a result of
     unrecoverable packet loss. Any packet number a high-level protocol
     assigns to an HPKE message SHOULD be (part of) the AAD passed to
     ContextS.Seal() and ContextR.Open() and it is the responsibility of
     the high-level protocol to specify how that is accomplished.

     A high-level protocol SHOULD provide a means of re-establishing
     synchronized state in the event that contexts get hopelessly out
     of sync. If this feature is provided it MUST NOT open the protocol
     up to any additional attack-- that is, the only way an attacker can
     induce parties to resynchronize is by dropping packets or otherwise
     denying service.

Something along those lines but in your voice.

   But I still maintain that adding AES-SIV is the way to go :-)

   regards,

   Dan.

> --Richard
>
> [1] https://tools.ietf.org/html/draft-irtf-cfrg-hpke-07#section-8.6
>
>
> On Sat, Feb 13, 2021 at 7:29 AM Dan Harkins <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>
>        Hi Karthik,
>
>     On 2/13/21 3:10 AM, Karthikeyan Bhargavan wrote:
>     > Hi Dan,
>     >
>     > I don’t fully understand the problem you are alluding to.
>     >
>     >>     "It is up to the application to ensure that encryptions and
>     >>      decryptions are done in the proper sequence, so that
>     encryption
>     >>      and decryption nonces align.”
>     > The HPKE stateful API guarantees that nonces cannot be misused,
>     even if you use AES-GCM or Chacha-Poly. (Of course, you could also
>     add a SIV ciphersuite.)
>     > Furthermore, it guarantees that the stream of plaintext messages
>     received by the decryptor is a prefix of the stream of plaintext
>     messages sent by the encryptor.
>
>        It's not an issue of misuse, it's an issue of the sender and
>     receiver contexts getting out of sync through entirely normal
>     network behavior and becoming unusable.
>
>     > In the current design, if two ciphertexts are decrypted
>     out-of-order, both decryptions will fail.
>     > So the problem alluded to in the text above is one of
>     functionality; the application has to ensure (using some
>     meta-data) that it is calling decrypt in the right order.
>     > The application usually has to do something like this anyway to
>     put the plaintext stream together.
>     >
>     > I do not see how using AES-GCM-SIV is going to solve the above
>     issue; yes, it would allow you to decrypt the plaintext in any
>     order, but  the HPKE receiver would not be able to authenticate
>     the correct order.
>     > Am I missing something?
>
>        AES-GCM-SIV requires a nonce (although reuse is not tragic in the
>     way it is for GCM) so there still needs to be some guarantee that the
>     nonce plugged into the receiver is the same as the one plugged into
>     the sender when the ciphertext was created. This is a proposal for
>     AES-SIV (defined by Rogaway and Shrimpton) which can do deterministic
>     AEAD (it can also be passed a nonce to be more like a traditional AEAD
>     mode, albeit slower, but that's not what I'm proposing here). No nonce
>     so nothing to worry about getting out of order.
>
>        Regarding the correct order, for a streaming application yes that's
>     true. The correct order would still be needed and whatever technique
>     you use to ensure that decrypted packets get ordered correctly could
>     probably be used to ensure that packets are decrypted in order. But
>     there are other interesting applications of HPKE that are not
>     streaming
>     and each message can be thought of as self-contained. Imagine a sensor
>     obtaining some environmental data and then sending it off to a server
>     for correlation and processing every <time slice>. It would be quite
>     easy for such a sensor and server to get their HPKE contexts out of
>     sync and that would be a real PITA.
>
>        regards,
>
>        Dan.
>
>     > -Karthik
>     >
>     >
>     >
>     >> On 13 Feb 2021, at 00:29, Dan Harkins <[e-mail]
>     <mailto:[e-mail]>> wrote:
>     >>
>     >>
>     >>    Hello again,
>     >>
>     >>    The HPKE spec defines a single shot API for doing things
>     like key-wrapping.
>     >> You pass in the recipient's public key and some plaintext and
>     get back a
>     >> ciphertext. And that's it. One and done.
>     >>
>     >>    There is also (what I'll call for lack of a better word) a
>     multi-shot API.
>     >> The idea here is that there's a single asymmetric crypto
>     operation involving
>     >> the recipient's pubic key to derive some state that resides in
>     an opaque HPKE
>     >> context and then multiple calls to encrypt distinct plaintexts.
>     The state
>     >> created includes a base nonce and a sequence number
>     (initialized to zero).
>     >> Each call to another encryption (decryption) increments the
>     sequence number
>     >> which is xor'd with the base nonce and passed to the AEAD
>     algorithm. The HPKE
>     >> APIs take a plaintext, and AAD, and produce a ciphertext, and
>     vice versa.
>     >>
>     >>    This multi-shot API is fine if your world is Guaranteed In
>     Order Delivery
>     >> of Packets but that's not the world we all live in. As such,
>     it'll only
>     >> be a matter of time before the sender and receiver are out of
>     sync. The
>     >> HPKE draft alludes to this problem this way:
>     >>
>     >>
>     >>
>     >> Well that's a pain! One of the nice things about HPKE is that
>     one doesn't
>     >> need to worry about the nitty gritty of crypto state management
>     anymore,
>     >> it's all hidden. The API is nice and clean-- pass in a
>     plaintext and get a
>     >> ciphertext, pass in a ciphertext and get a plaintext.
>     >>
>     >>    If there was an AEAD mode that did not require a nonce it
>     could be used
>     >> in HPKE's multi-shot API without need for the application to
>     manage state
>     >> and guarantee the parties stay in sync. Thankfully there is
>     such an AEAD
>     >> mode: AES-SIV (RFC 5297).
>     >>
>     >>    When I brought this up earlier (and also on github) in the
>     context of
>     >> misuse resistance the response was, there's an export-only API
>     that will
>     >> give you a secret and you can go do any AEAD mode you feel
>     like, including
>     >> AES-SIV, issue closed.
>     >>
>     >>    While that is technically true, it applies equally to the
>     AEAD functions
>     >> that HPKE already defines-- you can export a secret and do
>     AES-GCM-256
>     >> outside of HPKE while managing the necessary state yourself.
>     Yet HPKE
>     >> defines AEAD functions whose state resides in an opaque context
>     so there
>     >> is obviously value in having that functionality. I just want to
>     get that
>     >> value-- a clean, multi-shot API where I don't need to worry
>     about managing
>     >> state or guaranteeing people remain in sync-- for people who
>     don't live
>     >> in the world of Guaranteed In Order Delivery of Packets.
>     >>
>     >>    So I'd like to ask the group whether they see value in
>     having a nonce-less
>     >> AEAD mode in HPKE. If so I'll be happy to resurrect the text
>     changes I
>     >> proposed and will be happy to contribute test vectors from my HPKE
>     >> implementation which already does AES-SIV.
>     >>
>     >>    One issue is that there are different security properties for a
>     >> deterministic authenticated encryption scheme than for a
>     probabilistic
>     >> scheme. This is discussed in [1] and the security
>     considerations would
>     >> have to mention this. But I don't see that as a formidable problem.
>     >>
>     >>    regards,
>     >>
>     >>    Dan.
>     >>
>     >> [1] Rogaway and Shrimpton, "Deterministic Authenticated
>     Encryption",
>     >>      EUROCRYPT, 2006
>     >>
>     >> --
>     >> "The object of life is not to be on the side of the majority,
>     but to
>     >> escape finding oneself in the ranks of the insane." -- Marcus
>     Aurelius
>     >>
>     >> _______________________________________________
>     >> CFRG mailing list
>     >> [e-mail] <mailto:[e-mail]>
>     >> https://www.irtf.org/mailman/listinfo/cfrg
>
>     -- 
>     "The object of life is not to be on the side of the majority, but to
>     escape finding oneself in the ranks of the insane." -- Marcus Aurelius
>
>     _______________________________________________
>     CFRG mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.irtf.org/mailman/listinfo/cfrg
>

-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius