From nobody Sun Mar 19 17:05:41 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2058129415 for ; Sun, 19 Mar 2017 17:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m25-Z3K2MyaK for ; Sun, 19 Mar 2017 17:05:38 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02850129434 for ; Sun, 19 Mar 2017 17:05:37 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id r45so95973811qte.3 for ; Sun, 19 Mar 2017 17:05:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=0VSBA/yufUDZyMWSjglqGeLhnWLuTemIOpN7y10Ngcw=; b=aQJKY8xnTXQyrToMcx6oHcS7MHC9j4eeDDunyJaWf4tpVN+592JFPkeifCsdL5clqu gfJEN995J4ttTvlsVTzLHjAvNPWiXWRBKxzkDUWnQPERyXhHcwv/152bThuYdwvQF35/ adlUvhT+OaCny5e2iYThEwzTHkOF7Dlp5Mqyg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=0VSBA/yufUDZyMWSjglqGeLhnWLuTemIOpN7y10Ngcw=; b=U/w3HbrdT1NAb4IkhRSCO/CjQItewl/j5ORZVQo/r9+JCuSr8DivFdzMjDS+LWeJO0 eBFJDzxCVYwk1hRVK03V9oM6XCq53M8UUyP1s9roirzrYev6E7+EcqyWseUrg7XXqwTZ u7zjysINCftNVXaeWodcRcY0o59CEEkknbjt6BbSIuOulkF+QJFAWokVFkot6GXRGkjU vWiGj/ckgjM7qO3IDHub7iXJbi5ykbsk0+irmG0vZoANGSZxl4G6FJG4isZbhVM5eX7X Fb0L88LLR6NmHKI9VeuR7TdwzcqKFlL1/adcK9BZh7YnYQ3692ZJysUhklrSIaa1uEF9 +UnA== X-Gm-Message-State: AFeK/H2bgXzHSkZLmqQN2LTedAuqaqBKuC5jeZMn/V7znykIuAPF8WZ0HlqvU9zsfaSsEcR8BYSD3kTHmJfwKXKG X-Received: by 10.237.42.98 with SMTP id k31mr25314648qtf.232.1489968336888; Sun, 19 Mar 2017 17:05:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.30.197 with HTTP; Sun, 19 Mar 2017 17:04:56 -0700 (PDT) From: Kit Cambridge Date: Sun, 19 Mar 2017 17:04:56 -0700 Message-ID: To: webpush@ietf.org Content-Type: multipart/alternative; boundary=001a114231567289f6054b1e4996 Archived-At: Subject: [Webpush] Versioning aes128gcm-encoded messages X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 00:05:40 -0000 --001a114231567289f6054b1e4996 Content-Type: text/plain; charset=UTF-8 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 --001a114231567289f6054b1e4996 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Now that encrypted content-coding has a binary = header block, should we consider including a "magic number" prefi= x with a version? This would avoid having to use a new scheme name for back= ward-incompatible changes (so far, we've gone through "aesgcm"= ;, "aesgcm128", and "aes128gcm"), and make it easier fo= r tools to identify encrypted payloads.

OTOH, it seems like the draf= t has crystallized enough to where this won't be necessary. In the futu= re, maybe it does make sense to use a new scheme name for substantial chang= es.

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
--001a114231567289f6054b1e4996-- From nobody Sun Mar 19 17:52:42 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD10129434 for ; Sun, 19 Mar 2017 17:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkTWCG2hogpP for ; Sun, 19 Mar 2017 17:52:39 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 057C112702E for ; Sun, 19 Mar 2017 17:52:39 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id i34so96593521qtc.0 for ; Sun, 19 Mar 2017 17:52:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ipu81+lJ96zsGDmXgl3hX2xY4cl+xJN/vPN2KNbVutQ=; b=AAK/jFNQWyVbVaTaVk3Aqgzb9rLS1UKhhAMzWv3ybuyn8V292l6/N3ydWWu1jVBQo3 PNK3LK9GmVBj3/BV1JYX/W4wDuWapneZQPEyvFBwjvqrzkjIWaFzBmzG0o0q7d4EbLnA p3T8CGOnMnxVdhxaBilfo24y6ZCX+xv2HPv5m8Gw4eOlidAENZz/m5NwvnSzkI2OCqUc nz8gIMqpddroC6ol1bgFFrNRu16ZYwOtmhTufmAU5H9U7iBYMOD8YHmko5BbkH8Zh4Pj CGptGGx3pC/VJjY/KBzjqbB7QowChgzFADKs1h6ShRtXDhNHawShCR37sQ4r6cb/CkK9 XFcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ipu81+lJ96zsGDmXgl3hX2xY4cl+xJN/vPN2KNbVutQ=; b=o5VJP8swJ01ZRB7ccVcKyffZxlkUE+brtStEtrC8h/oxhBAbm4b2ULy3vZN8TJmqhA t4REV1XkpbZBmgng1JDMqtk/swYfK9zROHRm+c8n5Lv0nMo7ac5QKzzZzN+lsqzcogMW Om/Cy9EohiQeiRNQV1uxiBLvFYAhw5DYSqdUJX7wvAzeGTcMg5BOf356FITSn4TkvN7+ bH5MoCPIKXYiXnittu+KodaxuQpt7uneNeb9Rp2YlEXyoxLJHgpc+RTkhcewpF9mX7Yo GFoGuiVQfl5ZkG920qNxAv19rokg/UW0f2pDnamd4QQo5E0RXnSeorGPs5Jh3VVMfk9m TFFw== X-Gm-Message-State: AFeK/H0vRI+/dN0e64X1GOfBjZUBos0I/tT6qAuKbipRTAHETWRxcYxMkO2YsuEaM+znlhhJOXga1HNHoe3S7w== X-Received: by 10.237.34.250 with SMTP id q55mr24403520qtc.144.1489971158191; Sun, 19 Mar 2017 17:52:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Sun, 19 Mar 2017 17:52:37 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Mon, 20 Mar 2017 11:52:37 +1100 Message-ID: To: Kit Cambridge Cc: "webpush@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Webpush] Versioning aes128gcm-encoded messages X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 00:52:41 -0000 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 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 > From nobody Sun Mar 19 20:12:32 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5091C12952E for ; Sun, 19 Mar 2017 20:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDKnnLMg3hSW for ; Sun, 19 Mar 2017 20:12:27 -0700 (PDT) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFAE7129526 for ; Sun, 19 Mar 2017 20:12:27 -0700 (PDT) Received: by mail-ot0-x236.google.com with SMTP id a12so55105829ota.0 for ; Sun, 19 Mar 2017 20:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=85UhV1Iwweq+k/6b/TrR3T9iPpxsQ7FXDftFaYJ4s4s=; b=N3pbaZCfrCHQiJONC2FF1VNut81SQGNAFBvTY9Yr8IMUiHIyPqursfl8rr6kQ8yVjl zZAedJwsDzYlOFZsEK0633SnAPZMUVK0+Tpw+u5ZKMtaZtIii4ZA9B+luCBGc+B108U4 w3K+nboq3SPa2FNAMzmCBYk8dntZIJuUirF4k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=85UhV1Iwweq+k/6b/TrR3T9iPpxsQ7FXDftFaYJ4s4s=; b=FZyK0gl61zff1gy5FXxe+YIqx/iyYKUUkGUa8r0r+LRItRXLeIhMiqK6YONFcQ+2ZP 2BdeqdUfEDmR7VR4JD+lFpP2xLAgi6uO2EqB2ETnb7HNGOFGsebAjMWM8QjHDJsWrLtf K7ylDnSwrYY6BXsJfbjtPGHaB4BfLHj5G9VDrZcs/bV+mtJIFo/+hX4PoqmhaNPgKYDj Z/S1OErs/zBy/mcn8gcy9FRSD/sceZmGnfINovYHFbXXYLSgsirXU4ZLNpkVs2/KuAyH XSNrBaego5LZDDTk2OEHYDz7vkkr+7DwZ8XOfd7aQFkew1v7X7FoVx/00dLm4gMxZ2Xn Sv9Q== X-Gm-Message-State: AFeK/H0rHhJuckHiu11u/5bO5Hsh61tDp7V4PCu77d0cyUCcqDUnyG9SutsVcK/EDhAlWukXFSmOdD0bf10k82YB X-Received: by 10.157.1.22 with SMTP id 22mr13120239otu.272.1489979547046; Sun, 19 Mar 2017 20:12:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.48.131 with HTTP; Sun, 19 Mar 2017 20:12:26 -0700 (PDT) Reply-To: jrconlin@mozilla.com In-Reply-To: References: From: JR Conlin Date: Sun, 19 Mar 2017 20:12:26 -0700 Message-ID: To: Martin Thomson Cc: Kit Cambridge , "webpush@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c03c3a69ff9e3054b20e5ae Archived-At: Subject: Re: [Webpush] Versioning aes128gcm-encoded messages X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 03:12:30 -0000 --94eb2c03c3a69ff9e3054b20e5ae Content-Type: text/plain; charset=UTF-8 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 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 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 > --94eb2c03c3a69ff9e3054b20e5ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've always worked on the premise that you only version things you w= ant to keep in six months. Generally, "things change" as new tech= nology develops or bugs are found. Not having a version means you have to r= eplace whatever it was completely since you cannot get all participants to = seamlessly migrate in a short period of time. (And doing server-side gymnas= tics in order to support "legacy" non-versioned code is how you d= evelop 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 th= e version onto the Content-Encoding. It would break current clients, of cou= rse, but it at least would provide some flexibility in the future.

<= /div>

On Sun= , Mar 19, 2017 at 5:52 PM, Martin Thomson <martin.thomson@gmail.com= > wrote:
My intent was to s= ignal version with the content-coding type.

Adding a magic number doesn't really add anything unless you wanted to<= br> sanity check before doing a decryption.=C2=A0 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? T= his 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 wo= n'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, gi= ven that
> their payloads (by design!) don't reveal anything about their cont= ents.
>
> 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<= br>

--94eb2c03c3a69ff9e3054b20e5ae-- From nobody Sun Mar 19 20:52:46 2017 Return-Path: X-Original-To: webpush@ietfa.amsl.com Delivered-To: webpush@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54BC5129552 for ; Sun, 19 Mar 2017 20:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDl4kW9ZRMNm for ; Sun, 19 Mar 2017 20:52:42 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ED68129551 for ; Sun, 19 Mar 2017 20:52:42 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id y76so101084547qkb.0 for ; Sun, 19 Mar 2017 20:52:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zIWLSOghMg7wdCXW+BqxuwBwd4cIdEJTIKR2nwibfyU=; b=un/Ve7W42CTILnCrnDb588bHZH26sdGGIauYZEOZnTKEUeKwDRzGShtopm7ttlmeP5 /+68ivKGZ2sbwLa7oDW4N1m2ijoXX2LWZndS4H2XRR17ZvEypVuyqBL+qlgqclSA0x8s y8pRoHiVBnau/gHubpbFqCYdjCKLOT6eewz+MlW/dxuHPNvJZSMxYDCuUfqrzrtUPz54 17Asx/ghMl7CqS5JY4WyFa8C05YTNhw6U57/wSQOPF8wO7BZvZ/KMzRVHn7vJYrcmIB0 /HNl4MmY9lnBAdxzOvl/Wcg0pPK4HkiQ10Uec4dr+ZzMziLFE2kNQGCSRJ0XCYKfyLag rlqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zIWLSOghMg7wdCXW+BqxuwBwd4cIdEJTIKR2nwibfyU=; b=OqAmLi2G88lxKdTCdzXX3reiAj3tEsk7X18l748LoovmEfSHZd/ntuyrm92Qavx3P8 VDpXV0MMS4FJfKfG1fWem9PcCGqC38TlrOoj4ejN1cZ7wzTvVa90rdM/eQdMDEJja0Sm SaqFLHcmHyqsB9sgG8kb8bacnlGz9zV3cQ1JORpsgqR+QY+y6clj7Mg7TaH8VxLe8Rb1 cSVgiF1SCAFvnwLmQMSob/4SIUeEb1tCo4E6yKVQLwNj/PDm/scPAgvw/lT5uY49sI5C KC6Gf4pD57noFeW5rL5sY/N2CPZC7fvtw3in5hZ+wSG9YYRdZzL3/IY9j7bWtSOX5GVB 2GZw== X-Gm-Message-State: AFeK/H26XUzQWnTsVAM9DutBauXLZOJKxYAZkO8R1W/PwGBM6ga8bU8XWAgiYIT1IZXecPiplP8ta/Rot6dCvA== X-Received: by 10.233.237.20 with SMTP id c20mr24628425qkg.144.1489981961868; Sun, 19 Mar 2017 20:52:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Sun, 19 Mar 2017 20:52:41 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Mon, 20 Mar 2017 14:52:41 +1100 Message-ID: To: JR Conlin Cc: Kit Cambridge , "webpush@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Webpush] Versioning aes128gcm-encoded messages X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of potential IETF work on a web push protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 03:52:44 -0000 On 20 March 2017 at 14:12, JR Conlin wrote: > 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. 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.