Re: [Webpush] Versioning aes128gcm-encoded messages

JR Conlin <jconlin@mozilla.com> Mon, 20 March 2017 03:12 UTC

Return-Path: <jconlin@mozilla.com>
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 <webpush@ietfa.amsl.com>; 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 <webpush@ietfa.amsl.com>; 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 <webpush@ietf.org>; Sun, 19 Mar 2017 20:12:27 -0700 (PDT)
Received: by mail-ot0-x236.google.com with SMTP id a12so55105829ota.0 for <webpush@ietf.org>; 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: <CABkgnnXTAO5OyPR5iMFiO0JLY4MtwNYEn1X9ksOyydbDvPsSTg@mail.gmail.com>
References: <CAEeQnYKmJ9-E3JQArvNxbwJuTZvjwRW2W9002sciLNGKJDbKhg@mail.gmail.com> <CABkgnnXTAO5OyPR5iMFiO0JLY4MtwNYEn1X9ksOyydbDvPsSTg@mail.gmail.com>
From: JR Conlin <jconlin@mozilla.com>
Date: Sun, 19 Mar 2017 20:12:26 -0700
Message-ID: <CA+XEteNrHQvDZZch9u=BP1t4x0D24NMgEFZHWN9+_kqH5oeo1g@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Kit Cambridge <kit@mozilla.com>, "webpush@ietf.org" <webpush@ietf.org>
Content-Type: multipart/alternative; boundary=94eb2c03c3a69ff9e3054b20e5ae
Archived-At: <https://mailarchive.ietf.org/arch/msg/webpush/FsgSiz_68LGNSkd3C9_SZpUjoAU>
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 <webpush.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/webpush>, <mailto:webpush-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/webpush/>
List-Post: <mailto:webpush@ietf.org>
List-Help: <mailto:webpush-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/webpush>, <mailto:webpush-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Mar 2017 03:12:30 -0000

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
>