Re: [CFRG] RGLC on draft-irtf-cfrg-dnhpke-03

[Taylor R Campbell <[e-mail]>]

> Date: Fri, 8 Dec 2023 11:23:05 +0200
> From: Ilari Liusvaara <[e-mail]>
> 
> On Thu, Dec 07, 2023 at 05:42:56PM -0500, Richard Barnes wrote:
> > 
> > As a final note, I would just point out that the even document's
> > putative justification for DAE is false.  It is perfectly possible
> > to use HPKE in lossy networks.
> 
> AFAICT, not without heavy, in many cases not acceptable, overhead.
> And as extra bonus, with some of the most dangerous security 
> problems of DAE.
> 
> The biggest problem with DAE is not the data leaks. It is what replays
> will do to the application. Unless great care is taken (and many times
> it is not) the results are probably going to be ugly. 
> 
> For most applications with associations over lossy networks, windowed
> replay detection is a sweet spot. Handles loss, is stateful and prevents
> replay. Application just has not use ciphertext retransmission for
> reliability.

I haven't followed the whole thread here and I have no comment on HPKE
in lossy networks, but in general DAE supports this use case easily:
You can put a message number for replay detection in the header
(associated data), or even keep it secret in the payload.

DAE just obviates the need for a _separate_ fixed-size nonce parameter
in the cipher that requires your message number to be shoehorned into
a particular format, and serves to mitigate the damage if the sender's
counter is reset to zero, e.g. in a VM rollback or a backup restore.