Re: [CFRG] Questions for the group from the HPKE presentation

[Dan Harkins <[e-mail]>]

   An alternative proposal for using HPKE on lossy or unreliable networks...

   1000 pardons for the pseudo-python (which undoubtedly has some semantic
issues) but that's what HPKE uses so I'm trying to align with that.

   The idea here is that there is a new API for Seal and Open called 
DSeal and DOpen.
They are passed an additional datum which is used to construct the nonce 
used by
the AEAD algorithm (it no longer uses self.seq to construct the nonce). 
Senders
ensure this is a monotonically increasing number and receivers check 
whether they've
seen this number before in a sliding window of acceptable 
reordering/dropping.
For these APIs I've repurposed seq to be the sender's last sent number 
and the edge
of the receiver's window (seq can be used the old fashioned way when 
calling Seal()
and Open(), I'm not proposing a change to them). The receiver does an 
immediate
droppage check upon receipt and if it passes tries to open the message. 
If opening
succeeds the receiver window is updated to indicate this number has been 
seen.
This is analogous to the floating receiver window that IPsec uses [1] 
which was
written by James Hughes and Harry Varnis, all errors are mine.

def ContextS.DSeal(aad, num, pt):
   if num <= self.seq
       raise SealError
   ct = Seal(self.key, self.ComputeNonce(num), aad, pt)
   self.seq = num
   return ct

def ContextR.DOpen(aad, num, ct):
   if CheckSeq(num) == Bad
     raise OpenReplay
   pt = Open(self.key, self.ComputeNonce(num), aad, ct)
   if pt == OpenError:
     raise OpenError
   else
     UpdateWindow(num)
   return pt

where CheckSeq() and UpdateWindow() are as follows:

windowSize = 32 (or whatever)

def CheckSeq(num)
   if num == 0
      return Bad
   if num > self.seq
      return Good
   diff = self.seq - num
   if diff > windowSize
      return Bad
   if and(self.window, (1 << diff)) == 0
      return Good
   else
      return Bad

def UpdateWindow(num)
   if (num > self.seq)
       diff = num - self.seq
       if diff < windowSize
          self.window <<= diff
          self.window = or(self.window, 1)
       else
          self.window = 1
       self.seq = num
   else
       diff = self.seq - num
       self.window = or(self.window, (1 << diff))
   return

This does not require deterministic authenticated encryption modes but 
can, instead,
use the existing AEAD cipher modes so there is no worry about getting 
DAE instead
of IND-CCA2 when you're dealing with loss and reordering.

   Bouquets? Brickbats? If this seems like a better way to go I can 
write it up
in an -01 of my draft.

   regards,

   Dan.

[1] https://datatracker.ietf.org/doc/html/rfc2401#appendix-C

On 8/9/21 12:56 AM, Richard Barnes wrote:
> W.r.t. (1), the obvious solution to me would be a reordering window 
> outside of the HPKE implementation.  Even if the HPKE implementation 
> required in-order delivery, the application payloads containing HPKE 
> ciphertexts could have a sequence number indicating the order in which 
> they were produced, and the receiving application could use this to 
> ensure that they were fed to the HPKE implementation in order.
>
> --RLB
>
>
> On Fri, Aug 6, 2021 at 1:56 PM Dan Harkins <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>
>     On 8/6/21 3:49 PM, Richard Barnes wrote:
>>     1. I don't think this question is well-formed. HPKE isn't an API,
>>     it is a construction.  In fact, the "API considerations" section
>>     of the HPKE spec is there precisely because there might be
>>     different APIs to an HPKE implementation.
>
>       It may not be perfectly formed but its obvious what is being
>     asked. My answer
>     to it is that once you find out that your contexts are out of sync
>     it's too late.
>     I think it's more important to just be able to deal with
>     out-of-order and lost
>     packets.
>
>       Yes, it's "a construction"...that hides a datum from the user
>     and makes the
>     construction fragile for some use cases. So I'd like to remove
>     that fragility for
>     those use cases. The easiest and least intrusive, to the
>     construction, way is
>     to just have Nn=0 for these new AEAD algorithms and not worry
>     about the nonce.
>
>       One thing I failed to mention during my presentation is that
>     even if the
>     user adds a counter/nonce as AAD or a plaintext tweak (to hide
>     whether the same
>     thing is encrypted twice) and screws it up, the DAE security
>     guarantees
>     remain. SIV is the original misuse-resistant mode.
>
>       Instead "resetting the nonce counter" we could do
>     somethinganalogous to what
>     IPsec does with a floating window that prevents replay but allows
>     out-of-order
>     delivery modulo some limit (really late packets will just get
>     dropped). But that
>     might require some changes to the API...err, the construction, so
>     we'd be back
>     to a reformed question #1.
>
>>     Given all that, I would be in favor of no action here.  There are
>>     several existing ways for an HPKE-based protocol to deal with
>>     out-of-order delivery.
>
>       You mean like using deterministic authenticated encryption? If
>     not that, then what
>     exactly are you referring to?
>
>>     2. Personally, I don't have a use case for either of these.
>
>       Well, will you admit that while these might not be your use
>     cases that they are
>     legitimate nonetheless?
>
>       Serialization should have never used SEC uncompressed format.
>     There's no valid
>     reason to do that. I regret that I didn't bring this issue up
>     until it was
>     officially "too late". But that can be rectified pretty easily and
>     no one will force
>     you to use compact representation if you really don't want to.
>
>       Dan.
>
>>     On Fri, Aug 6, 2021 at 12:31 PM Nick Sullivan
>>     <nick=[e-mail]
>>     <mailto:[e-mail]>> wrote:
>>
>>         Dear CFRG participants,
>>
>>         At IETF 111, Dan Harkins made a presentation
>>         <https://datatracker.ietf.org/meeting/111/materials/slides-111-cfrg-new-kems-and-aeads-for-hpke-00>
>>         with two proposals:
>>         - a proposal to define new codepoints for HPKE representing
>>         new KEMs for compressed NIST points
>>         - a proposal to define new codepoints to support
>>         deterministic authenticated encryption schemes that don't use
>>         a nonce. This is in service of the use case of out-of-order
>>         delivery of ciphertexts. /In the discussion, it was noted
>>         thatHPKE uses a nonce to ensure that it never leaks whether
>>         the same plaintext was encrypted twice and that this proposal
>>         does not provide this security property./
>>
>>         Also during the discussion, an alternative proposal was made
>>         to solve the out-of-order use case: modify the API for HPKE
>>         to enable the user to reset the nonce counter. This API would
>>         enable out-of-order delivery of ciphertexts with existing
>>         HPKE AEADs.
>>
>>         The chairs would like to ask the group a few questions:
>>         1) Does the research group support adding an API to HPKE for
>>         resetting the nonce counter?
>>         2) Is there interest in pursuing a work item to explore
>>         defining either of the following:
>>         - new codepoints for compressed curve points in HPKE?
>>         - new codepoints for deterministic authenticated
>>         encryption in HPKE (given the answer to (1) was no)?
>>
>>
>>
>>         Regards,
>>         Nick (for the chairs)
>>         _______________________________________________
>>         CFRG mailing list
>>         [e-mail] <mailto:[e-mail]>
>>         https://www.irtf.org/mailman/listinfo/cfrg
>>         <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
>

-- 
"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