[Webpush] Versioning aes128gcm-encoded messages

Kit Cambridge <kit@mozilla.com> Mon, 20 March 2017 00:05 UTC

Return-Path: <kcambridge@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 F2058129415 for <webpush@ietfa.amsl.com>; 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 <webpush@ietfa.amsl.com>; 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 <webpush@ietf.org>; Sun, 19 Mar 2017 17:05:37 -0700 (PDT)
Received: by mail-qt0-x22e.google.com with SMTP id r45so95973811qte.3 for <webpush@ietf.org>; 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 <kit@mozilla.com>
Date: Sun, 19 Mar 2017 17:04:56 -0700
Message-ID: <CAEeQnYKmJ9-E3JQArvNxbwJuTZvjwRW2W9002sciLNGKJDbKhg@mail.gmail.com>
To: webpush@ietf.org
Content-Type: multipart/alternative; boundary=001a114231567289f6054b1e4996
Archived-At: <https://mailarchive.ietf.org/arch/msg/webpush/otVvVGkYf7ioeW5zsSf6Lap-4jA>
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 <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 00:05:40 -0000

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