Re: Version Ossification: Intended Scope for QUICv1

[Mikkel Fahnøe Jørgensen <[e-mail]>]

I really don’t think the draft should recommend key deployments like that.
It may be that baked into the binary works, but sound deployment advise is
to use an environment variable for such things, then you can bake it into
you deployment script if you wish. Point being, the WG should not be too
specific here.


On 5 November 2019 at 03.22.32, Jana Iyengar ([e-mail]) wrote:

On Mon, Nov 4, 2019 at 5:58 PM Martin Thomson <[e-mail]> wrote:

> On Tue, Nov 5, 2019, at 12:23, Jana Iyengar wrote:
> > On Sun, Nov 3, 2019 at 1:46 PM Martin Thomson <[e-mail]> wrote:
> > > Why can't servers just bake the "keys" into binaries? I mean, that's
> not something that is likely to get lost. And it isn't really the case that
> keys need to be secret, they just have to change often enough to frustrate
> attempts to fixate on them.
> >
> > This is a fine idea, but how does it change anything? Whenever the keys
> > are rotated at the server, you would still have to deal with old
> > versions appearing at the server, no?
>
> I'm assuming that you can a) limit the time over which a token could
> appear, b) use a key identifier so that keys can be changed, and c) keep
> old keys in the code until the associated tokens are all expired.
>

Right, that makes sense. I think your point about not requiring this to be
rotated frequently is a good one, and we might even want to suggest your
idea of baking the key into the binary.