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 75E1513283F for ; Thu, 17 Aug 2017 21:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 xY6eTur1Cdzj for ; Thu, 17 Aug 2017 21:15:23 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (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 183A21321D2 for ; Thu, 17 Aug 2017 21:15:23 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id i12so56093134pgr.3 for ; Thu, 17 Aug 2017 21:15:23 -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=YmY/33+JYNoQQD6jGUX+2yLfUMPrlGc+QFZPKUQcBNA=; b=sSZsVuPm8Mmen5L3sKnfWdITPR0hslOjnJVEiBRY7dztwlew13Tn+NtLvHTLHPb+FK 5vaF85QnJWQegfTGMVRVX7at+LJFtRe9230w752wUEUD0m+d+SZtk+EjzQp0rderyG5y tBQXkegP7ozlKyer5HE3KcM70EDpnKKL1Rddp8DjfWVW2MW5NdMtgRzfGzRW364Njyhv IDftuTLYjUjG9aQ18kWP1CePCXNfM4YIASoWatrGQU2OfMdcFUgTdiKtd/lOFkj6mt+Q YTb+4mJmvrUB96Ca323XZqwMRK/TxVfNjzqNSQwGd2j+z4V6AJPYp9+GJTCk4MR2XUj2 ynZw== 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=YmY/33+JYNoQQD6jGUX+2yLfUMPrlGc+QFZPKUQcBNA=; b=Z7G3rheXcnVJhX1nYzL4IljHrof881KklVLRX3N7l0XY4kyGN1vtQDYgM4nCk2b2hm AHJOyTk3ubaNrP6j7iL0Cg7wdh9rijrlnOJUoxE9SiUEhTrnwi8w+HyDmjpkb8sDozzW TbqqiGfKMJv+AEMx9qrIAq3eEWvppwHM58dZq/4s+tzI6FbwKuGKD8Z0YNEXDXr09tAW lko7DhPHtBweq1coColDAx1Iv1/PkbYyn/ctXesV9/P9jdtT7UrucDSlXDY2wMNTD8Zy ILj8gzhCWvSAlFt7VFBvd1mq+sGJuCGjMPzsDVfnwlFA4IGCOn+IysLNwecM6i5yceHt DWkQ== X-Gm-Message-State: AHYfb5g0h1Pgbs6ivU1+eR2w0kxd+k4Y+i8GW+2p0YdcFFBjNhWKDXUf Uj0fbq2hz15kURUsW6/3KOmkDQrWX5Em X-Received: by 10.98.144.149 with SMTP id q21mr7327303pfk.137.1503029722566; Thu, 17 Aug 2017 21:15:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.138.76 with HTTP; Thu, 17 Aug 2017 21:15:21 -0700 (PDT) In-Reply-To: References: From: Costin Manolache Date: Thu, 17 Aug 2017 21:15:21 -0700 Message-ID: To: Phil Sorber Cc: "webpush@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0e37d8b3576d0556ff6091" Archived-At: Subject: Re: [Webpush] CALL FOR CONSENSUS: VAPID cut-and-paste protection 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: Fri, 18 Aug 2017 04:15:25 -0000 --94eb2c0e37d8b3576d0556ff6091 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (1) we did discuss using mutual TLS for webpush, as one of the early proposals, which would mitigate this issue. However it was felt that support for mutual TLS would be tricky in various environments, limiting the adoption both client and server side. With the work going on SPIFFE and other projects (gRPC, k8s) - this may change and IMHO a future revision of webpush could add it. On VAPID - since it is based on JWT, we have the same limitations as most other uses of JWT. I believe Oauth1 was mentioned in some discussions, but more as a thing to avoid. Also discussed the fact that bearer JWTs tokens with audience and similar expiration are widely used for protecting more valuable user accounts, and in the case of webpush we also have the authenticator and the (secret) public key. If VAPID is used for other purposes besides webpush - I believe the format is extensible enough to support additional elements to avoid reply. Costin On Thu, Aug 17, 2017 at 7:58 PM, Phil Sorber wrote: > This is a call for consensus for an issue relating to > draft-ietf-webpush-vapid, which is currently in IESG evaluation. Interest= ed > participants should respond no later than Friday, September 1st 2017. > > During its initial review, one of the Security Area Directors expressed > concerns regarding the cryptographic properties of the JWT: > > https://mailarchive.ietf.org/arch/msg/webpush/HYW9NcUioQo5X2Np-d2hjCzB1Fo > > Specifically: as implemented, the JWT is merely a bearer token. While the > DISCUSS provides a thumbnail sketch of how this could be mitigated, the > crux of the issue isn=E2=80=99t the specifics of the implementation, but = whether > the WG had considered other, more cryptographically secure approaches. > > Although participants are free to respond in any way they choose, the mos= t > useful input would be of one of the following three forms: > > > 1. > > I believe the working group has already discussed adding such a > mechanism and rejected it (with citation to an email discussion or min= utes > reflecting such discussion). > > 2. > > I do not think the working group has discussed the issue before, > however I am opposed to changing the mechanism prior to publication > because... > > 3. > > I do not think the working group has discussed the issue before, and > would support bringing the document back to the working group for the > purpose of mitigating copy-and-paste attacks. > > > Thank you. > > _______________________________________________ > Webpush mailing list > Webpush@ietf.org > https://www.ietf.org/mailman/listinfo/webpush > > --94eb2c0e37d8b3576d0556ff6091 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(1) =C2=A0we did discuss using mutual TLS for webpush, as = one of the early proposals, which would mitigate this=C2=A0
issue.=C2= =A0 However it was felt that support for mutual TLS would be tricky in vari= ous environments, limiting the adoption=C2=A0
both client and server si= de.=C2=A0 With the work going on SPIFFE and other projects (gRPC, k8s) - = =C2=A0this may change and
=C2=A0IMHO a future revision of webpush= could add it.

On VAPID - since it is based on JWT= , we have the same limitations as most other uses of JWT.=C2=A0
I= believe Oauth1 was mentioned in some discussions, but more as a thing to a= void.=C2=A0
Also discussed the fact that bearer JWTs tokens with = audience and similar expiration are widely used
=C2=A0for protect= ing more valuable user accounts, and in the case of webpush we also have th= e authenticator
=C2=A0and the (secret) public key.=C2=A0

If VAPID is used for other purposes besides webpush - I be= lieve the format is extensible enough to=C2=A0
support additional= elements to avoid reply.

Costin



On Thu, Aug 17, 2017 at 7:58 PM, Phil Sorber <= sorber@apache.org> wrote:
<= div dir=3D"ltr">

This is a call for consensus for an issue relating to draft-ietf-web= push-vapid, which is currently in IESG evaluation. Interested participants = should respond no later than Friday, September 1st 2017.


During its initial review, one of t= he Security Area Directors expressed concerns regarding the cryptographic p= roperties of the JWT:


https://mailarchive.ietf.org/arch/ms= g/webpush/HYW9NcUioQo5X2Np-d2hjCzB1Fo


Specifically: as implemented, the JWT is mere= ly a bearer token. While the DISCUSS provides a thumbnail sketch of how thi= s could be mitigated, the crux of the issue isn=E2=80=99t the specifics of = the implementation, but whether the WG had considered other, more cryptogra= phically secure approaches.


Although participants are free to respond in any way they choose= , the most useful input would be of one of the following three forms:


  1. I believe the working group has already discuss= ed adding such a mechanism and rejected it (with citation to an email discu= ssion or minutes reflecting such discussion).

  2. I do not think = the working group has discussed the issue before, however I am opposed to c= hanging the mechanism prior to publication because...

  3. I do no= t think the working group has discussed the issue before, and would support= bringing the document back to the working group for the purpose of mitigat= ing copy-and-paste attacks.


Thank you.


_______________________________________________
Webpush mailing list
Webpush@ietf.org
https://www.ietf.org/mailman/listinfo/webpush<= br>

--94eb2c0e37d8b3576d0556ff6091--