[ech] Loading time and flushing

[Watson Ladd]

On Thu, Oct 5, 2023 at 5:21 PM Stephen Farrell
<stephen.farrell at cs.tcd.ie> wrote:
>
>
> Hi Watson,
>
> Good one! Thanks for the fine comment.
>
> On 05/10/2023 21:44, Watson Ladd wrote:
> > Dear ECH enthusiasts,
> >
> > I think the current API from Stephen Farrel
>
> Ahem, Farrell, i.e. not related to, but often confused with, the
> Adrian F. variety in IETF contexts:-)

My apologies for horrific spelling.
>
> > for loading doesn't quite
> > work. If I understand correctly, the real time of loading is used to
> > determine when a key is timed out. In a fleet of servers a server may
> > restart during the validity time of a key, and thus would end up
> > retaining it longer. Thankfully this is not a big problem as servers
> > with additional keys can only decrypt more, unlike with shared ticket
> > keys where it could be more serious.
>
> Great point. Being fleet-ignorant, I need to ponder it a bit.
> If you know what you'd like, be great to get input on that.
> (And I'm very happy to modify APIs to be thusly useful.)

So the pattern I've seen work is that each server has a window of 3
keys: past, current, future.  it will accept any of them to decrypt
from a client, but only hands out the current key.

On a rotation (synchronized to the top of the hour or something
similar)  it forgets the past, makes the current past, the future
current, and grabs a new future key.  So long as all machines are
within a few minutes of synchronization this prevents any outages.
Generally the next few keys will be present in whatever storage system
is used for keys so that a disruption to generation will have a
comfortable recovery time, but aren't loaded.

>
> There's also an interaction here with retry_configs I guess,
> it'd seem a bad plan if one server were returning N such,
> when other servers had timed out some of those decryption keys.
> So if the right answer e.g. involved a notAfter equivalent,
> that'd likely also affect that parameter too. OTOH, there's a
> fine history of notAfter equivalents being foot-guns, so not
> sure if that'd be right either.

I think the application code should explicitly manage whether an
ECHConfig is decryptable, rather than using timeouts inside the
OpenSSL library. It's a lot easier to get event logging out for one
thing.

Sincerely,
Watson
>
> Cheers,
> S.
>
> >
> > Sincerely,
> > Watson
> >



-- 
Astra mortemque praestare gradatim