Subject: [Webpush] Versioning aes128gcm-encoded messages

From: Kit Cambridge <[email-masked]>
Date: Sun, 19 Mar 2017 17:04:56 -0700

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 20 Mar 2017 11:52:37 +1100

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 <[email-masked]> wrote:
> 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.
>
> _______________________________________________
> Webpush mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webpush
>

---

From: JR Conlin <[email-masked]>
Date: Sun, 19 Mar 2017 20:12:26 -0700

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.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 20 Mar 2017 14:52:41 +1100

On 20 March 2017 at 14:12, JR Conlin <[email-masked]> wrote:
> 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.

The problem with versioning inline is that it is invisible to HTTP
content negotiation.  Granted, that doesn't really make any difference
to the push usage, but a label is visible.  If you accept the need to
have more labels, then the inline check is redundant.