Re: [Webpush] Versioning aes128gcm-encoded messages

I've always worked on the premise that you only version things you want to
keep in six months. Generally, "things change" as new technology develops
or bugs are found. Not having a version means you have to replace whatever
it was completely since you cannot get all participants to seamlessly
migrate in a short period of time. (And doing server-side gymnastics in
order to support "legacy" non-versioned code is how you develop drinking
problems.)

Unfortunately, the current binary format starts with a randomized value, so
adding information to the header cannot easily be differentiated. I'm fine
if the eventual replacement for ECE either specifies a labeled prefix (I
hate to use DER as an example, but that sort of format is fairly
predictable and flexible.) Likewise, we could suffix the version onto the
Content-Encoding. It would break current clients, of course, but it at
least would provide some flexibility in the future.

On Sun, Mar 19, 2017 at 5:52 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> My intent was to signal version with the content-coding type.
>
> Adding a magic number doesn't really add anything unless you wanted to
> sanity check before doing a decryption.  The decryption will fail if
> something has changed and decryption is cheap enough not to need an
> redundant version signal.
>
> On 20 March 2017 at 11:04, Kit Cambridge <kit@mozilla.com> wrote:
> > Hi,
> >
> > Now that encrypted content-coding has a binary header block, should we
> > consider including a "magic number" prefix with a version? This would
> avoid
> > having to use a new scheme name for backward-incompatible changes (so
> far,
> > we've gone through "aesgcm", "aesgcm128", and "aes128gcm"), and make it
> > easier for tools to identify encrypted payloads.
> >
> > OTOH, it seems like the draft has crystallized enough to where this
> won't be
> > necessary. In the future, maybe it does make sense to use a new scheme
> name
> > for substantial changes.
> >
> > I'm also not sure how useful identifying encrypted messages is, given
> that
> > their payloads (by design!) don't reveal anything about their contents.
> >
> > WDYT?
> >
> > - kit
> >
> > _______________________________________________
> > Webpush mailing list
> > Webpush@ietf.org
> > https://www.ietf.org/mailman/listinfo/webpush
> >
>
> _______________________________________________
> Webpush mailing list
> Webpush@ietf.org
> https://www.ietf.org/mailman/listinfo/webpush
>