Re: [Sframe] Key ratchting

Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> Thu, 06 October 2022 13:54 UTC

MIME-Version: 1.0
References: <CA+ag07aZ-OoCpAQumj_TYDuiZ=RaBMiWiAi8MoUrYo4zmYuovg@mail.gmail.com> <CAL02cgTfh8=j=t_MZNTw+Mpmyym8UXr=rkjMNUKK_P2iH_F4DA@mail.gmail.com>
In-Reply-To: <CAL02cgTfh8=j=t_MZNTw+Mpmyym8UXr=rkjMNUKK_P2iH_F4DA@mail.gmail.com>
From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Date: Thu, 06 Oct 2022 15:54:46 +0200
Message-ID: <CA+ag07ZVX3r8bY-BmSvch=vkyXyWyerZ4Q8gBdSvAZEcinzgYQ@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>, Emad Omara <eomara@apple.com>
Cc: sframe@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e754fb05ea5e099c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sframe/vsC59HQ9-vXAgLgJDdVBKUO1ATw>
Subject: Re: [Sframe] Key ratchting
Precedence: list

On Thu, Oct 6, 2022 at 2:40 PM Richard Barnes <rlb@ipv.sx> wrote:

>
> 1. Instead of allowing every sender to use the whole KID space, you could
> segment the KID space as in the MLS-based case (so that KID would indicate
> sender as well as generation)
>

That was my second question, would the SFrame stack need to know the sender
for each KID to be able to "expire" a previous KID for the same sender? If
so, should that information be passed in the SFrame API or should we carry
the sender Id also on the SFrame header? (The later would allow to identify
the sender of each packet)

2. Instead of ratcheting the keys directly, there should probably be a
> ratchet_secret that gets ratcheted, and from which keys are derived.  This
> would avoid the keys being used with two algorithms (HMAC and AEAD).
>

I think @Emad Omara <eomara@apple.com> should be the right person to answer
that question.

Best regards
Sergio

[Sframe] Key ratchting Sergio Garcia Murillo
Re: [Sframe] Key ratchting Richard Barnes
Re: [Sframe] Key ratchting Sergio Garcia Murillo
Re: [Sframe] Key ratchting Emad Omara