From nobody Tue Nov 1 10:58:29 2016 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 7CB5B1294DA for ; Tue, 1 Nov 2016 10:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 HL7USh7xfx4Q for ; Tue, 1 Nov 2016 10:58:25 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 B3A2B129413 for ; Tue, 1 Nov 2016 10:58:25 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id 128so113615872oih.0 for ; Tue, 01 Nov 2016 10:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xgP7er559fzjZzkf+MNNoEVK8rT4UXIaCEIR8RLQLcs=; b=MzVuSmJxsRgGFs8PPuXoPyYXSrSxmVJFfQDN2UK1kZLMSKPf7BW17L6dg4/MTAvEoL danr5ULTqsbuag++nJNUNeI+lVkmIi4SAZ+lASRpH8t2u+h5EgWhh0z+ZLRamdOiUB2b ieJn3tdRELvQMwHOLMYOdJ/6igotLjOZCm6D3wSMKFKudIfL9LDE7vxj758zKq9dN6IX t6DOJh0BlScWbfwXJ/+UdPYA9ks4CuJ94itkWj47Hphgcfv4deNOC1wMNClw5Su8asR6 xW+WiX6AOiFZ5AahXkpxljCdYRgHdwoXbS6nFD2TJ5tnapkvrPgX/F04VDeIPtnxPrRi RCpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xgP7er559fzjZzkf+MNNoEVK8rT4UXIaCEIR8RLQLcs=; b=Ch+soRwCtzNJEdm/H12ILNwAuIKv8nZilFYnczRUWhsBx+FKQ7ytzo6G28cdwV8E+7 qdUoyWHyepYe8GxltSiBUUbViwS2GWGChSR1tDRYfvHjAu08X/jS5tYxU9ZShcCvbUEM zpOZnqY2x+W7iPDUU6h68CiQhT5ZsBoTLKaNxt5R13B4/p4PTbaS5bnKcWxecfGqR/Sf 45dIlyt0FCqWPsJ88zFgEuPpeevFnJ8zjZtL0AUIoSuTv3MMYSTc0QrU2yTjaHg7Zvnb lSZpIOndyP0xpE94blnp1jp8vjsfhQ2/xZympxP7xd1oAMsT/aubRt5ljMgpyWQHt8+U vsNA== X-Gm-Message-State: ABUngvcrfXz39pUcFZBqJa47rF6LsPUeZJdDvJICHXvgcepTT8YmK/4Chh5QYfuacJazy8btcLXUwD50ckdgpQ== X-Received: by 10.107.183.148 with SMTP id h142mr106643iof.190.1478023104967; Tue, 01 Nov 2016 10:58:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Costin Manolache Date: Tue, 01 Nov 2016 17:58:14 +0000 Message-ID: To: Martin Thomson , Peter Beverloo Content-Type: multipart/alternative; boundary=94eb2c0b8e6e243a270540411264 Archived-At: Cc: jr conlin , "webpush@ietf.org" Subject: Re: [Webpush] Major change to encryption X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 01 Nov 2016 17:58:27 -0000 --94eb2c0b8e6e243a270540411264 Content-Type: text/plain; charset=UTF-8 Using the Crypto-Key for vapid is fine with me - I have no problem with keeping it for this purpose, in vapid spec. Or to use Crypto-Key in other specs that deal with key distribution or other things. However I still think that for consistency, the dh-public key used for decrypting the message should be in the binary header, next to salt - maybe even using the 'key id' field ( renamed to 'symmetric key id or public key' ). The binary blob should be sufficient to decode the message, if the content-encoding is known, using secrets known to the receiver ( symmetric key in http case, or EC private key for webpush ). I think it's important to recognize that client-to-pushservice communication may use different transports, in addition to http/2 push promises. In particular it may be layered over Webcoket, newly proposed WiSH, etc - and in many cases the implementation will be greatly simplified if the binary blob can be sent as-is (after any protocol-specific authentication ). Costin On Mon, Oct 31, 2016 at 4:57 PM Martin Thomson wrote: Hi Peter and JR, Thanks both for picking up on my stupid errors. Hasty is not always careful enough, but I was working to a time limit. With 5 minutes left, I think that I managed to get all your input integrated. And your reminder about vapid was timely. I think that we can dispense with any attempt to remove Crypto-Key, since we have to have it for vapid anyway. Now I need to think about getting the python implementation updated. --Martin On 1 November 2016 at 10:31, Peter Beverloo wrote: > Hi Martin, > > Thanks for the update and the proposal! > > I've reviewed these today, and have minor some points of feedback. I'll > deliberately avoid the topics of interoperability and upgrade cost here. > > First of all, this indeed vastly improves layering between the drafts. I > very much like how webpush-encryption is now built on top of encryption- > encoding as opposed to being some sort of fork. > >>> A push message MUST include a zero length keyid parameter in the >>> content coding header. This allows implementations to ignore the first >>> 21 octets of a push message. > > I don't think this is right. The `salt` and the `rs` must still be known, > and those are included in the header. > >>> A push service is not required to support more than 4096 octets of >>> payload body (see Section 7.2 of [I-D.ietf-webpush-protocol]), which >>> equates to at most 4059 octets of cleartext. > > I think this forgot about the padding -- > > 4096 - 16 (auth) - 2 (padding length) - 21 (header w/o keyid) = 4,057 > > May also want to s/cleartext/plaintext/ for consistency with encryption- > encoding. > >>> An Application Server MUST include exactly one aes128gcm content >>> coding, and at most one entry in the Crypto-Key field. This allows the >>> keyid parameter to be omitted. > > This means the draft is incompatible with VAPID again. It must have at > most one Crypto-Key entry that has a `dh` value. > > I haven't yet been able to validate the examples in the draft, but it > sounds like you're changing these anyway per jr's feedback (+1 to that). > > Thanks, > Peter > > > On Mon, Oct 31, 2016 at 11:19 PM, Martin Thomson > wrote: >> >> On 1 November 2016 at 10:07, jr conlin wrote: >> > One small comment, then? Can we change the transmitted Content-Encoding >> > type to match the new Content-type of "aes128gcm" instead of the long >> > abandoned "aesgcm128"? (See point #4) >> >> Ouch, that's going to hurt. I'll have to redo the examples :*( 40 >> minutes until the deadline, go! >> >> _______________________________________________ >> 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 --94eb2c0b8e6e243a270540411264 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Using the Crypto-Key = for vapid is fine with me - I have no problem with=C2=A0
keeping it for this purpose, in vapid spec. Or to use Crypto-Key in= =C2=A0
other specs that deal with key distrib= ution or other things.=C2=A0

However I still think that for consi= stency, the dh-public key used for decrypting
the message should be in the binary header, next to salt - maybe even
=C2=A0using the 'key id' field ( renamed = to 'symmetric key id or public key' ).=C2=A0
The binary blob should be sufficient to decode the message, if the= =C2=A0
content-encoding is known, using secre= ts known to the receiver ( symmetric=C2=A0
ke= y in http case, or EC private key for webpush ).

I think it's= important to recognize that client-to-pushservice communication
may use different transports, in addition to http/2 pus= h promises. In particular
it may be layered o= ver Webcoket, newly proposed WiSH, etc - and in many
cases the implementation will be greatly simplified if the binary b= lob can
be sent as-is (after any protocol-spe= cific authentication ).

Costin


= =C2=A0

On Mon, Oct 31, 2016 at 4:57 PM Ma= rtin Thomson <martin.thomson@gmail.com> wrote:
Hi Peter and JR,=

Thanks both for picking up on my stupid errors.=C2=A0 Hasty is not always careful enough, but I was working to a time limit.=C2=A0 With 5 minutes
left, I think that I managed to get all your input integrated.

And your reminder about vapid was timely.=C2=A0 I think that we can
dispense with any attempt to remove Crypto-Key, since we have to have
it for vapid anyway.

Now I need to think about getting the python implementation updated.

--Martin

On 1 November 2016 at 10:31, Peter Beverloo <beverloo@google.com&g= t; wrote:
> Hi Martin,
>
> Thanks for the update and the proposal!
>
> I've reviewed these today, and have minor some points of feedback.= I'll
> deliberately avoid the topics of interoperability and upgrade cost her= e.
>
> First of all, this indeed vastly improves layering between the drafts.= I
> very much like how webpush-encryption is now built on top of encryptio= n-
> encoding as opposed to being some sort of fork.
>
>>> A push message MUST include a zero length keyid parameter in t= he
>>> content coding header. This allows implementations to ignore t= he first
>>> 21 octets of a push message.
>
> I don't think this is right. The `salt` and the `rs` must still be= known,
> and those are included in the header.
>
>>> A push service is not required to support more than 4096 octet= s of
>>> payload body (see Section 7.2 of [I-D.ietf-webpush-protocol]),= which
>>> equates to at most 4059 octets of cleartext.
>
> I think this forgot about the padding --
>
>=C2=A0 =C2=A04096 - 16 (auth) - 2 (padding length) - 21 (header w/o key= id) =3D 4,057
>
> May also want to s/cleartext/plaintext/ for consistency with encryptio= n-
> encoding.
>
>>> An Application Server MUST include exactly one aes128gcm conte= nt
>>> coding, and at most one entry in the Crypto-Key field. This al= lows the
>>> keyid parameter to be omitted.
>
> This means the draft is incompatible with VAPID again. It must have at=
> most one Crypto-Key entry that has a `dh` value.
>
> I haven't yet been able to validate the examples in the draft, but= it
> sounds like you're changing these anyway per jr's feedback (+1= to that).
>
> Thanks,
> Peter
>
>
> On Mon, Oct 31, 2016 at 11:19 PM, Martin Thomson <martin.tho= mson@gmail.com>
> wrote:
>>
>> On 1 November 2016 at 10:07, jr conlin <jconlin@mozilla.com> wrote:
>> > One small comment, then? Can we change the transmitted Conten= t-Encoding
>> > type to match the new Content-type of "aes128gcm" i= nstead of the long
>> > abandoned "aesgcm128"? (See point #4)
>>
>> Ouch, that's going to hurt.=C2=A0 I'll have to redo the ex= amples :*(=C2=A0 40
>> minutes until the deadline, go!
>>
>> _______________________________________________
>> Webpush mailing list
>> Webpush@ietf.org
>> https://www.ietf.org/mailm= an/listinfo/webpush
>
>

_______________________________________________
Webpush mailing list
W= ebpush@ietf.org
https://www.ietf.org/mailman/listin= fo/webpush
--94eb2c0b8e6e243a270540411264-- From nobody Tue Nov 1 11:03:09 2016 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 DB62F129721 for ; Tue, 1 Nov 2016 11:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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] 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 pp1C30D5G3mT for ; Tue, 1 Nov 2016 11:03:04 -0700 (PDT) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (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 E743F12979D for ; Tue, 1 Nov 2016 11:03:03 -0700 (PDT) Received: by mail-yb0-x22a.google.com with SMTP id d128so73313550ybh.2 for ; Tue, 01 Nov 2016 11:03:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jObHx1jzkyLk1Wp7hLVpyyHpjXepRGHVz0Z8pFNB8QE=; b=02rrZOdds06ZQS5OWQlkSeISFI5rpdcXdVCWPR0SYnzVd/aOt1t6JHjTy8SlpzOm2g rrMRiFVvnrymoFsTbdizCujdWyV7b+IKiXlmrdYDpqbjp0n55teD1AfozIYfPVqQEbv1 +/fkxTt6BPuogpKKBFm6Z6lW4bBJXvRBUXALfrQHNf0a7QQbaDxDYVKDhgIPeFdCfI03 Ja65FagZY17ahjqfbnKYfzHtmn+rypkzZzV/eF5ds7NTb2qMnbLasrcC9RTDPcA0wnMR Tu2MRy/sDiGkqp+8vtFSjuzNqFg5QLG9KQ4EGo8CNv4MynSF5bhvJF/N2suh7j+uDwvu q1Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jObHx1jzkyLk1Wp7hLVpyyHpjXepRGHVz0Z8pFNB8QE=; b=EDWYisBPp3jj+38q5Ih0RaQQ5EutRFw4+My3zXw/WLoQiphDxrX+2pmXkQ59R2JZ3a 0vS1d5VBkDsp6UzEc3Qktet4amRdgquHBfJadvJdL2MtN9MQif2XqJEZAa6TyTakIL31 JdK253fb94ppyCHhvFoEMht+ON+Ikk8jKKjETJJJcsLwm5VbScUFkbt837kzzUYzBgtn 8R6FA9CnIXOpS5ZYyMHcCCgCff0nk4jDpYbk1kMx6lr9AGx24JHXK8eLLIH+c87oA+0R NRMlOU3eaRb0KEZaiNfEpYrzLg7s5mTXB3wb9oYVpHQo6Xh1cGYL36nIoFyjjjimI+Le B90w== X-Gm-Message-State: ABUngvfg/zvFxqPhpUY7FIMNuxB7CWcvL8EfQVZA4bmbsNMIVoZQxCwHDyDbm/zjD18Q4+bl86qslnBeb/KzRQ== X-Received: by 10.36.28.135 with SMTP id c129mr2088587itc.66.1478023382947; Tue, 01 Nov 2016 11:03:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Costin Manolache Date: Tue, 01 Nov 2016 18:02:52 +0000 Message-ID: To: Martin Thomson , Peter Beverloo Content-Type: multipart/alternative; boundary=001a11452876b5e14805404122a6 Archived-At: Cc: jr conlin , "webpush@ietf.org" Subject: Re: [Webpush] Major change to encryption X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 01 Nov 2016 18:03:08 -0000 --001a11452876b5e14805404122a6 Content-Type: text/plain; charset=UTF-8 I would also add that some of the bugs we've seen in our implementation were related to parsing and passing along the crypto key. Even for VAPID I would love to see the sender public key appended to the Authorization header somehow instead of in a separate Crypto-Key header. Costin On Tue, Nov 1, 2016 at 10:58 AM Costin Manolache wrote: > Using the Crypto-Key for vapid is fine with me - I have no problem with > keeping it for this purpose, in vapid spec. Or to use Crypto-Key in > other specs that deal with key distribution or other things. > > However I still think that for consistency, the dh-public key used for > decrypting > the message should be in the binary header, next to salt - maybe even > using the 'key id' field ( renamed to 'symmetric key id or public key' ). > The binary blob should be sufficient to decode the message, if the > content-encoding is known, using secrets known to the receiver ( symmetric > key in http case, or EC private key for webpush ). > > I think it's important to recognize that client-to-pushservice > communication > may use different transports, in addition to http/2 push promises. In > particular > it may be layered over Webcoket, newly proposed WiSH, etc - and in many > cases the implementation will be greatly simplified if the binary blob can > be sent as-is (after any protocol-specific authentication ). > > Costin > > > > > On Mon, Oct 31, 2016 at 4:57 PM Martin Thomson > wrote: > > Hi Peter and JR, > > Thanks both for picking up on my stupid errors. Hasty is not always > careful enough, but I was working to a time limit. With 5 minutes > left, I think that I managed to get all your input integrated. > > And your reminder about vapid was timely. I think that we can > dispense with any attempt to remove Crypto-Key, since we have to have > it for vapid anyway. > > Now I need to think about getting the python implementation updated. > > --Martin > > On 1 November 2016 at 10:31, Peter Beverloo wrote: > > Hi Martin, > > > > Thanks for the update and the proposal! > > > > I've reviewed these today, and have minor some points of feedback. I'll > > deliberately avoid the topics of interoperability and upgrade cost here. > > > > First of all, this indeed vastly improves layering between the drafts. I > > very much like how webpush-encryption is now built on top of encryption- > > encoding as opposed to being some sort of fork. > > > >>> A push message MUST include a zero length keyid parameter in the > >>> content coding header. This allows implementations to ignore the first > >>> 21 octets of a push message. > > > > I don't think this is right. The `salt` and the `rs` must still be known, > > and those are included in the header. > > > >>> A push service is not required to support more than 4096 octets of > >>> payload body (see Section 7.2 of [I-D.ietf-webpush-protocol]), which > >>> equates to at most 4059 octets of cleartext. > > > > I think this forgot about the padding -- > > > > 4096 - 16 (auth) - 2 (padding length) - 21 (header w/o keyid) = 4,057 > > > > May also want to s/cleartext/plaintext/ for consistency with encryption- > > encoding. > > > >>> An Application Server MUST include exactly one aes128gcm content > >>> coding, and at most one entry in the Crypto-Key field. This allows the > >>> keyid parameter to be omitted. > > > > This means the draft is incompatible with VAPID again. It must have at > > most one Crypto-Key entry that has a `dh` value. > > > > I haven't yet been able to validate the examples in the draft, but it > > sounds like you're changing these anyway per jr's feedback (+1 to that). > > > > Thanks, > > Peter > > > > > > On Mon, Oct 31, 2016 at 11:19 PM, Martin Thomson < > martin.thomson@gmail.com> > > wrote: > >> > >> On 1 November 2016 at 10:07, jr conlin wrote: > >> > One small comment, then? Can we change the transmitted > Content-Encoding > >> > type to match the new Content-type of "aes128gcm" instead of the long > >> > abandoned "aesgcm128"? (See point #4) > >> > >> Ouch, that's going to hurt. I'll have to redo the examples :*( 40 > >> minutes until the deadline, go! > >> > >> _______________________________________________ > >> 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 > > --001a11452876b5e14805404122a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would also add that some of the bugs we've seen in o= ur implementation=C2=A0
were related to parsing and passing along the c= rypto key. Even for=C2=A0
VAPID I would love to see the sender pu= blic key appended to the
Authorization header somehow instead of = in a separate Crypto-Key header.

Costin

On Tue, Nov 1, 2016 at 10:= 58 AM Costin Manolache <costin@gmail= .com> wrote:
Using the Crypto= -Key for vapid is fine with me - I have no problem with=C2=A0
keeping it for this purpose, in vapid spec. Or to use Crypto-Key= in=C2=A0
other specs that deal with key dist= ribution or other things.=C2=A0

However I still think that for co= nsistency, the dh-public key used for decrypting
the message should be in the binary header, next to salt - maybe even
=C2=A0using the 'key id' field ( renam= ed to 'symmetric key id or public key' ).=C2=A0
The binary blob should be sufficient to decode the message, if t= he=C2=A0
content-encoding is known, using sec= rets known to the receiver ( symmetric=C2=A0
= key in http case, or EC private key for webpush ).

I think it'= ;s important to recognize that client-to-pushservice communication
may use different transports, in addition to http/2 p= ush promises. In particular
it may be layered= over Webcoket, newly proposed WiSH, etc - and in many
cases the implementation will be greatly simplified if the binary= blob can
be sent as-is (after any protocol-s= pecific authentication ).

Costin


=C2=A0

On Mon, Oct 31, 2016= at 4:57 PM Martin Thomson <martin.thomson@gmail.com> wrot= e:
Hi= Peter and JR,

Thanks both for picking up on my stupid errors.=C2=A0 Hasty is not always careful enough, but I was working to a time limit.=C2=A0 With 5 minutes
left, I think that I managed to get all your input integrated.

And your reminder about vapid was timely.=C2=A0 I think that we can
dispense with any attempt to remove Crypto-Key, since we have to have
it for vapid anyway.

Now I need to think about getting the python implementation updated.

--Martin

On 1 November 2016 at 10:31, Peter Beverloo <beverloo@google.com&g= t; wrote:
> Hi Martin,
>
> Thanks for the update and the proposal!
>
> I've reviewed these today, and have minor some points of feedback.= I'll
> deliberately avoid the topics of interoperability and upgrade cost her= e.
>
> First of all, this indeed vastly improves layering between the drafts.= I
> very much like how webpush-encryption is now built on top of encryptio= n-
> encoding as opposed to being some sort of fork.
>
>>> A push message MUST include a zero length keyid parameter in t= he
>>> content coding header. This allows implementations to ignore t= he first
>>> 21 octets of a push message.
>
> I don't think this is right. The `salt` and the `rs` must still be= known,
> and those are included in the header.
>
>>> A push service is not required to support more than 4096 octet= s of
>>> payload body (see Section 7.2 of [I-D.ietf-webpush-protocol]),= which
>>> equates to at most 4059 octets of cleartext.
>
> I think this forgot about the padding --
>
>=C2=A0 =C2=A04096 - 16 (auth) - 2 (padding length) - 21 (header w/o key= id) =3D 4,057
>
> May also want to s/cleartext/plaintext/ for consistency with encryptio= n-
> encoding.
>
>>> An Application Server MUST include exactly one aes128gcm conte= nt
>>> coding, and at most one entry in the Crypto-Key field. This al= lows the
>>> keyid parameter to be omitted.
>
> This means the draft is incompatible with VAPID again. It must have at=
> most one Crypto-Key entry that has a `dh` value.
>
> I haven't yet been able to validate the examples in the draft, but= it
> sounds like you're changing these anyway per jr's feedback (+1= to that).
>
> Thanks,
> Peter
>
>
> On Mon, Oct 31, 2016 at 11:19 PM, Martin Thomson <martin.tho= mson@gmail.com>
> wrote:
>>
>> On 1 November 2016 at 10:07, jr conlin <jconlin@mozilla.com> wrote:
>> > One small comment, then? Can we change the transmitted Conten= t-Encoding
>> > type to match the new Content-type of "aes128gcm" i= nstead of the long
>> > abandoned "aesgcm128"? (See point #4)
>>
>> Ouch, that's going to hurt.=C2=A0 I'll have to redo the ex= amples :*(=C2=A0 40
>> minutes until the deadline, go!
>>
>> _______________________________________________
>> Webpush mailing list
>> Webpush@ietf.org
>> https://www.ietf.org/mailm= an/listinfo/webpush
>
>

_______________________________________________
Webpush mailing list
W= ebpush@ietf.org
https://www.ietf.org/mailman/listin= fo/webpush
--001a11452876b5e14805404122a6-- From nobody Tue Nov 1 12:46:27 2016 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 4AB3B129585 for ; Tue, 1 Nov 2016 12:46:25 -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 Kn3rXH5cB7ZT for ; Tue, 1 Nov 2016 12:46:23 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (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 0EE9D1299AC for ; Tue, 1 Nov 2016 12:46:23 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id i88so6607865pfk.2 for ; Tue, 01 Nov 2016 12:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=OEnJY4IxmBwrgpL4VX23OZNkGSdm8khPS8UdnSghrJI=; b=AqcGQWrVREYCASSrPof0Uw/03XeBOVmW4mpa6eKjsCZHocRlhyMJ221RqvT3ovbQpt BsedmUp0lRpJ3e0ZzD3zYYVYWdUFMjWgIHNnJ89zn9GS/SuES3kKuk9OBR5NH/Q1T6C/ TUu6eDN6zjnpnHZ2S0Y/GsRTmdLrIULrUYfYQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=OEnJY4IxmBwrgpL4VX23OZNkGSdm8khPS8UdnSghrJI=; b=NWjUAZLXZotqDyw8Gv2e9gnoL95rFxWg1j56JgFyC7jYyUXH/z/E51qcnEWi3qyhDs AnH6Y8jD8VTPVV5DbqBo4iJStG4tiX0Vi0s78sbklJhVxBaH3aP9a2fDZJT/GlEO4S0+ S6xnzDW2wf6nhImFr5JefD+77MDOuULcHVT1nBER9b+f2NhZ6cPv6wejDABv2sWx7Frc J535k4a8YeQEmo4ZWuynbHyUGLHICNxzL25dMWJw8YWBCZbLI79XhZgsleKVzGT53m5Q LYR5nrI6wI2cmE27m04A5b/RF/Gc2zd4GiUgnZ/tJNYToiOUqhzKOjGQQPTqzl3mtkN8 ZY6g== X-Gm-Message-State: ABUngvcOGz0zdGkWJQ3xJbPxHQKTNvne3kcvkb4rEJ0JHDlBWDYTGIpe6K6yOwrkiSPJwxkI X-Received: by 10.99.178.6 with SMTP id x6mr6821783pge.63.1478029582594; Tue, 01 Nov 2016 12:46:22 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:c1ce:f3d9:2ed1:18a1? ([2620:101:80fc:224:c1ce:f3d9:2ed1:18a1]) by smtp.gmail.com with ESMTPSA id k89sm44045777pfg.6.2016.11.01.12.46.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Nov 2016 12:46:21 -0700 (PDT) To: Costin Manolache , Martin Thomson , Peter Beverloo References: From: jr conlin Message-ID: <84f3da33-a9a4-1bbc-f290-e283cec07c22@mozilla.com> Date: Tue, 1 Nov 2016 12:46:21 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Thunderbird/51.0a2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D9FE41FECCA9B1A9F943684F" Content-Language: en-US Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Major change to encryption X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 01 Nov 2016 19:46:25 -0000 This is a multi-part message in MIME format. --------------D9FE41FECCA9B1A9F943684F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I'll agree that putting as much crypto in the message would be great. One thing to note is that when messages are delivered over bridged connections (like GCM/FCM or APNs) all that added content eats into the preciously small available delivery content. Particularly when you have to encode to base64 for JSON envelopes. We should strive to have as little required "prefix" content as possible, else folks wind up only able to send a few hundred bytes across. On 11/1/2016 10:58 AM, Costin Manolache wrote: > Using the Crypto-Key for vapid is fine with me - I have no problem with > keeping it for this purpose, in vapid spec. Or to use Crypto-Key in > other specs that deal with key distribution or other things. > > However I still think that for consistency, the dh-public key used for > decrypting > the message should be in the binary header, next to salt - maybe even > using the 'key id' field ( renamed to 'symmetric key id or public > key' ). > The binary blob should be sufficient to decode the message, if the > content-encoding is known, using secrets known to the receiver ( > symmetric > key in http case, or EC private key for webpush ). > > I think it's important to recognize that client-to-pushservice > communication > may use different transports, in addition to http/2 push promises. In > particular > it may be layered over Webcoket, newly proposed WiSH, etc - and in many > cases the implementation will be greatly simplified if the binary blob can > be sent as-is (after any protocol-specific authentication ). > > Costin > > > > > On Mon, Oct 31, 2016 at 4:57 PM Martin Thomson > > wrote: > > Hi Peter and JR, > > Thanks both for picking up on my stupid errors. Hasty is not always > careful enough, but I was working to a time limit. With 5 minutes > left, I think that I managed to get all your input integrated. > > And your reminder about vapid was timely. I think that we can > dispense with any attempt to remove Crypto-Key, since we have to have > it for vapid anyway. > > Now I need to think about getting the python implementation updated. > > --Martin > > On 1 November 2016 at 10:31, Peter Beverloo > wrote: > > Hi Martin, > > > > Thanks for the update and the proposal! > > > > I've reviewed these today, and have minor some points of > feedback. I'll > > deliberately avoid the topics of interoperability and upgrade > cost here. > > > > First of all, this indeed vastly improves layering between the > drafts. I > > very much like how webpush-encryption is now built on top of > encryption- > > encoding as opposed to being some sort of fork. > > > >>> A push message MUST include a zero length keyid parameter in the > >>> content coding header. This allows implementations to ignore > the first > >>> 21 octets of a push message. > > > > I don't think this is right. The `salt` and the `rs` must still > be known, > > and those are included in the header. > > > >>> A push service is not required to support more than 4096 octets of > >>> payload body (see Section 7.2 of [I-D.ietf-webpush-protocol]), > which > >>> equates to at most 4059 octets of cleartext. > > > > I think this forgot about the padding -- > > > > 4096 - 16 (auth) - 2 (padding length) - 21 (header w/o keyid) > = 4,057 > > > > May also want to s/cleartext/plaintext/ for consistency with > encryption- > > encoding. > > > >>> An Application Server MUST include exactly one aes128gcm content > >>> coding, and at most one entry in the Crypto-Key field. This > allows the > >>> keyid parameter to be omitted. > > > > This means the draft is incompatible with VAPID again. It must > have at > > most one Crypto-Key entry that has a `dh` value. > > > > I haven't yet been able to validate the examples in the draft, > but it > > sounds like you're changing these anyway per jr's feedback (+1 > to that). > > > > Thanks, > > Peter > > > > > > On Mon, Oct 31, 2016 at 11:19 PM, Martin Thomson > > > > wrote: > >> > >> On 1 November 2016 at 10:07, jr conlin > wrote: > >> > One small comment, then? Can we change the transmitted > Content-Encoding > >> > type to match the new Content-type of "aes128gcm" instead of > the long > >> > abandoned "aesgcm128"? (See point #4) > >> > >> Ouch, that's going to hurt. I'll have to redo the examples :*( 40 > >> minutes until the deadline, go! > >> > >> _______________________________________________ > >> 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 > --------------D9FE41FECCA9B1A9F943684F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
I'll agree that putting as much crypto in the message would be great. One thing to note is that when messages are delivered over bridged connections (like GCM/FCM or APNs) all that added content eats into the preciously small available delivery content. Particularly when you have to encode to base64 for JSON envelopes.

We should strive to have as little required "prefix" content as possible, else folks wind up only able to send a few hundred bytes across.

On 11/1/2016 10:58 AM, Costin Manolache wrote:
Using the Crypto-Key for vapid is fine with me - I have no problem with 
keeping it for this purpose, in vapid spec. Or to use Crypto-Key in 
other specs that deal with key distribution or other things. 

However I still think that for consistency, the dh-public key used for decrypting
the message should be in the binary header, next to salt - maybe even
 using the 'key id' field ( renamed to 'symmetric key id or public key' ). 
The binary blob should be sufficient to decode the message, if the 
content-encoding is known, using secrets known to the receiver ( symmetric 
key in http case, or EC private key for webpush ).

I think it's important to recognize that client-to-pushservice communication
may use different transports, in addition to http/2 push promises. In particular
it may be layered over Webcoket, newly proposed WiSH, etc - and in many
cases the implementation will be greatly simplified if the binary blob can
be sent as-is (after any protocol-specific authentication ).

Costin


 

On Mon, Oct 31, 2016 at 4:57 PM Martin Thomson <martin.thomson@gmail.com> wrote:
Hi Peter and JR,

Thanks both for picking up on my stupid errors.  Hasty is not always
careful enough, but I was working to a time limit.  With 5 minutes
left, I think that I managed to get all your input integrated.

And your reminder about vapid was timely.  I think that we can
dispense with any attempt to remove Crypto-Key, since we have to have
it for vapid anyway.

Now I need to think about getting the python implementation updated.

--Martin

On 1 November 2016 at 10:31, Peter Beverloo <beverloo@google.com> wrote:
> Hi Martin,
>
> Thanks for the update and the proposal!
>
> I've reviewed these today, and have minor some points of feedback. I'll
> deliberately avoid the topics of interoperability and upgrade cost here.
>
> First of all, this indeed vastly improves layering between the drafts. I
> very much like how webpush-encryption is now built on top of encryption-
> encoding as opposed to being some sort of fork.
>
>>> A push message MUST include a zero length keyid parameter in the
>>> content coding header. This allows implementations to ignore the first
>>> 21 octets of a push message.
>
> I don't think this is right. The `salt` and the `rs` must still be known,
> and those are included in the header.
>
>>> A push service is not required to support more than 4096 octets of
>>> payload body (see Section 7.2 of [I-D.ietf-webpush-protocol]), which
>>> equates to at most 4059 octets of cleartext.
>
> I think this forgot about the padding --
>
>   4096 - 16 (auth) - 2 (padding length) - 21 (header w/o keyid) = 4,057
>
> May also want to s/cleartext/plaintext/ for consistency with encryption-
> encoding.
>
>>> An Application Server MUST include exactly one aes128gcm content
>>> coding, and at most one entry in the Crypto-Key field. This allows the
>>> keyid parameter to be omitted.
>
> This means the draft is incompatible with VAPID again. It must have at
> most one Crypto-Key entry that has a `dh` value.
>
> I haven't yet been able to validate the examples in the draft, but it
> sounds like you're changing these anyway per jr's feedback (+1 to that).
>
> Thanks,
> Peter
>
>
> On Mon, Oct 31, 2016 at 11:19 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>>
>> On 1 November 2016 at 10:07, jr conlin <jconlin@mozilla.com> wrote:
>> > One small comment, then? Can we change the transmitted Content-Encoding
>> > type to match the new Content-type of "aes128gcm" instead of the long
>> > abandoned "aesgcm128"? (See point #4)
>>
>> Ouch, that's going to hurt.  I'll have to redo the examples :*(  40
>> minutes until the deadline, go!
>>
>> _______________________________________________
>> 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


--------------D9FE41FECCA9B1A9F943684F-- From nobody Tue Nov 1 18:01:10 2016 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 C68AE129438 for ; Tue, 1 Nov 2016 18:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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 wt2Es8cyeGRB for ; Tue, 1 Nov 2016 18:01:06 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 371EE127078 for ; Tue, 1 Nov 2016 18:01:06 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id e187so13206645itc.0 for ; Tue, 01 Nov 2016 18:01:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xe6O3nC+NqfW5qE/fDxGMJktGYSYxx6T5UFQbOucoKM=; b=ZugKe91eFN6EszjX5nQWeA6OOLGaly6fw6xuAhVTT6qA0gml76HuIA52cHlIgAA8C+ 2Mk9gn7B5nch/x1QZ4sEVrs1jMFoWTMzsZiZUPo3vm/0t+PwGfxfSdwM9ChfudWvojFt LDuaC1DtQRUeMIPg9hWCjGXmJnLRBenX6dB9n2ekzc7GQtvyiRSNfIfSlZaSy377nzQW 990M5rknqM7xPfOfrD0v3LI0fBzWWi3xWUm/tex4PG3i2pDOJ/EWnHEoipJAWCADBPr6 xz8V7uipMfB3h/Kc4WPbeNIop0ihz+7PGegP1pljWhnAF9rwjsCc2/vazvEJma0Wiz5I SIMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Xe6O3nC+NqfW5qE/fDxGMJktGYSYxx6T5UFQbOucoKM=; b=h3aH0BN6iYleteLEN1r6jZ+UvSbBOvPan8CwYKywMKkAtmFW4y3nOCDeWYP32ttpd2 q4FJ8wZmIgTmryblov+FSdLlsjcN+AejtRkcMrYAfGXWlN39K2tFjoMsA543h5Wkqzz5 pP4jhJaJxlgs6EGDqlLjkZ44AxWrFQQn9PsbpWILBWA2FUUcl3KZ43+lS5zKkZxleJHX RAAHwQue3S5ZQuf9foFea61wWSwlOZmRbBJYyxNcE4uHGZozi2ko7qXCwG7oxhSotxeu dZToMEKSNDZ8iUrNULCkLSO327TqybsPVV1i+Nqg3L4PyTx0kGosybm9EZxarmc6tqDb iz3g== X-Gm-Message-State: ABUngvfULlccnvAdaXVY5j2xjGaLIQkF7aoxYelW9RfvKng5qtAOQczxajC3SPKsImnnDU7ldZ7aBRQgkpl7+Q== X-Received: by 10.36.28.135 with SMTP id c129mr599189itc.66.1478048465551; Tue, 01 Nov 2016 18:01:05 -0700 (PDT) MIME-Version: 1.0 References: <84f3da33-a9a4-1bbc-f290-e283cec07c22@mozilla.com> In-Reply-To: <84f3da33-a9a4-1bbc-f290-e283cec07c22@mozilla.com> From: Costin Manolache Date: Wed, 02 Nov 2016 01:00:54 +0000 Message-ID: To: jr conlin , Martin Thomson , Peter Beverloo Content-Type: multipart/alternative; boundary=001a11452876c006f4054046f9ab Archived-At: Cc: "webpush@ietf.org" Subject: Re: [Webpush] Major change to encryption X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 02 Nov 2016 01:01:09 -0000 --001a11452876c006f4054046f9ab Content-Type: text/plain; charset=UTF-8 Yes, when sending over GCM it's better to have the 65bytes of the key in the binary prefix of the "raw_data" byte[] instead of having to add another key/value pair, with the b64 encoding and proto overhead. But it's an optimization - not the main reason :-). A nice extra benefit is that browsers on android could dispatch the message based on the raw_data only, since the EC public key can identify the app/SW. Costin On Tue, Nov 1, 2016 at 12:46 PM jr conlin wrote: > I'll agree that putting as much crypto in the message would be great. One > thing to note is that when messages are delivered over bridged connections > (like GCM/FCM or APNs) all that added content eats into the preciously > small available delivery content. Particularly when you have to encode to > base64 for JSON envelopes. > > We should strive to have as little required "prefix" content as possible, > else folks wind up only able to send a few hundred bytes across. > > > On 11/1/2016 10:58 AM, Costin Manolache wrote: > > Using the Crypto-Key for vapid is fine with me - I have no problem with > keeping it for this purpose, in vapid spec. Or to use Crypto-Key in > other specs that deal with key distribution or other things. > > However I still think that for consistency, the dh-public key used for > decrypting > the message should be in the binary header, next to salt - maybe even > using the 'key id' field ( renamed to 'symmetric key id or public key' ). > The binary blob should be sufficient to decode the message, if the > content-encoding is known, using secrets known to the receiver ( symmetric > key in http case, or EC private key for webpush ). > > I think it's important to recognize that client-to-pushservice > communication > may use different transports, in addition to http/2 push promises. In > particular > it may be layered over Webcoket, newly proposed WiSH, etc - and in many > cases the implementation will be greatly simplified if the binary blob can > be sent as-is (after any protocol-specific authentication ). > > Costin > > > > > On Mon, Oct 31, 2016 at 4:57 PM Martin Thomson > wrote: > > Hi Peter and JR, > > Thanks both for picking up on my stupid errors. Hasty is not always > careful enough, but I was working to a time limit. With 5 minutes > left, I think that I managed to get all your input integrated. > > And your reminder about vapid was timely. I think that we can > dispense with any attempt to remove Crypto-Key, since we have to have > it for vapid anyway. > > Now I need to think about getting the python implementation updated. > > --Martin > > On 1 November 2016 at 10:31, Peter Beverloo wrote: > > Hi Martin, > > > > Thanks for the update and the proposal! > > > > I've reviewed these today, and have minor some points of feedback. I'll > > deliberately avoid the topics of interoperability and upgrade cost here. > > > > First of all, this indeed vastly improves layering between the drafts. I > > very much like how webpush-encryption is now built on top of encryption- > > encoding as opposed to being some sort of fork. > > > >>> A push message MUST include a zero length keyid parameter in the > >>> content coding header. This allows implementations to ignore the first > >>> 21 octets of a push message. > > > > I don't think this is right. The `salt` and the `rs` must still be known, > > and those are included in the header. > > > >>> A push service is not required to support more than 4096 octets of > >>> payload body (see Section 7.2 of [I-D.ietf-webpush-protocol]), which > >>> equates to at most 4059 octets of cleartext. > > > > I think this forgot about the padding -- > > > > 4096 - 16 (auth) - 2 (padding length) - 21 (header w/o keyid) = 4,057 > > > > May also want to s/cleartext/plaintext/ for consistency with encryption- > > encoding. > > > >>> An Application Server MUST include exactly one aes128gcm content > >>> coding, and at most one entry in the Crypto-Key field. This allows the > >>> keyid parameter to be omitted. > > > > This means the draft is incompatible with VAPID again. It must have at > > most one Crypto-Key entry that has a `dh` value. > > > > I haven't yet been able to validate the examples in the draft, but it > > sounds like you're changing these anyway per jr's feedback (+1 to that). > > > > Thanks, > > Peter > > > > > > On Mon, Oct 31, 2016 at 11:19 PM, Martin Thomson < > martin.thomson@gmail.com> > > wrote: > >> > >> On 1 November 2016 at 10:07, jr conlin wrote: > >> > One small comment, then? Can we change the transmitted > Content-Encoding > >> > type to match the new Content-type of "aes128gcm" instead of the long > >> > abandoned "aesgcm128"? (See point #4) > >> > >> Ouch, that's going to hurt. I'll have to redo the examples :*( 40 > >> minutes until the deadline, go! > >> > >> _______________________________________________ > >> 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 > > > --001a11452876c006f4054046f9ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, when sending over GCM it's better to have the 65b= ytes of the key in the binary prefix of the=C2=A0
"raw_data" = byte[] instead of having to add another key/value pair, with the b64 encodi= ng and proto=C2=A0
overhead. But it's an optimization - not t= he main reason :-). A nice extra benefit is that browsers on android
<= div>could dispatch the message based on the raw_data only, since the EC pub= lic key can identify the app/SW.

Costin
=

=C2=A0

On Tue, Nov 1, 2016 at 12:46 PM jr conlin <jconlin@mozilla.com> wrote:
=20 =20 =20
I'll= agree that putting as much crypto in the message would be great. One thing to note is that when messages are delivered over bridged connections (like GCM/FCM or APNs) all that added content eats into the preciously small available delivery content. Particularly when you have to encode to base64 for JSON envelopes.

We should strive to have as little required "prefix" conten= t as possible, else folks wind up only able to send a few hundred bytes across.
=

On 11/1/2016 10:58 AM, Costin Manolache wrote:
Using the Crypto-Key for vapid is fine with me - I have no problem with=C2=A0
keeping it for this purpose, in vapid spec. Or to use Crypto-Key in=C2=A0
other specs that deal with key distribution or other things.=C2=A0

However I still think that for consistency, the dh-public key used for decrypting
the message should be in the binary header, next to salt - maybe even
=C2=A0using the 'key id' field (= renamed to 'symmetric key id or public key' ).=C2=A0
The binary blob should be sufficient to decode the message, if the=C2=A0
content-encoding is known, using secrets known to the receiver ( symmetric=C2=A0
key in http case, or EC private key for webpush ).

I think it's important to recognize that client-to-pushservice communication
may use different transports, in addition to http/2 push promises. In particular
it may be layered over Webcoket, newly proposed WiSH, etc - and in many
cases the implementation will be greatly simplified if the binary blob can
be sent as-is (after any protocol-specific authentication ).

Costin


=C2=A0

On Mon, Oct 31, 2016 at 4:57 PM Martin Thomson <martin.thomson@gmail.com> wrote:
Hi Peter and JR,

Thanks both for picking up on my stupid errors.=C2=A0 Hasty is not always
careful enough, but I was working to a time limit.=C2=A0 With 5 minutes
left, I think that I managed to get all your input integrated.

And your reminder about vapid was timely.=C2=A0 I think that we can
dispense with any attempt to remove Crypto-Key, since we have to have
it for vapid anyway.

Now I need to think about getting the python implementation updated.

--Martin

On 1 November 2016 at 10:31, Peter Beverloo <beverloo@goog= le.com> wrote:
> Hi Martin,
>
> Thanks for the update and the proposal!
>
> I've reviewed these today, and have minor some points of feedback. I'll
> deliberately avoid the topics of interoperability and upgrade cost here.
>
> First of all, this indeed vastly improves layering between the drafts. I
> very much like how webpush-encryption is now built on top of encryption-
> encoding as opposed to being some sort of fork.
>
>>> A push message MUST include a zero length keyid parameter in the
>>> content coding header. This allows implementations to ignore the first
>>> 21 octets of a push message.
>
> I don't think this is right. The `salt` and the `rs` must still be known,
> and those are included in the header.
>
>>> A push service is not required to support more than 4096 octets of
>>> payload body (see Section 7.2 of [I-D.ietf-webpush-protocol]), which
>>> equates to at most 4059 octets of cleartext.
>
> I think this forgot about the padding --
>
>=C2=A0 =C2=A04096 - 16 (auth) - 2 (padding length) - 21 (he= ader w/o keyid) =3D 4,057
>
> May also want to s/cleartext/plaintext/ for consistency with encryption-
> encoding.
>
>>> An Application Server MUST include exactly one aes128gcm content
>>> coding, and at most one entry in the Crypto-Key field. This allows the
>>> keyid parameter to be omitted.
>
> This means the draft is incompatible with VAPID again. It must have at
> most one Crypto-Key entry that has a `dh` value.
>
> I haven't yet been able to validate the examples in th= e draft, but it
> sounds like you're changing these anyway per jr's feedback (+1 to that).
>
> Thanks,
> Peter
>
>
> On Mon, Oct 31, 2016 at 11:19 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>>
>> On 1 November 2016 at 10:07, jr conlin <jconlin@m= ozilla.com> wrote:
>> > One small comment, then? Can we change the transmitted Content-Encoding
>> > type to match the new Content-type of "aes128gcm" instead of the long
>> > abandoned "aesgcm128"? (See point #4) >>
>> Ouch, that's going to hurt.=C2=A0 I'll have to= redo the examples :*(=C2=A0 40
>> minutes until the deadline, go!
>>
>> _______________________________________________
>> Webpush mailing list
>> Webpush@ietf.org
>> https://www.ie= tf.org/mailman/listinfo/webpush
>
>

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


--001a11452876c006f4054046f9ab-- From nobody Tue Nov 1 20:50:12 2016 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 B21661294D5 for ; Tue, 1 Nov 2016 20:50:11 -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, FREEMAIL_FROM=0.001, 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 rfj4ZNA25CA8 for ; Tue, 1 Nov 2016 20:50:10 -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 904AE129404 for ; Tue, 1 Nov 2016 20:50:10 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id o68so4317440qkf.3 for ; Tue, 01 Nov 2016 20:50:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XVo2tP4p3t6Bjo771IcH5NzzMaktmMzqyM2i4jc4k+0=; b=d8MIMIYKLHc1Bcx+8JYHKafMVOlZ1qHDYGrhACkRMCTt1+7W9yAAa2p5C8QhRPkOPi alHXdkl0Bc+nbQxbCHtXhmUG7jcpORbOCCUf2klVm8S8hfwzvoRZPlQVK1dpvDmbqke5 A7TcUk0NYoWi1AoCkUSNxw8eNp5o4yndOkOEdP+3TR+Aeku9cuR/gfcaG5x8rOwbs0cz GEMrQjwazc1sI+HpKmdb8R/wxl6dTf4rlRfxXdPsDHHmNf10THKNHCykXdljvmzXtBSL u9cGDTeLf/u+uWSK1C7/fQ5o5NrMGKnzeN3TUaEaGe/z+cdlZq2xtsNIX3RDeTta6hdP bFVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XVo2tP4p3t6Bjo771IcH5NzzMaktmMzqyM2i4jc4k+0=; b=FinR25BikNRT3x4AYx4rQec+rXQd2MK+pP69e7pe2P7O2GnbhHQ5Ia/M9Wn1kc+fBp XLDI9K4Mp37EcQxUxiqICQryyo4s62XFC11astLM3s53r1WTRJUCPkDjzUshEfKwlVu8 apQKJDFbeBvFfkO92vikFS44+WKNo3P6SV/VLVfkcUQLuMVeWF2DMZztRXGFmTj0PCqw YbOLhuH87SRtxTtcJSKI0kNkNf6H60KqqRevUo5T6ISfobD4YfbT221LJ7Z6XETmdbrY oyH7ezb1Mzzq4YMGbGBvkKlRlbzh3tGc5BVWXAk7m1QhwIxThrg0QuPmYm5rW9Vwm70F bL0w== X-Gm-Message-State: ABUngvf7Ob3kwJZHbJ1XxIeuwaXEEDtWnpKKEH611ETaqxaqkk8W2e84Zu3/2Q7xeJCzWG6hOb2xITPwXKhH3g== X-Received: by 10.55.155.151 with SMTP id d145mr1249847qke.115.1478058609791; Tue, 01 Nov 2016 20:50:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Tue, 1 Nov 2016 20:50:09 -0700 (PDT) In-Reply-To: References: <84f3da33-a9a4-1bbc-f290-e283cec07c22@mozilla.com> From: Martin Thomson Date: Wed, 2 Nov 2016 14:50:09 +1100 Message-ID: To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: jr conlin , "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Major change to encryption X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 02 Nov 2016 03:50:12 -0000 On 2 November 2016 at 12:00, Costin Manolache wrote: > Yes, when sending over GCM it's better to have the 65bytes of the key in the > binary prefix of the > "raw_data" byte[] instead of having to add another key/value pair, with the > b64 encoding and proto > overhead. But it's an optimization - not the main reason :-). A nice extra > benefit is that browsers on android > could dispatch the message based on the raw_data only, since the EC public > key can identify the app/SW. As I said, I'm not opposed to this, it just seems wrong. Moving the public key into the body will cut into message budgets. We'll be at 3994 octets of plaintext maximum if we do that. One of the nice things with the header field is that users don't pay for it. The bad thing is that the server needs to find a way to move it. If we are going to make this change, we need to be very crisp about it. From nobody Tue Nov 1 20:55:54 2016 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 012E41294D5 for ; Tue, 1 Nov 2016 20:55:53 -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 EFMIRh2a0inD for ; Tue, 1 Nov 2016 20:55:51 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 92E9F1293EE for ; Tue, 1 Nov 2016 20:55:51 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id x190so2709468qkb.0 for ; Tue, 01 Nov 2016 20:55:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=TQEMvBTuvQGbF8RDiKnRatTOs+x3CaJpZ1D7JSrasik=; b=gCyDMQQhL4ys9H05/c9mK8hlzL1nEntjqAvsFplh3z/UT9zlrTmwD/J8tHA/jXhUdD LQrd3c2oA8qi/+Z0CGLvZVAxF4tR8STRy/A4dHXAaIkMeaEjdWCpGOWt8vVDA0akp9y2 Q1+Oo/0785YjiUt9EjMi5QadkI8uWbed3Det4y99FQGxunnDjMoqrHICLNFtJfB1PCbB TVfVK9M3drt2z3IA0f/n2kmJX5XifNojGGwrXcL6DV0cl9JlocaKWrYUjDnNjs3S4Pr1 V301RCd0c7l28KDBO1qRv+gwQNS8FfykiD2z2tpJq2lUNDhv4J9hX8f90xq92P0UP/9r 3/cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=TQEMvBTuvQGbF8RDiKnRatTOs+x3CaJpZ1D7JSrasik=; b=FvLuRaIsBuN+1stXqaV5Eoars7SApKHQqv2umnkGxQpVHmuB3K+shi4ryGta6L7gmV ZVIZzTY9TX4V5HvXEz4hPUMQ6IfjbX+Y0ZKbzc4QF9r/MHOF/92d2UGKjoNE7Awp1b1P 2nG3CUDCkE2KXsAd93jidm+agFW8Gr2aCo6RCcNmDEPxeZtXAtFHWnmKOl9+6lQufWMi vzBipnL1T2Z0iGKUldQ8fbLJ2W3/A9737hE+QA+rJJaAXko9UkiRQ37CjLTZv2Fyp62r V7YO9hlMnWOXYeKxuLDLQxBsd4pvi1ysrNJi8DXv49NUlB0MRupFJ00jSRSFzwW8kZdV EBeQ== X-Gm-Message-State: ABUngvcPO/3B0z806v4tIw418gmaC4+hPvlS5/Rs76Ma3uZbWa2pYSmPyUPrg/iadl1zFSc+cGgXo7aeKNJyPQ== X-Received: by 10.55.155.151 with SMTP id d145mr1262436qke.115.1478058950728; Tue, 01 Nov 2016 20:55:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Tue, 1 Nov 2016 20:55:50 -0700 (PDT) From: Martin Thomson Date: Wed, 2 Nov 2016 14:55:50 +1100 Message-ID: To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: jr conlin , "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Vapid public key X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 02 Nov 2016 03:55:53 -0000 On 2 November 2016 at 05:02, Costin Manolache wrote: > I would also add that some of the bugs we've seen in our implementation > were related to parsing and passing along the crypto key. Even for > VAPID I would love to see the sender public key appended to the > Authorization header somehow instead of in a separate Crypto-Key header. Putting the public key in the JWT header is probably doable, but it means double base64 encoding for key. I'd want to hear that people are OK with it before making a change. Note that this is probably a net increase in header size (I make it to be a 22 octet increase, even losing the Crypto-Key header field entirely). Header size probably isn't that important on this request though. From nobody Tue Nov 1 21:02:23 2016 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 33400129468 for ; Tue, 1 Nov 2016 21:02:21 -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 WYhZiydk0doh for ; Tue, 1 Nov 2016 21:02:19 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 7AFA51293EE for ; Tue, 1 Nov 2016 21:02:19 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id p190so242224394wmp.1 for ; Tue, 01 Nov 2016 21:02:19 -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=Y0UPnHdLs9DcXW8MNeVG9fRwcKNdYAakIAsVThQIidc=; b=WXjGliA6hRz6lokwavNfOKflTGu18nJF4Q76muomuX+ahku2Eiph8as2jCsNuitKaM aFfUcFG4RZe18egG6ePBaYSSvfdxHXzVHx7lYot+RsfQH5rPerAPJgxfgFDsrWaIihs3 llXN84NtOMgzkXmNXsH2JuCqM44Ju45d7p6zg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=Y0UPnHdLs9DcXW8MNeVG9fRwcKNdYAakIAsVThQIidc=; b=big/K9Hl+CF72K4nrnoEQia6LKxhZYVN440nctBZwXpyDhFp9XHQVs5fEA/HFMffAj RtPHztfBkjyJSr4tv8O6if4PKQwA+phnRUBC5ZAzM4hB+3m2nT3xqizFol/6GHxinQNO EGutSbI5VWJ/UaKskZbhCE/RJpfZsQeq/DfEv6jGzqhnBzaa5a1KdYTM98Ni5Fnrt78W Uccbd5jcCWpWdH5t+p8IdQXOfkXEMluFhfAuq5ku4lQxkjKgR7EyWJH5Zc3bcKrqQ6TS HOUbjEbWQDSxMq29wFlyIVRsmM25ahd/DGlYiWXbzC342zxsbhYoozzhBxIJrIO/Xqs+ f9pQ== X-Gm-Message-State: ABUngve95DQ1nJXR6qDfK8UVpYc33ulk4h+r0QPvh7z9qGrE0vNcmQujleIhpRCyxBxJ9KKpNU7DKz5G4wgYWV3j X-Received: by 10.194.176.40 with SMTP id cf8mr1005922wjc.68.1478059338041; Tue, 01 Nov 2016 21:02:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.24.21 with HTTP; Tue, 1 Nov 2016 21:02:17 -0700 (PDT) In-Reply-To: References: <84f3da33-a9a4-1bbc-f290-e283cec07c22@mozilla.com> From: JR Conlin Date: Tue, 1 Nov 2016 21:02:17 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=089e013d19f6cd2b5b0540498112 Archived-At: Cc: Costin Manolache , "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Major change to encryption X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jrconlin@mozilla.com 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: Wed, 02 Nov 2016 04:02:21 -0000 --089e013d19f6cd2b5b0540498112 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BOn Tue, Nov 1, 2016 at 8:50 PM, Martin Thomson wrote: > Moving the public key into the body will cut into message budgets. > We'll be at 3994 octets of plaintext maximum if we do that. > =E2=80=8B=E2=80=8B =E2=80=8BI'm a bit confused about that. For "native" networks, push servers= have pretty wide tolerances for how much data that they can send over their pipes. Going between services, I can definitely understand, since you're held to the limits of the provider system. (APNs limits to about 2K, so users are kinda screwed worse.) Of course, with "bridged" systems like those, you still have to deal with the host system, so "headers" aren't free. You still have to encode the data into the body of the message in some fashion, which eats into the available amount. Worst of all, is that those bridged systems are also unreliable for hosts of reasons and then you're re-implementing TCP with one hand tied behind your back.=E2=80=8B Granted, I've got a pretty limited viewpoint, so I'm sure I'm missing something obvious. On Tue, Nov 1, 2016 at 8:50 PM, Martin Thomson wrote: > On 2 November 2016 at 12:00, Costin Manolache wrote: > > Yes, when sending over GCM it's better to have the 65bytes of the key i= n > the > > binary prefix of the > > "raw_data" byte[] instead of having to add another key/value pair, with > the > > b64 encoding and proto > > overhead. But it's an optimization - not the main reason :-). A nice > extra > > benefit is that browsers on android > > could dispatch the message based on the raw_data only, since the EC > public > > key can identify the app/SW. > > As I said, I'm not opposed to this, it just seems wrong. > > Moving the public key into the body will cut into message budgets. > We'll be at 3994 octets of plaintext maximum if we do that. One of > the nice things with the header field is that users don't pay for it. > The bad thing is that the server needs to find a way to move it. > > If we are going to make this change, we need to be very crisp about it. > --089e013d19f6cd2b5b0540498112 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8BOn Tue, Nov 1, 2016 at 8:50 PM, Martin Thomson <martin.= thomson@gmail.com> wrote:
= Moving the public key into the body will cut into message budgets.
We'll be at 3994 octets of plaintext maximum if we do that.=C2=A0
=
=E2=80=8B=E2=80=8B

=E2=80=8BI'm a bit confused about that. For "native" networks, push servers h= ave=20 pretty wide tolerances for how much data that they can send over their=20 pipes. Going between services, I can definitely understand, since you'r= e held to the limits of the provider system. (APNs limits to about 2K, so users are kinda screwed worse.) Of course, with "bridged" system= s like=20 those, you still have to deal with the host system, so "headers" = aren't=20 free. You still have to encode the data into the body of the message in=20 some fashion, which eats into the available amount.=C2=A0

Worst of all, is that those bridged systems are also unreliable for hosts of=20 reasons and then you're re-implementing TCP with one hand tied behind= =20 your back.=E2=80=8B

Granted, I've got a pretty limited viewpoint, so I&#= 39;m sure I'm missing something obvious.

On Tue, Nov 1, 2016 = at 8:50 PM, Martin Thomson <martin.thomson@gmail.com>= wrote:
On 2 November 20= 16 at 12:00, Costin Manolache <costi= n@gmail.com> wrote:
> Yes, when sending over GCM it's better to have the 65bytes of the = key in the
> binary prefix of the
> "raw_data" byte[] instead of having to add another key/value= pair, with the
> b64 encoding and proto
> overhead. But it's an optimization - not the main reason :-). A ni= ce extra
> benefit is that browsers on android
> could dispatch the message based on the raw_data only, since the EC pu= blic
> key can identify the app/SW.

As I said, I'm not opposed to this, it just seems wrong.

Moving the public key into the body will cut into message budgets.
We'll be at 3994 octets of plaintext maximum if we do that.=C2=A0 One o= f
the nice things with the header field is that users don't pay for it. The bad thing is that the server needs to find a way to move it.

If we are going to make this change, we need to be very crisp about it.

--089e013d19f6cd2b5b0540498112-- From nobody Tue Nov 1 21:25:47 2016 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 B3364129551 for ; Tue, 1 Nov 2016 21:25:45 -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 3pnQLqH72ZiC for ; Tue, 1 Nov 2016 21:25:44 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 5A6D71293EE for ; Tue, 1 Nov 2016 21:25:44 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id x190so3236128qkb.0 for ; Tue, 01 Nov 2016 21:25:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Yw7uvpGjLK/pP+Rpun5IipB+6ZRpk5QglGZd/nKIhI8=; b=Z6o0wvwkQfZhTc6naElA6SlLmZCmbBG3mTSjARU4XdwDf6iunlR1Uw0tT2pEW427mC JtjF3mYZwGhw6W9k9C8tVae/YdSkIo3jeP5s0i5823zg0fiC/7Kbz2YIF7B8hsNN68YM n3SjYrbxVjCB3zBTRy4P9sKHC0UQrTrZx6garcoguf7fnaWcufLTas8aAXXMlEexcQts T4e0oQ1rP7mpTTdAN0on5WDy8NZPKRD6xoNshhDSWlDOx1Q+UpGEH7I+6NpUTz5nsyxU Oi7p3qArM70nrRKZPqdE2RsquYjbYm4JS82w3FmFzptOT6nyamUnJ1K0jPNk0Ff6kJR5 A2BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Yw7uvpGjLK/pP+Rpun5IipB+6ZRpk5QglGZd/nKIhI8=; b=X44FV+6msVcAGf+VlXhIOPIadQgZR1ExZwG2X2rFsnMiRxPiQeWLkjnp2ZT3ZDRW7C F1399391fDTiu6Ri6JMYXXkVYrcMg8VIuDGEhyUO4LHNoWkpn6PxjnuoS7NDS6CXQ7dm wY25QZRalACWZgeuNswzrnPpw9T+teU74lg28BP63zAu9xdtghA2Z7VHA6sVOuy8n1iR siOdMQO3kPIVCIBG1cwL/KdI4CbEay+F2B2H21QkKmAvAbozbphejJ7RtetBPIB0jNYH r+G3TEv2SvsdGz6fA/lOs8c3SJZJYqOLMbU+RWL8nMRTZXC1AUGyfouYWDShKJsZR4Xf Q6Vw== X-Gm-Message-State: ABUngve/Yj1ZxXJK1THZ3Nj0X3nZC2Igv2tABy66dA4h+kuw4e7n62eZgU1OPK6BB3jaVYXzYElCTDsNyAZvgA== X-Received: by 10.55.158.199 with SMTP id h190mr1486197qke.202.1478060743559; Tue, 01 Nov 2016 21:25:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Tue, 1 Nov 2016 21:25:42 -0700 (PDT) In-Reply-To: References: <84f3da33-a9a4-1bbc-f290-e283cec07c22@mozilla.com> From: Martin Thomson Date: Wed, 2 Nov 2016 15:25:42 +1100 Message-ID: To: JR Conlin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Costin Manolache , "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Major change to encryption X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 02 Nov 2016 04:25:46 -0000 On 2 November 2016 at 15:02, JR Conlin wrote: > I'm a bit confused about that. For "native" networks, push servers have > pretty wide tolerances for how much data that they can send over their > pipes. Going between services, I can definitely understand, since you're > held to the limits of the provider system. (APNs limits to about 2K, so > users are kinda screwed worse.) Of course, with "bridged" systems like > those, you still have to deal with the host system, so "headers" aren't > free. You still have to encode the data into the body of the message in some > fashion, which eats into the available amount. > > Worst of all, is that those bridged systems are also unreliable for hosts of > reasons and then you're re-implementing TCP with one hand tied behind your > back. > > Granted, I've got a pretty limited viewpoint, so I'm sure I'm missing > something obvious. If you intend to implement this over APNS, then you are stuck, I agree. Unless you fragment (and reassembly is ugly). In the end, the point is to create a consistent experience for users of the API, we need to pick a point that works. Currently, the keys go into the "overhead" bucket: stuff that the push service has to wear above the 4k message size. Moving the key into the message is just moving things around, but it does mean that users of the API get even less space to play with than before. I guess you could say that we're stealing 21 octets already, why not make it 85? From nobody Tue Nov 1 21:43:39 2016 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 593F3129599 for ; Tue, 1 Nov 2016 21:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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 79GIGyYy1H0s for ; Tue, 1 Nov 2016 21:43:36 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 737A21293E8 for ; Tue, 1 Nov 2016 21:43:36 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id e187so65528097itc.0 for ; Tue, 01 Nov 2016 21:43:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tgijUd2KOX5iNOoskkyi5he3GsO+lliUnj/HmUwXEiY=; b=UR3mT5gUYDzSma1x4LzY/TxQ6JXwPO08ZyPfY+e9jZCqhpQ4ZgU/Rx3/Y2o8GPCUrF /aMa7NWVnK9VHV3Gh+KTvd0bnQkE7qSJkmEcdql3wNMTcbhbSoUSBisyopF2CW2vMVUg 1kttXnsLxkcXchs8T4BtTwF6EwE0qwZ7cal+0N5EW43TWIIZdKgc4o7DJEx6FYsqDNPb 2YbIMi+rfIwpaSDRxw5zdz8K+sN/ifz4PDLNhShF0Kz9i0yMS5IRrHDvBaa/4/nMuftv sT+TKboMBywll9lIqDjIRn4DfGOw7m1OFS6h/JqE5ZuTWzl49SHa0K4endMPeGzZji8+ BBTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tgijUd2KOX5iNOoskkyi5he3GsO+lliUnj/HmUwXEiY=; b=BTBnvDPWvQ578Y+aVa+WFTc6SYhATbN4JX+qWDWpiz4q3+9zW1K8rc0ru8zvukNzqz uIMDYnUj1ykeFjR4Je2IRmGDe8Hl3W5EJGkbAhXRKWZmNenVSyXuattu+0pkvdmYiKv2 xnRTjJfS0iwGouKAjqVHaBjxAWz2Us7usc1c2YDnyCWZ/ocf4KzBIFLhlNbeTZuRoh9m KpjTP1nOFJK9XhPZIXG7TV9QPrBUOBLZePXDqjjZv/L75kGH3YuBlUL6yFhkWJEhQeUj 8ti2Yq+iTk5DdNBeuc7bbfHHHt6OgHx8vvC3s2+3p7bpjcVTOPfOg9b4stXkR3ZWq3mA 0nkg== X-Gm-Message-State: ABUngvevvh19RwyHYTZ2miQD9cd2QMr9FAD09GMSPUnyBdJ/qnW03YRmOe4cWbv11fOlw40E7k8fUihnnQ3Q/g== X-Received: by 10.36.101.143 with SMTP id u137mr1109894itb.66.1478061815725; Tue, 01 Nov 2016 21:43:35 -0700 (PDT) MIME-Version: 1.0 References: <84f3da33-a9a4-1bbc-f290-e283cec07c22@mozilla.com> In-Reply-To: From: Costin Manolache Date: Wed, 02 Nov 2016 04:43:25 +0000 Message-ID: To: jrconlin@mozilla.com, Martin Thomson Content-Type: multipart/alternative; boundary=001a114949127b86a505404a155f Archived-At: Cc: "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Major change to encryption X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 02 Nov 2016 04:43:38 -0000 --001a114949127b86a505404a155f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable AFAIK the "DH" public key must be sent to the device no matter what. Right now for GCM, if you use the webpush endpoint the headers end up in the key/value pairs, as base64, while the binary data goes in the raw_data. I have no problem if the spec defines that the binary header should be excluded - and push services support 4k of real data ( i.e. continue to exclude the header overhead). If transmitting over other transports - somehow we need to send the dh public key and the body - if it doesn't fit a tickle+poll or segmentation need to be used. The fact the public key was received in a header or was part of the body doesn't change this. Costin On Tue, Nov 1, 2016 at 9:02 PM JR Conlin wrote: > =E2=80=8BOn Tue, Nov 1, 2016 at 8:50 PM, Martin Thomson > wrote: > > Moving the public key into the body will cut into message budgets. > We'll be at 3994 octets of plaintext maximum if we do that. > > =E2=80=8B=E2=80=8B > > =E2=80=8BI'm a bit confused about that. For "native" networks, push serve= rs have > pretty wide tolerances for how much data that they can send over their > pipes. Going between services, I can definitely understand, since you're > held to the limits of the provider system. (APNs limits to about 2K, so > users are kinda screwed worse.) Of course, with "bridged" systems like > those, you still have to deal with the host system, so "headers" aren't > free. You still have to encode the data into the body of the message in > some fashion, which eats into the available amount. > > Worst of all, is that those bridged systems are also unreliable for hosts > of reasons and then you're re-implementing TCP with one hand tied behind > your back.=E2=80=8B > > Granted, I've got a pretty limited viewpoint, so I'm sure I'm missing > something obvious. > > On Tue, Nov 1, 2016 at 8:50 PM, Martin Thomson > wrote: > > On 2 November 2016 at 12:00, Costin Manolache wrote: > > Yes, when sending over GCM it's better to have the 65bytes of the key i= n > the > > binary prefix of the > > "raw_data" byte[] instead of having to add another key/value pair, with > the > > b64 encoding and proto > > overhead. But it's an optimization - not the main reason :-). A nice > extra > > benefit is that browsers on android > > could dispatch the message based on the raw_data only, since the EC > public > > key can identify the app/SW. > > As I said, I'm not opposed to this, it just seems wrong. > > Moving the public key into the body will cut into message budgets. > We'll be at 3994 octets of plaintext maximum if we do that. One of > the nice things with the header field is that users don't pay for it. > The bad thing is that the server needs to find a way to move it. > > If we are going to make this change, we need to be very crisp about it. > > > --001a114949127b86a505404a155f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
AFAIK the "DH" public key must be sent to the de= vice no matter what.

Right now for GCM, if you use = the webpush endpoint the headers end up in
the key/value pairs, a= s base64, while the binary data goes in the raw_data.
I have no p= roblem if the spec defines that the binary header should be excluded - and<= /div>
=C2=A0push services support 4k of real data ( i.e. continue to ex= clude the header overhead).=C2=A0

If transmitting = over other transports - somehow we need to send the dh public key and
=
the body - if it doesn't fit a tickle+poll or segmentation need to= be used. The fact the
=C2=A0public key was received in a header = or was part of the body doesn't change this.

C= ostin

On T= ue, Nov 1, 2016 at 9:02 PM JR Conlin <jconlin@mozilla.com> wrote:
=E2=80=8BOn Tue, Nov 1, 2016 at 8:50 = PM, Martin Thomson <martin.= thomson@gmail.com> wrote:
=
Moving the public key into the body = will cut into message budgets.
We'll be at 3994 octets of plaintext maximum if we do that.=C2=A0
=
=E2=80=8B=E2=80=8B

=
=E2= =80=8BI'm a bit confused about that. For "native" networks, push servers h= ave=20 pretty wide tolerances for how much data that they can send over their=20 pipes. Going between services, I can definitely understand, since you'r= e held to the limits of the provider system. (APNs limits to about 2K, so users are kinda screwed worse.) Of course, with "bridged" system= s like=20 those, you still have to deal with the host system, so "headers" = aren't=20 free. You still have to encode the data into the body of the message in=20 some fashion, which eats into the available amount.=C2=A0

Worst of all, is that those bridged systems are also unreliable for hosts of=20 reasons and then you're re-implementing TCP with one hand tied behind= =20 your back.=E2=80=8B

Grante= d, I've got a pretty limited viewpoint, so I'm sure I'm missing= something obvious.

On Tue, Nov 1, 2016 at 8:50 PM, Martin Thomson <martin.thomson@gmail.com>= wrote:
On 2 November 2016 at 12:00, Costin Manolache <cos= tin@gmail.com> wrote:
> Yes, when sending over GCM it's better to have the 65bytes of the = key in the
> binary prefix of the
> "raw_data" byte[] instead of having to add another key/value= pair, with the
> b64 encoding and proto
> overhead. But it's an optimization - not the main reason :-). A ni= ce extra
> benefit is that browsers on android
> could dispatch the message based on the raw_data only, since the EC pu= blic
> key can identify the app/SW.

As I said, I'm not opposed to this, it just seems wrong.

Moving the public key into the body will cut into message budgets.
We'll be at 3994 octets of plaintext maximum if we do that.=C2=A0 One o= f
the nice things with the header field is that users don't pay for it. The bad thing is that the server needs to find a way to move it.

If we are going to make this change, we need to be very crisp about it.

--001a114949127b86a505404a155f-- From nobody Tue Nov 1 21:47:02 2016 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 3372B1299EA for ; Tue, 1 Nov 2016 21:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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 dC1dP_R--ws9 for ; Tue, 1 Nov 2016 21:46:59 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 61627129494 for ; Tue, 1 Nov 2016 21:46:59 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id e187so65606057itc.0 for ; Tue, 01 Nov 2016 21:46:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kKCZKnHlb1DSr+YkC3LcCzkNOyNtUEjbaZE78vWWYVo=; b=q5bMPHqrH/f7/SbfBeEXmna0AGKZfsc5FpaA/l2bYZL/DvNXP9667T3P9VEKAk74tb N6AGEUwxeywaKhGlc9ej7ejAP4CTLD5iXfl8HHaL3B1iG/RDmYLO2EpREGsz4jSZM3qO tuVq8iAYRcVm0++La6PjsykINA0l7aXOrRtN3eF8DXpy3V5+Qk8a+holp2I8pSsVzvaa Nq+DDWkrUWQT1ZVDDsCif0pTpaNrNM65RQNoPdqVbEEKlW4QnuG7QyfvRwx2E+0/BZSV hsc3j6yC87ufNl5yr/3uY81MO75li06vPfFXohRdfvMUwV1pbIxjGdoKI4p1xafY2q11 7zsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kKCZKnHlb1DSr+YkC3LcCzkNOyNtUEjbaZE78vWWYVo=; b=RHPiLzeAch0TkULRHPGU+mXL/fd1s8IwEiDJosOfEi3uuKwKBeAbpFKsG9Z/4kXR43 khjw1BkhZ+y+SunxgI5whq9kaqsp+dq4yN15AmLQ/FdEKhFu4n63FZnsxNfRIClff/Lj wuiWi9ThleF8d5Lgpqq0CvFCFEh3EQD+GuRAsK81ydv1p+YKBa21m4zs/oXkinqHFwE5 BH7VH44la3E+j4QEO92JjGoro5C7CU2lHOslG/I9HBVs52Tg8vR4i+qaNV0kCMxK9Odd BMSECmX5gmCc6qNLazf/QNotEB0JI1jxKIRdlnk3o3TONRtMfMn3A5w+V8MYzUpri1SF iCKA== X-Gm-Message-State: ABUngvfX0DwEVmetOw7NfpVHaKztvs6Q2SdAziqq6J6H+mzQDZUPsB8rxgUsBj4SPwJS6q0QdSkIgM3n/8HOMA== X-Received: by 10.107.183.148 with SMTP id h142mr2275512iof.190.1478062018717; Tue, 01 Nov 2016 21:46:58 -0700 (PDT) MIME-Version: 1.0 References: <84f3da33-a9a4-1bbc-f290-e283cec07c22@mozilla.com> In-Reply-To: From: Costin Manolache Date: Wed, 02 Nov 2016 04:46:47 +0000 Message-ID: To: jrconlin@mozilla.com, Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c0b8e6e94ed6a05404a21b2 Archived-At: Cc: "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Major change to encryption X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 02 Nov 2016 04:47:01 -0000 --94eb2c0b8e6e94ed6a05404a21b2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I now understand your concern - no need to steal any octet, just define that real message size should be 4k. I believe aesgcm also adds few byes for authentication - we can define that the cleartext can be 4k, with header and crypto overhead excluded.. Costin On Tue, Nov 1, 2016 at 9:43 PM Costin Manolache wrote: > AFAIK the "DH" public key must be sent to the device no matter what. > > Right now for GCM, if you use the webpush endpoint the headers end up in > the key/value pairs, as base64, while the binary data goes in the raw_dat= a. > I have no problem if the spec defines that the binary header should be > excluded - and > push services support 4k of real data ( i.e. continue to exclude the > header overhead). > > If transmitting over other transports - somehow we need to send the dh > public key and > the body - if it doesn't fit a tickle+poll or segmentation need to be > used. The fact the > public key was received in a header or was part of the body doesn't > change this. > > Costin > > On Tue, Nov 1, 2016 at 9:02 PM JR Conlin wrote: > > =E2=80=8BOn Tue, Nov 1, 2016 at 8:50 PM, Martin Thomson > wrote: > > Moving the public key into the body will cut into message budgets. > We'll be at 3994 octets of plaintext maximum if we do that. > > =E2=80=8B=E2=80=8B > > =E2=80=8BI'm a bit confused about that. For "native" networks, push serve= rs have > pretty wide tolerances for how much data that they can send over their > pipes. Going between services, I can definitely understand, since you're > held to the limits of the provider system. (APNs limits to about 2K, so > users are kinda screwed worse.) Of course, with "bridged" systems like > those, you still have to deal with the host system, so "headers" aren't > free. You still have to encode the data into the body of the message in > some fashion, which eats into the available amount. > > Worst of all, is that those bridged systems are also unreliable for hosts > of reasons and then you're re-implementing TCP with one hand tied behind > your back.=E2=80=8B > > Granted, I've got a pretty limited viewpoint, so I'm sure I'm missing > something obvious. > > On Tue, Nov 1, 2016 at 8:50 PM, Martin Thomson > wrote: > > On 2 November 2016 at 12:00, Costin Manolache wrote: > > Yes, when sending over GCM it's better to have the 65bytes of the key i= n > the > > binary prefix of the > > "raw_data" byte[] instead of having to add another key/value pair, with > the > > b64 encoding and proto > > overhead. But it's an optimization - not the main reason :-). A nice > extra > > benefit is that browsers on android > > could dispatch the message based on the raw_data only, since the EC > public > > key can identify the app/SW. > > As I said, I'm not opposed to this, it just seems wrong. > > Moving the public key into the body will cut into message budgets. > We'll be at 3994 octets of plaintext maximum if we do that. One of > the nice things with the header field is that users don't pay for it. > The bad thing is that the server needs to find a way to move it. > > If we are going to make this change, we need to be very crisp about it. > > > --94eb2c0b8e6e94ed6a05404a21b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I now understand your concern - no need to steal any octet= , just define that=C2=A0
real message size should be 4k. I believe aesg= cm also adds few byes for=C2=A0
authentication - we can define th= at the cleartext can be 4k, with header
and crypto overhead exclu= ded..

Costin

On Tue, Nov 1, 2016 at 9:43 PM Costin Manolache <<= a href=3D"mailto:costin@gmail.com">costin@gmail.com> wrote:
AFAIK = the "DH" public key must be sent to the device no matter what.

Right now for GCM, if you use the webpush endpoi= nt the headers end up in
the key/value pairs,= as base64, while the binary data goes in the raw_data.
I have no problem if the spec defines that the binary header sho= uld be excluded - and
=C2=A0push services sup= port 4k of real data ( i.e. continue to exclude the header overhead).=C2=A0=

If transmitting over other transports - somehow we need to send = the dh public key and
the body - if it doesn&= #39;t fit a tickle+poll or segmentation need to be used. The fact the
=
=C2=A0public key was received in a header or was p= art of the body doesn't change this.

Costin
<= br class=3D"gmail_msg">
On Tue, Nov 1, 2016 at 9:02 PM JR Conlin <jconl= in@mozilla.com> wrote:
=E2=80=8BOn Tue, = Nov 1, 2016 at 8:50 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
Mov= ing the public key into the body will cut into message budgets.
We'll be at 3994 octets of plaintext maximum if we do that.=C2=A0
=
=E2=80=8B=E2=80=8B

=
=E2= =80=8BI'm a bit confused about that. For "native" networks, push servers h= ave=20 pretty wide tolerances for how much data that they can send over their=20 pipes. Going between services, I can definitely understand, since you'r= e held to the limits of the provider system. (APNs limits to about 2K, so users are kinda screwed worse.) Of course, with "bridged" system= s like=20 those, you still have to deal with the host system, so "headers" = aren't=20 free. You still have to encode the data into the body of the message in=20 some fashion, which eats into the available amount.=C2=A0

Worst of all, is that those bridged systems are also unreliable for hosts of=20 reasons and then you're re-implementing TCP with one hand tied behind= =20 your back.=E2=80=8B

Grante= d, I've got a pretty limited viewpoint, so I'm sure I'm missing= something obvious.

On Tue, Nov 1, 2016 at 8:50 PM, Martin Thomson <martin.thomson@gmail.com>= wrote:
On 2 November 2016 at 12:00, Costin Manolache <cos= tin@gmail.com> wrote:
> Yes, when sending over GCM it's better to have the 65bytes of the = key in the
> binary prefix of the
> "raw_data" byte[] instead of having to add another key/value= pair, with the
> b64 encoding and proto
> overhead. But it's an optimization - not the main reason :-). A ni= ce extra
> benefit is that browsers on android
> could dispatch the message based on the raw_data only, since the EC pu= blic
> key can identify the app/SW.

As I said, I'm not opposed to this, it just seems wrong.

Moving the public key into the body will cut into message budgets.
We'll be at 3994 octets of plaintext maximum if we do that.=C2=A0 One o= f
the nice things with the header field is that users don't pay for it. The bad thing is that the server needs to find a way to move it.

If we are going to make this change, we need to be very crisp about it.

--94eb2c0b8e6e94ed6a05404a21b2-- From nobody Tue Nov 1 22:11:11 2016 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 8A72A1294B5 for ; Tue, 1 Nov 2016 22:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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 wsLOp1KjMCC9 for ; Tue, 1 Nov 2016 22:11:09 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 0D996129436 for ; Tue, 1 Nov 2016 22:11:09 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id q124so15662931itd.1 for ; Tue, 01 Nov 2016 22:11:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TGy9aAvne6kTeuV6g6X5LWybxd60qQ3MPf3j+Zazdp8=; b=GS4wMG3XR7UaPjSzNcG62XSqWWO4oXySnZPhoc+2n+9j40g1fsh3PqEbSfY7LJiBRG dvQtxazXi9i5/FSdhfEVFdRFvwWVRyktND7UXuclDS9JTsei0ZUjyHjpgoMymnpeKbid p60L/JgtNqEeOIiesUhLXed/JfRjn4Pm6UxX3xGxFF8WIeUETeuua5CBNJ157jFjVLH0 6iGr7+Qch7sNyR+Zbe99UrrBC8dzq+3yJWuxFgAwXbmVz+t/obSRDJU4fzsTPxQyYPhK efV/sDxXDy34hUU/JU6xtYi+JDt46C0ZSLDgdxY2dPd6RiWsZejnOkrUbR7qyWEatYEh 2tbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TGy9aAvne6kTeuV6g6X5LWybxd60qQ3MPf3j+Zazdp8=; b=EOlwZOkKPBmBwNC1j3KTFwKeT8rThj3O4+iMLrJWNpjs7Sb+65GiDUrQltxT/Vw7c6 Kiu6oKptHOLFdj6NCn3v22Y011nOxjRcfOZJwUXths+0ES5YHooiMbWA7DLaon7ccJpF hseu5oXuiAVX3giyzIYvvnnzyQMNdBMIJuk3mXocOCzrhL9RgkKzGFoW0B+W7Um8BGIY brwkTPL3soSVVzuOxtKj6bp4rBMTGFOoeXQF/IPe34gfmFD8bKQSfT8XUgWi7vI4qyqP akSa/f0h74Jn9GMkyS29wbPPg/KMc0t7vELW/vGo9OxTbLM8Dr5Y8Eou1VZgSjtz+Csl sY9g== X-Gm-Message-State: ABUngvdC0v6Ll7V2jp8GYO1yF4lVyAmKtTMp2Andbg4iQqfpTeVm9sQIYjMOIKBifGwpAiKruq0Ct8rNb7mg9Q== X-Received: by 10.107.2.65 with SMTP id 62mr2200367ioc.83.1478063468205; Tue, 01 Nov 2016 22:11:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Costin Manolache Date: Wed, 02 Nov 2016 05:10:57 +0000 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11396f40fa76d205404a7717 Archived-At: Cc: jr conlin , "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Vapid public key X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 02 Nov 2016 05:11:10 -0000 --001a11396f40fa76d205404a7717 Content-Type: text/plain; charset=UTF-8 Can we do something like: Authorization: webpush JWT;PUBLICKEY or even Authorization: webpush PUBLICKEY:JWT_TOKEN The public key is the 'identity' of the sender, the JWT token is authenticating it - it's common to use USER:SECRET. I agree having the publickey inside the JWT token - and double b64 - is ugly, also it may be easier to verify the signature first, and decode the body after. Costin On Tue, Nov 1, 2016 at 8:55 PM Martin Thomson wrote: > On 2 November 2016 at 05:02, Costin Manolache wrote: > > I would also add that some of the bugs we've seen in our implementation > > were related to parsing and passing along the crypto key. Even for > > VAPID I would love to see the sender public key appended to the > > Authorization header somehow instead of in a separate Crypto-Key header. > > Putting the public key in the JWT header is probably doable, but it > means double base64 encoding for key. I'd want to hear that people are > OK with it before making a change. > > Note that this is probably a net increase in header size (I make it to > be a 22 octet increase, even losing the Crypto-Key header field > entirely). Header size probably isn't that important on this request > though. > --001a11396f40fa76d205404a7717 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Can we do something like:

Authorization= : webpush JWT;PUBLICKEY

or even

Authorization: webpush PUBLICKEY:JWT_TOKEN

= The public key is the 'identity' of the sender, the JWT token is au= thenticating it -
it's common to use USER:SECRET.
<= br>
I agree having the publickey inside the JWT token - and doubl= e b64 - is ugly, also
it may be easier to verify the signature fi= rst, and decode the body after.=C2=A0

Costin
=

On Tue, Nov 1, 2016 a= t 8:55 PM Martin Thomson <ma= rtin.thomson@gmail.com> wrote:
On 2 November 2016 at 05:02, Costin Manolache <costin@gmail.com>= ; wrote:
> I would also add that some of the bugs we've seen in our implement= ation
> were related to parsing and passing along the crypto key. Even for
> VAPID I would love to see the sender public key appended to the
> Authorization header somehow instead of in a separate Crypto-Key heade= r.

Putting the public key in the JWT header is probably doable, but it
means double base64 encoding for key. I'd want to hear that people are<= br class=3D"gmail_msg"> OK with it before making a change.

Note that this is probably a net increase in header size (I make it to
be a 22 octet increase, even losing the Crypto-Key header field
entirely).=C2=A0 Header size probably isn't that important on this requ= est
though.
--001a11396f40fa76d205404a7717-- From nobody Tue Nov 1 22:59:59 2016 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 C18A5129513 for ; Tue, 1 Nov 2016 22:59:58 -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 nXMe-JzeNLDF for ; Tue, 1 Nov 2016 22:59:57 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 528B71293F2 for ; Tue, 1 Nov 2016 22:59:57 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id q130so6626100qke.1 for ; Tue, 01 Nov 2016 22:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cUP52mPmThxEoLbdFeenVspcRt08AaBgp9LPmd7uqk8=; b=Ula72xJOAyZwzOY8DaRauFDvHuOWVrWCdFFgdbetE43AkKnEIUSME5XbY7nN8dt5V6 w2CzP2YCm2QC77cZ2hG72Pmd5AERLHg/rU0THSRoXiwb+BUP9cqatEyk3/RljDvGRoLd DRBCClZnl2Ty2S4sJURyPV8W/GN2ITe6MIKopHL/+A48G15dziNMeSFB9WO8K9/1i4+p nZIMipkrpaUGZ9+gmAxNxXQsL+dIoMV/c1xb167TEmOG/5R2ABEI17OtL8q8YS1z8BO0 bGOXvoX7gvw5sy1AVMlErkXTdL+31VRZsdMYnUF0acLrUfEXO7QWt2NBzbxyxWncUWye 0FPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cUP52mPmThxEoLbdFeenVspcRt08AaBgp9LPmd7uqk8=; b=J++pjDjHT8KSZvYAysrAce7OHhvXqGhAWKmtWnC7bpmECyM0G7ZdCOwE1XyLOyeeBn ASlPnDL50ig8ihgGJ6/x7uwSJB/kHIUfNvf1UiyNDfWEq8Wwazo3ZHU808yP39WWWfA0 BLPz2wbZGtWO0jZf/zWDFCdfET/XLbPWrRq22SMk/U1tWSB/xweoqMnQVkJC6LhvLtd4 GNXIiQdgRz6lWL/pfOv3o0ZT+cWiyEh17swo1cDrPNPB6OKcuH6HThAOkFFs8Fk+0zMl cUmFL5CdYWpQlFQ34b+fuysA6pN0WTOJVQFX8NNVAoFmQPkec9hJ1HHNhCWTrhxlARHJ Lv0A== X-Gm-Message-State: ABUngvfytehGJ9ElyfLeSX8/vEFUT2rdWLnRYz0XyfDLDzfm9XsNvEtOiVFSGmfr5vQitUIdTCCO522kcNCvgA== X-Received: by 10.55.12.2 with SMTP id 2mr1557364qkm.68.1478066396486; Tue, 01 Nov 2016 22:59:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Tue, 1 Nov 2016 22:59:55 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Wed, 2 Nov 2016 16:59:55 +1100 Message-ID: To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: jr conlin , "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Vapid public key X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 02 Nov 2016 05:59:59 -0000 On 2 November 2016 at 16:10, Costin Manolache wrote: > Authorization: webpush PUBLICKEY:JWT_TOKEN The grammar (RFC 7235) is: credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ] token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"=" With JWT, we've opted to use the "token68" form (also shown here). Given that base64url takes '-', '_', and '.', we could separate on '/'. '/' is a valid base64 (the non-url-safe variant) character, but we could split on that. For existing implementations, you would have to accept that you are going to have to sniff for this, or we could use a new auth-scheme. I think that sniffing should be workable given that you won't have a Crypto-Key header field. And before I forget, the ugliest option of all is to use JWK inside the JWT. Here's an example of a JWK: {"crv":"P-256","ext":true,"key_ops":["verify"],"kty":"EC","x":"20zCfUuIs0NGtaVxENI4VH0YyJOUuxp973BTZTfhe1A","y":"WEMWyistS_sD6gGLN4IISWdIMQxZoCHAhlZ8zkmcVUI"} The ext and key_ops fields can be omitted safely - I just pulled this straight out of webcrypto - though it's still even bigger than you might like. From nobody Wed Nov 2 08:32:08 2016 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 224C3129699 for ; Wed, 2 Nov 2016 08:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 hERaVWWft1dL for ; Wed, 2 Nov 2016 08:32:02 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 653D612963A for ; Wed, 2 Nov 2016 08:32:02 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id n85so13833697pfi.1 for ; Wed, 02 Nov 2016 08:32:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=un/7ukZgcxwAgjlYhXN59Y6UBsO6nMJXJOkIaOSD75I=; b=bHQbeV7g3LMBmzrBro/l1TE2EKcYcED9zLzjQ+OAe0cW62VgAnv7ek50kOnKts+6zh IWE5IZ9hI0uOQKT+I+gA8RMDDucbaJmpoHCi+MDihgB4m9RnpExx7w8ItDss72U7bmwE u/E3eg7ZcYkmCTCMSv84dFAHzHQh554UpGdsQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=un/7ukZgcxwAgjlYhXN59Y6UBsO6nMJXJOkIaOSD75I=; b=aZz0f6gms3giMwyYBt28i5k7BxjsfGmEaPLBVxljwK+/A0xD/ACjTiD6fkdgHsrKfE AZpWmdhYevA5tyn+flBTt8cvtrSYC0M/ljJVaWkps5QaCtgwdTaTkwjVRTthDbQF/O3m qknClcpUXPp8JLPZF30aLGQCArMZjYZSW7zs8mfZtx4xLH4h2pfV0NiFOev6oCiKD1AR 57fqyj1hUryPNX00xMxQ0l/Xy4Jjist4twdZoFIAdoe/GZZE4lxBSGbMoOFT063XnodY akbz7nga8K9UlPRyBeJjm6mAHygIVZ1aeCLI7LWGG8+WpI63WEoD7VzTFrA7oKLQmbum Cp7A== X-Gm-Message-State: ABUngvckM8zX316mW6KJZCETtYUBGxi9Nf2VaYnK9ltar0Vqr/lEAj3mmv1cXmo5r5U14gzF X-Received: by 10.98.155.9 with SMTP id r9mr7962687pfd.71.1478100721642; Wed, 02 Nov 2016 08:32:01 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:ad46:b789:568d:ff0? ([2620:101:80fc:224:ad46:b789:568d:ff0]) by smtp.gmail.com with ESMTPSA id yx8sm5656152pac.29.2016.11.02.08.32.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Nov 2016 08:32:00 -0700 (PDT) To: Martin Thomson , Costin Manolache References: From: jr conlin Message-ID: <7299b268-1bbb-e04f-55d3-da1294583785@mozilla.com> Date: Wed, 2 Nov 2016 08:32:00 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Thunderbird/51.0a2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Cc: "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Vapid public key X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 02 Nov 2016 15:32:05 -0000 I'm ok with making the new auth scheme: 2/PUBLICKEY/JWT_TOKEN While this would break older libraries (ick) it would at least allow servers to easily determine if this is a new form rather than an older version. I'll also add that many libraries have a limit to the length of the header line they're willing to accept. For instance, python's twisted library tops out header lines at 16384 characters, and a 16K limit is pretty common for others. https://twistedmatrix.com/documents/current/api/twisted.protocols.basic.LineReceiver.html We're currently far short of that, but remember that people will be putting extra values inside of their JWT so that Ops teams can properly coordinate, and those values will be re-encoded as base64. So it's quite possible that folks could bump up against that limit. On 11/1/2016 10:59 PM, Martin Thomson wrote: > On 2 November 2016 at 16:10, Costin Manolache wrote: >> Authorization: webpush PUBLICKEY:JWT_TOKEN > The grammar (RFC 7235) is: > > credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ] > token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"=" > > With JWT, we've opted to use the "token68" form (also shown here). > Given that base64url takes '-', '_', and '.', we could separate on > '/'. '/' is a valid base64 (the non-url-safe variant) character, but > we could split on that. > > For existing implementations, you would have to accept that you are > going to have to sniff for this, or we could use a new auth-scheme. I > think that sniffing should be workable given that you won't have a > Crypto-Key header field. > > And before I forget, the ugliest option of all is to use JWK inside > the JWT. Here's an example of a JWK: > > {"crv":"P-256","ext":true,"key_ops":["verify"],"kty":"EC","x":"20zCfUuIs0NGtaVxENI4VH0YyJOUuxp973BTZTfhe1A","y":"WEMWyistS_sD6gGLN4IISWdIMQxZoCHAhlZ8zkmcVUI"} > > The ext and key_ops fields can be omitted safely - I just pulled this > straight out of webcrypto - though it's still even bigger than you > might like. From nobody Wed Nov 2 11:12:02 2016 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 DC269129AB1 for ; Wed, 2 Nov 2016 11:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 3UazXnSo6Kmx for ; Wed, 2 Nov 2016 11:11:58 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::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 79418129569 for ; Wed, 2 Nov 2016 11:11:58 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id h14so17470301ywa.2 for ; Wed, 02 Nov 2016 11:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lij1QsENBBwFWFDc7HZkMGSrpQVJbv1Vjlalc8+4m5I=; b=iok2vRV9keWMh1ZhO80znysspvliNPCc6cDmKv3NPd5nQ/+XBfxoYSr66DJbewVpNO JdN/b/8irvfoAvW/ZS0V6izu+VxpXE93fMewBAju/Oq/aIqtlgJHyD3ivYYRzqlv/Hu1 HnI9oUmm4gpfpdaWFR0xDB0/e1nCh7CCGNzhDyqBny+v7KCfqXV4XOkV+xvMgPnrGzWh 2i1WLEvhMtNtM3n59Qg4DWeb8mG45tRdOXdvYYzsnNnT/09B4s7TEeOtv/Im/tyq0Py9 YR3m7O6Z1gVWKCnLG4I2WsJdG+I4HqcURy7jONo0+sryYmIHsMKPK+4k2C+QHZytftge sCLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lij1QsENBBwFWFDc7HZkMGSrpQVJbv1Vjlalc8+4m5I=; b=b1m5r0O3/km9VT5P9hCWvKzwQLOf7Ko+O692fSqr/mMPnKOPaMN4wGi7mLLHS/vS4L 3+V7EMl3m+o1wdkN1TC3TWUdzL0i4KpFhzHZiDLB3zX78YlAsYO4Rb81OwXsFCjSg2ao OQshIUGojqZ6dQ2X6db64Fjtz5nriO+RQZpe/fPCYb3kuDvPb/7QfvV/krXAnZGOi+rB 4BK0N9dtGAlX9dK4TZj2rnju3GX8FTLndRENYYlDuXQWOxea7/TFr008Kznx2Ysegqgx vhfZhvkD7awCFoQIYMPlmbO4+toskfN/j9z5E7MgF27fB/Tpj6ixirCVx6znt5pkuxN9 ZpJg== X-Gm-Message-State: ABUngvdT6xToZnE435iDEVrcGaSqWYVAYiBx7vg/phK/d3u1ot/WXm4gvbhjvpyVfwl2GoNSwzRScNsnETa2WQ== X-Received: by 10.36.125.5 with SMTP id b5mr3487011itc.62.1478110317742; Wed, 02 Nov 2016 11:11:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Costin Manolache Date: Wed, 02 Nov 2016 18:11:47 +0000 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114059446d9293054055602f Archived-At: Cc: jr conlin , "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Vapid public key X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 02 Nov 2016 18:12:00 -0000 --001a114059446d9293054055602f Content-Type: text/plain; charset=UTF-8 IMHO the main problem with JWK is not size, but the inconsistency - would be good for the exact string used in subscribe() to also show in Authenticate. Any problem with using auth-param: Authorization: webpush JWTTOKEN, id=PUBKEY Costin On Tue, Nov 1, 2016 at 10:59 PM Martin Thomson wrote: > On 2 November 2016 at 16:10, Costin Manolache wrote: > > Authorization: webpush PUBLICKEY:JWT_TOKEN > > The grammar (RFC 7235) is: > > credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ] > token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"=" > > With JWT, we've opted to use the "token68" form (also shown here). > Given that base64url takes '-', '_', and '.', we could separate on > '/'. '/' is a valid base64 (the non-url-safe variant) character, but > we could split on that. > > For existing implementations, you would have to accept that you are > going to have to sniff for this, or we could use a new auth-scheme. I > think that sniffing should be workable given that you won't have a > Crypto-Key header field. > > And before I forget, the ugliest option of all is to use JWK inside > the JWT. Here's an example of a JWK: > > > {"crv":"P-256","ext":true,"key_ops":["verify"],"kty":"EC","x":"20zCfUuIs0NGtaVxENI4VH0YyJOUuxp973BTZTfhe1A","y":"WEMWyistS_sD6gGLN4IISWdIMQxZoCHAhlZ8zkmcVUI"} > > The ext and key_ops fields can be omitted safely - I just pulled this > straight out of webcrypto - though it's still even bigger than you > might like. > --001a114059446d9293054055602f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
IMHO the main problem with JWK is not size, but the incons= istency - would be good for the=C2=A0
exact string used in subscribe() = to also show in Authenticate.

Any problem with usi= ng auth-param:

Authorization: webpush JWTTOKEN, id= =3DPUBKEY

Costin

On Tue, Nov 1, 2016 at 10:59 PM Martin Thomson &l= t;martin.thomson@gmail.com&= gt; wrote:
On 2 November 2016 at 16= :10, Costin Manolache <costin@gmail.com> wrote:
> Authorization: webpush PUBLICKEY:JWT_TOKEN

The grammar (RFC 7235) is:

=C2=A0 =C2=A0 =C2=A0credentials =3D auth-scheme [ 1*SP ( token68 / #auth-pa= ram ) ]
=C2=A0 =C2=A0 =C2=A0token68 =3D 1*( ALPHA / DIGIT / "-" / ".= " / "_" / "~" / "+" / "/" ) *&= quot;=3D"

With JWT, we've opted to use the "token68" form (also shown h= ere).
Given that base64url takes '-', '_', and '.', we co= uld separate on
'/'.=C2=A0 '/' is a valid base64 (the non-url-safe variant)= character, but
we could split on that.

For existing implementations, you would have to accept that you are
going to have to sniff for this, or we could use a new auth-scheme.=C2=A0 I=
think that sniffing should be workable given that you won't have a
Crypto-Key header field.

And before I forget, the ugliest option of all is to use JWK inside
the JWT.=C2=A0 Here's an example of a JWK:

{"crv":"P-256","ext":true,"key_ops"= :["verify"],"kty":"EC","x":"20= zCfUuIs0NGtaVxENI4VH0YyJOUuxp973BTZTfhe1A","y":"WEMWyis= tS_sD6gGLN4IISWdIMQxZoCHAhlZ8zkmcVUI"}

The ext and key_ops fields can be omitted safely - I just pulled this
straight out of webcrypto - though it's still even bigger than you
might like.
--001a114059446d9293054055602f-- From nobody Wed Nov 2 11:14:36 2016 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 3304F129AFC for ; Wed, 2 Nov 2016 11:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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 Od8lrnE1v40g for ; Wed, 2 Nov 2016 11:14:33 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::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 290411297D4 for ; Wed, 2 Nov 2016 11:14:16 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id t125so17620852ywc.1 for ; Wed, 02 Nov 2016 11:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mzduq0gSQNuxNCgUuU7imap9gM1xGIl6yrT5QdH8MNc=; b=DY8TyqfgElQRsGQt/msGXpuL9KkIXAoMEdug2g+rrGtW2+TNxEUy38W9SUDbZZDU8j LJ9wKwgLTv24fKyq69sknooIkWRGNAhnFIHP4C6k/TDLQxRyMQU6pD0M5N1hyH0koF9i 6PkasAjdWgZqpCED1pnRg8+v7aZPVlBdJzIggekA1qMmfbRvWtBEs5KP+5yOw86kASM7 uZzU9kmLTHEBGaj2B9Dpr0u1BkhUtblHlP6POfjy1wSxJ3KFFuP+5CU18GifwROfh7We N7+/HYJfaV4fdvEdiVh6wYN/zLPOQl2I1/puzniozEQ13vz1emfsxvx/YUx8cgGOXOG5 z27A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mzduq0gSQNuxNCgUuU7imap9gM1xGIl6yrT5QdH8MNc=; b=Kjtp1JHJrV/ZwJgIh4ROS0HdWv1itVSkyNcDgb0Zce3dpUDmY1NUo1UUJDcwNJ7+TU 3Q8FhSPqd5xSykSuMtf1r6vQyz1zVFDCzNiO+FOmlE8UVNPBvFInqISCkRWMISE7muN9 hBeVVxYY1hZlQJyDiYKN/CUIMroWybBBItAPzy4dh5XRKK9KU1dE5FZWsaz5Ea8MN0ks 7aG4X+bbSMiJnmZBcOqWp4+DoU40ZyecHqhIHBw8xJjdKKzw3C4qL2R5tT+qU1Qi+A0I xqzAALFnvT0xE9TFZoys+tcez6LtMlRQkQ99WQAhmFgNCvwdKMovUNQlv/AvxGwppmjz ZaOg== X-Gm-Message-State: ABUngvdiT5eKRTgj0RAzIM6lsEbEfAs1VRUu5Qhxo0PDq6Zz8aNZhTxOGXjKkLT2lMAx9WYy5N+cfB6/0iiPbQ== X-Received: by 10.107.2.8 with SMTP id 8mr2127753ioc.83.1478110455400; Wed, 02 Nov 2016 11:14:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Costin Manolache Date: Wed, 02 Nov 2016 18:14:04 +0000 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11397876a20e81054055686b Archived-At: Cc: jr conlin , "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Vapid public key X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 02 Nov 2016 18:14:35 -0000 --001a11397876a20e81054055686b Content-Type: text/plain; charset=UTF-8 >From rfc2617 (digest auth): Authorization: Digest username="Mufasa", realm="testrealm@host.com", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="/dir/index.html", qop=auth, nc=00000001, cnonce="0a4f113b", response="6629fae49393a05397450978507c4ef1", opaque="5ccc069c403ebaf9f0171e9517f40e41" On Wed, Nov 2, 2016 at 11:11 AM Costin Manolache wrote: > IMHO the main problem with JWK is not size, but the inconsistency - would > be good for the > exact string used in subscribe() to also show in Authenticate. > > Any problem with using auth-param: > > Authorization: webpush JWTTOKEN, id=PUBKEY > > Costin > > On Tue, Nov 1, 2016 at 10:59 PM Martin Thomson > wrote: > > On 2 November 2016 at 16:10, Costin Manolache wrote: > > Authorization: webpush PUBLICKEY:JWT_TOKEN > > The grammar (RFC 7235) is: > > credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ] > token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"=" > > With JWT, we've opted to use the "token68" form (also shown here). > Given that base64url takes '-', '_', and '.', we could separate on > '/'. '/' is a valid base64 (the non-url-safe variant) character, but > we could split on that. > > For existing implementations, you would have to accept that you are > going to have to sniff for this, or we could use a new auth-scheme. I > think that sniffing should be workable given that you won't have a > Crypto-Key header field. > > And before I forget, the ugliest option of all is to use JWK inside > the JWT. Here's an example of a JWK: > > > {"crv":"P-256","ext":true,"key_ops":["verify"],"kty":"EC","x":"20zCfUuIs0NGtaVxENI4VH0YyJOUuxp973BTZTfhe1A","y":"WEMWyistS_sD6gGLN4IISWdIMQxZoCHAhlZ8zkmcVUI"} > > The ext and key_ops fields can be omitted safely - I just pulled this > straight out of webcrypto - though it's still even bigger than you > might like. > > --001a11397876a20e81054055686b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
From rfc2617 (digest auth):

= Authorization: Digest username=3D"Mufasa",
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0realm=3D"testrealm@host.com",
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0nonce=3D"dc= d98b7102dd2f0e8b11d0f600bfb0c093",
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uri=3D"/dir/index.html",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0qop= =3Dauth,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0nc=3D00000001,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0cnonce=3D"0a4f113b",
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0response=3D"6629fae493= 93a05397450978507c4ef1",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0opaque=3D"5ccc069c403ebaf9f0171e9517f40e41&= quot;

On Wed, Nov 2, 2= 016 at 11:11 AM Costin Manolache <co= stin@gmail.com> wrote:
IMHO the main problem with JWK is not size,= but the inconsistency - would be good for the=C2=A0
exact string used in subscribe() to also show in Authenticate.

= Any problem with using auth-param:

Authorization: webpush JWTTOK= EN, id=3DPUBKEY

Costi= n

<= div dir=3D"ltr" class=3D"gmail_msg">On Tue, Nov 1, 2016 at 10:59 PM Martin = Thomson <martin.thomson@gmail.com> wrote:
On 2 November 2016 at= 16:10, Costin Manolache <costin@gmail.com> wrote:
> Authorization: webpush PUBLICKEY:JWT_TOKEN

The grammar (RFC 7235) is:

=C2=A0 =C2=A0 =C2=A0credentials =3D auth-scheme [ 1*SP ( token68 / #auth-pa= ram ) ]
=C2=A0 =C2=A0 =C2=A0token68 =3D 1*( ALPHA / DIGIT / "-" / ".= " / "_" / "~" / "+" / "/" ) *&= quot;=3D"

With JWT, we've opted to use the "token68" form (also shown h= ere).
Given that base64url takes '-', '_', and '.', we co= uld separate on
'/'.=C2=A0 '/' is a valid base64 (the non-url-safe variant)= character, but
we could split on that.

For existing implementations, you would have to accept that you are
going to have to sniff for this, or we could use a new auth-scheme.=C2=A0 I=
think that sniffing should be workable given that you won't have a
Crypto-Key header field.

And before I forget, the ugliest option of all is to use JWK inside
the JWT.=C2=A0 Here's an example of a JWK:

{"crv":"P-256","ext":true,"key_ops"= :["verify"],"kty":"EC","x":"20= zCfUuIs0NGtaVxENI4VH0YyJOUuxp973BTZTfhe1A","y":"WEMWyis= tS_sD6gGLN4IISWdIMQxZoCHAhlZ8zkmcVUI"}

The ext and key_ops fields can be omitted safely - I just pulled this
straight out of webcrypto - though it's still even bigger than you
might like.
--001a11397876a20e81054055686b-- From nobody Wed Nov 2 12:43:30 2016 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 3D11B1293F5 for ; Wed, 2 Nov 2016 12:43:29 -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 hUcsk7BgP5-p for ; Wed, 2 Nov 2016 12:43:27 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (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 BB009127076 for ; Wed, 2 Nov 2016 12:43:27 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id 189so17009366pfz.3 for ; Wed, 02 Nov 2016 12:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=MG/cpmazOoZ+pX2LfabqBKwL6kXuLul8Ddc9OtnjhOc=; b=NhX9BClSppQaMkr5SesmsLwuNJn0gSUz8phJVwYK91hqfrHpWKpqM83eAFKstbOy7p 62Wi9bJqf6DGZ0MPbOe7ZZ5hv3DAT66lvNf1mjtMllOrN9L4ZHrPaNqGgDgLtKilgSHO zMLQo+cCYqf4e2Zv+McyDV8QOCQ4lbMGSbvWM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=MG/cpmazOoZ+pX2LfabqBKwL6kXuLul8Ddc9OtnjhOc=; b=V+jQjp3gh/ebSDYc9vL/vWNvhPKDCv17nDgDd9Nkl0UYIIdprWPlrlnJD0A0QBwNp8 AgYa164mO7SumjVW5B8jNDnLBvGh8i347hV3QgHpB42jtsVlmOnBB61Wqq/8835yC+wY ZuIpgVJV+lbG/1N50vMCnBh40JT1Wwu7sR88b72Uy60mpqqhG2UAzuLQ9KWIZhFyZuvB VjHe0WSltSnFbSkP87hRKnoAuRFgx1LzKRRvRw56pEayfJtdVHv9fmrjlxRweRqwZIUj nyxhjKuLI/Y3eqsxysQU1seLabFFmWeahio2wo5V5XgElbhZWZF6LkHbnjmHTJmO4FC7 /c5A== X-Gm-Message-State: ABUngvclKRGvNqxWRso5zqwPNI9cVmQxp5hdQtM/5bVvrrTE9lhf0FWcERjVFnKuYfOOZteq X-Received: by 10.99.218.21 with SMTP id c21mr8077553pgh.67.1478115807407; Wed, 02 Nov 2016 12:43:27 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:ad46:b789:568d:ff0? ([2620:101:80fc:224:ad46:b789:568d:ff0]) by smtp.gmail.com with ESMTPSA id 13sm6683171pfz.30.2016.11.02.12.43.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Nov 2016 12:43:26 -0700 (PDT) To: Costin Manolache , Martin Thomson References: From: jr conlin Message-ID: <4538eada-c406-fa72-fec1-1c26bb225a1f@mozilla.com> Date: Wed, 2 Nov 2016 12:43:26 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Thunderbird/51.0a2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9E40EC194F88E2ECC69FA7DB" Content-Language: en-US Archived-At: Cc: "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Vapid public key X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 02 Nov 2016 19:43:29 -0000 This is a multi-part message in MIME format. --------------9E40EC194F88E2ECC69FA7DB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 11/2/2016 11:14 AM, Costin Manolache wrote: > From rfc2617 (digest auth): > > Authorization: Digest username="Mufasa", > realm="testrealm@host.com ", > nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", > uri="/dir/index.html", > qop=auth, > nc=00000001, > cnonce="0a4f113b", > response="6629fae49393a05397450978507c4ef1", > opaque="5ccc069c403ebaf9f0171e9517f40e41" No "favoriteDrink"? /me fights back his x.500 PTSD. --------------9E40EC194F88E2ECC69FA7DB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 11/2/2016 11:14 AM, Costin Manolache wrote:
From rfc2617 (digest auth):

Authorization: Digest username="Mufasa",
                 realm="testrealm@host.com",
                 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                 uri="/dir/index.html",
                 qop=auth,
                 nc=00000001,
                 cnonce="0a4f113b",
                 response="6629fae49393a05397450978507c4ef1",
                 opaque="5ccc069c403ebaf9f0171e9517f40e41"
No "favoriteDrink"?

/me fights back his x.500 PTSD.

--------------9E40EC194F88E2ECC69FA7DB-- From nobody Wed Nov 2 13:22:57 2016 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 9EA76129489 for ; Wed, 2 Nov 2016 13:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 4lbaBWVBExOr for ; Wed, 2 Nov 2016 13:22:53 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::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 E134A1298C7 for ; Wed, 2 Nov 2016 13:22:51 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id 62so36225001oif.1 for ; Wed, 02 Nov 2016 13:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=573MBszHyo/zR5vvYwPe52bAcp7sb5b8aOYFjzFpaKY=; b=IlTDHGIfEkJ+zRsUpCoeCNGMhuXTAi2Qnb05syQ+LNR2ZtMJ3xUKa5682irr03vohL m5h/NCxh2WOHlBxN3xl46MnsRXd7l96tNDQGfw9NLMxw51dPGNxDTMTbgcWie5ujNrLw om96FsyMXNjeirnUNYGwkpmrWqAtj1LdOC9+lcE4p6hGGUse1BkQmBX9tjPU8pzXlvKk nwjvnguUHH2S2obic1THsCAxDAEKIYyGW6NY19kePoX3msKZ5zwr87tdNyIlMU6Pua2g 4wiY8IcAtKDG1II6nr7KX3AfycGfZXu2T9QDTTdbL2ZGRHqKrMzOa7qDF+0pq6AS2RMx yQ3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=573MBszHyo/zR5vvYwPe52bAcp7sb5b8aOYFjzFpaKY=; b=exDcgVRC8+l8h4ajnGmEdNlimQzsycSUahFj2T8lnNgTXor1gZyCfThiMQuF6jaLfx 7IZKcHB8Dzz3JXQfHq9WEIeQzni13dsEr+aRoXLvgK9PKDM307M4Nd+/WN/nnHXBANuR yq9jVO8sN+tV/LOrziO0fDsqdu5OsOwI6+92h6LkcFlwrrQrE3yT5lanmlMltMZAslMq BA0Y42sj+9L1RMY2udmy3sYJqMWN6g8jZjGAPhQb6KjJiAYlleWPLoGRWykWsycdYaAe oz0J3KwcxdJ4PARBnSiv2OoATdRVDvjJZqSRKUx4Ik1v28dMlHgavdxb8LU64i/jyYMD 5dkQ== X-Gm-Message-State: ABUngvfQ4ru1v312m96m+dT4JtWptVwESLNfirORcAdRbjIEfJm4kTzBpaLeMzUOGSNOAPntzw09ohM9ihBM7A== X-Received: by 10.107.2.8 with SMTP id 8mr2557908ioc.83.1478118171183; Wed, 02 Nov 2016 13:22:51 -0700 (PDT) MIME-Version: 1.0 References: <4538eada-c406-fa72-fec1-1c26bb225a1f@mozilla.com> In-Reply-To: <4538eada-c406-fa72-fec1-1c26bb225a1f@mozilla.com> From: Costin Manolache Date: Wed, 02 Nov 2016 20:22:40 +0000 Message-ID: To: jr conlin , Martin Thomson Content-Type: multipart/alternative; boundary=001a1139787687946f054057345b Archived-At: Cc: "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Vapid public key X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 02 Nov 2016 20:22:56 -0000 --001a1139787687946f054057345b Content-Type: text/plain; charset=UTF-8 Apologies for any bad memories related to implementing digest auth :-) If we are updating the vapid spec - I would like to ask for one more change: "A UA may also authenticate with VAPID when making a subscribe request. If subscribe was authenticated with VAPID, all subsequent subscribe, unsubscribe, ack or monitor requests associated with the same pushset MUST be authenticated with VAPID with same public key" I know subscribe/monitor are over SSL - but I think it improves a bit the security, and the device already needs to have code to handle EC for the e2e encryption. The main concern is an attacker 'acking' or unsubscribing - since the messages are e2e encrypted they can't read it. Costin On Wed, Nov 2, 2016 at 12:43 PM jr conlin wrote: > On 11/2/2016 11:14 AM, Costin Manolache wrote: > > From rfc2617 (digest auth): > > Authorization: Digest username="Mufasa", > realm="testrealm@host.com", > nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", > uri="/dir/index.html", > qop=auth, > nc=00000001, > cnonce="0a4f113b", > response="6629fae49393a05397450978507c4ef1", > opaque="5ccc069c403ebaf9f0171e9517f40e41" > > No "favoriteDrink"? > > /me fights back his x.500 PTSD. > > --001a1139787687946f054057345b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Apologies for any bad memories related to implementin= g digest auth :-)

If we are updating the vapid spe= c - I would like to ask for one more change:

"= ;A UA may also authenticate with VAPID when making a subscribe request. If = subscribe was=C2=A0
authenticated with VAPID, all subsequent subs= cribe, unsubscribe, ack or monitor requests
associated with the s= ame pushset MUST be authenticated with VAPID with same public key"=C2= =A0

I know subscribe/monitor are over SSL - but I = think it improves a bit the security, and the device
already need= s to have code to handle EC for the e2e encryption. The main concern is=C2= =A0
an attacker 'acking' or unsubscribing - since the mes= sages are e2e encrypted they can't read it.

Co= stin=C2=A0

On We= d, Nov 2, 2016 at 12:43 PM jr conlin <jconlin@mozilla.com> wrote:
On 11/2/2= 016 11:14 AM, Costin Manolache wrote:
From rfc2617 (digest auth):

Authorization: Digest username=3D"Muf= asa",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0realm=3D"testrealm@host.com",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0nonce=3D"dcd98b7102dd2f0e8b11d0f600bfb0c093",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0uri=3D"/dir/index.html",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0qop=3Dauth,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0nc=3D00000001,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0cnonce=3D"0a4f113b",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0response=3D"6629fae49393a05397450978507c4ef1",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0opaque=3D"5ccc069c403ebaf9f0171e9517f40e41"
No "favoriteDrink"?

/me fights back his x.500 PTSD.

--001a1139787687946f054057345b-- From nobody Wed Nov 2 17:49:57 2016 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 4B04F12961A for ; Wed, 2 Nov 2016 17:49:55 -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 z6QLUw9bzzir for ; Wed, 2 Nov 2016 17:49:53 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 2E7DA129705 for ; Wed, 2 Nov 2016 17:49:52 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id q130so39436823qke.1 for ; Wed, 02 Nov 2016 17:49:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Tys07pPzW9qMLxr+5HSkEWJ6b2NFtMrWvIlV3+Ill8A=; b=H2lSENKtLa4+kUS7rnn9wAzhUf207UbIcDS6LykkfoH/rpK5hYjasYZHc3eCGmE8Jr Gn1QN3rojiTs57lNUvUqBHBdAKlUSbsNYkKJ7vPT0yPGk1bvoF/HQFCbSjHKsESt+i4n SuAadzaRdxqMwao07MNlI3riF8Kks/E/r+xmbjpUAUTCEjX5Tc98CWunEMwHrGFSaMRK Ng0H2iLkvPE0w8Tkd4tLJLRJrUrLHMRA1dwgEtXRagC3p9CQiEBdhoayLxJpO1yU7M4i odIe48OY55BCPnrH9lqJjMJBQIfZiiinHs70iA36mu/D0rmVz0PTpuOW+Djf2KcMYQz8 LlUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Tys07pPzW9qMLxr+5HSkEWJ6b2NFtMrWvIlV3+Ill8A=; b=V0KVfcz8LgjbXwgkK019dEiObSHC+r2cbgktdkKy3/w3gLOSTWjQqGLyod3DoFIORl 3wG5QW145BoylOJjLIIr4JwhYSqxzHKd9FYnu4F2YBLc9688pz+cAxSx9R1MQTMsO80u Ooy7EAcMbMCSm76SKPfOooUWLaTXDcqaz0LEshbzIUCvlwsFhwvnMSezJDB/KnfumJ5S lcT9MJJRAi0/9XtMVEm14VKsQnWnESA8q8/ORwO0uo/vCicELHYUZtJYEexjpVmGshF/ 49ld6wDdjyPvFiT8om4iCmITEZoDPiIbI1o9Rk+ylqjtRjJiraVlrxZ4F7VE82B+oE5n NhlQ== X-Gm-Message-State: ABUngvejyHsd6O00WSUUKQGeL1vVzyyzKwA1M6GMOEz/8TqPnFvyoJAQOAhwvJsFuTW845YneeQvJ0k1fHwqbw== X-Received: by 10.55.12.2 with SMTP id 2mr5401772qkm.68.1478134191304; Wed, 02 Nov 2016 17:49:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Wed, 2 Nov 2016 17:49:50 -0700 (PDT) In-Reply-To: References: <4538eada-c406-fa72-fec1-1c26bb225a1f@mozilla.com> From: Martin Thomson Date: Thu, 3 Nov 2016 11:49:50 +1100 Message-ID: To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: jr conlin , "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Vapid public key X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 03 Nov 2016 00:49:55 -0000 Well, I haven't revised VAPID recently (it missed the cutoff due to a rush on -encryption). I have an open PR, and now these changes. I'll add this to the pile. (I think that I'd phrase this slightly differently, but it's reasonable to point out that this new authentication scheme is available to the UA and PS). https://github.com/webpush-wg/webpush-vapid/issues/27 On 3 November 2016 at 07:22, Costin Manolache wrote: > Apologies for any bad memories related to implementing digest auth :-) > > If we are updating the vapid spec - I would like to ask for one more change: > > "A UA may also authenticate with VAPID when making a subscribe request. If > subscribe was > authenticated with VAPID, all subsequent subscribe, unsubscribe, ack or > monitor requests > associated with the same pushset MUST be authenticated with VAPID with same > public key" > > I know subscribe/monitor are over SSL - but I think it improves a bit the > security, and the device > already needs to have code to handle EC for the e2e encryption. The main > concern is > an attacker 'acking' or unsubscribing - since the messages are e2e encrypted > they can't read it. > > Costin > > On Wed, Nov 2, 2016 at 12:43 PM jr conlin wrote: >> >> On 11/2/2016 11:14 AM, Costin Manolache wrote: >> >> From rfc2617 (digest auth): >> >> Authorization: Digest username="Mufasa", >> realm="testrealm@host.com", >> nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", >> uri="/dir/index.html", >> qop=auth, >> nc=00000001, >> cnonce="0a4f113b", >> response="6629fae49393a05397450978507c4ef1", >> opaque="5ccc069c403ebaf9f0171e9517f40e41" >> >> No "favoriteDrink"? >> >> /me fights back his x.500 PTSD. >> > From nobody Wed Nov 2 17:56:32 2016 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 EFA3612973A for ; Wed, 2 Nov 2016 17:56:29 -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 k4JkLxpuqdyW for ; Wed, 2 Nov 2016 17:56:28 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 708721295AB for ; Wed, 2 Nov 2016 17:56:28 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id c47so19514375qtc.2 for ; Wed, 02 Nov 2016 17:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pCnHjGShLVCTgG1B54bgSmrT5U1ZENUSwWnkA3d9hz0=; b=cZIbsDzSy8NHqbpY4Slczu9ycOrCZwwqAgWSEj/EKVYuDLDW7/EIZHwPtRxbvNOtNf x5qfB/0/V00srMsAFPg6QuO1EVZb7cHm2fGsfJ/99pL7pm8+2A91BY8qBqbWW5aOIRwi crvYXYqi2DphVw15CHpsF4G6+m2rshZvB8v0AvGuLjXpvY1FHbKUnRj9o7YbD3Rqo0t/ FHX5+nmlXH8EvKRfXLxvz5fIBF2Bb2pm+XmikbSDvhkkOvDGLKDBb4pXR7BRFFx1xW3u F/nRRsnx2xUj/nN13KsR2FMMcu2qqhgsx9Ns+pvDephWANJ2Wu2k3SdjSM0pgX32nakF SyBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pCnHjGShLVCTgG1B54bgSmrT5U1ZENUSwWnkA3d9hz0=; b=VucMEmGMqUPxB0AwRGnpbOHARh1jHLH4bZB0Fe99kEOY7FtWw6bhm9shaGW9ZgrtW8 Vr7iHEI2cbE8+rKUegMm6Aywwwn7SQhUXlufu1VMIJq77/Iq9JoUCi9rpy0LElxM5Ii0 Fu8EPXal9DANdoZKrIESFFTKTmhrFrRkeepXJyyDtNvJD2PGzdKsQrycdbeBsQoyrtkW D9FwjoEAk1QJzrJJfeFrRk0T0Djf5aYJ4uhdLP1MWiCoQpZEGTUO4ClG2CimwlE1WT6b xOV1N3E1lmEck++HBT1cI+4sU3B4Xs0/L7yvvkM6LWPP/84jxlcSXWkRH70CbeXvygQR vNMw== X-Gm-Message-State: ABUngvddHsiK9cc1sKvWbzXLD0Ugj1+LM3iWy2fquCbTo8IAXEiJh/wE0LZzT2vtSgxavuhizB9B4hUjVyrJ1w== X-Received: by 10.200.36.125 with SMTP id d58mr5300728qtd.126.1478134587629; Wed, 02 Nov 2016 17:56:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Wed, 2 Nov 2016 17:56:27 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 3 Nov 2016 11:56:27 +1100 Message-ID: To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: jr conlin , "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Vapid public key X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 03 Nov 2016 00:56:30 -0000 On 3 November 2016 at 05:11, Costin Manolache wrote: > Any problem with using auth-param: > > Authorization: webpush JWTTOKEN, id=PUBKEY Yeah, authparam requires that everything have a key-value pair. We could do it though. It's a toss-up: Authorization: webpush JWTTOKEN.blah.blah_/AApubkey-___ Authorization: webpush token="JWTTOKEN.blah.blah",k="AApubkey-___" I could live with either. The second form is recommended by RFC 7235, so we should probably pick that one. That said, it makes sniffing marginally harder because the double-quotes are optional and '=' is valid in either form. You have to look for a comma. From nobody Thu Nov 3 17:27:54 2016 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 5417F1294B1 for ; Thu, 3 Nov 2016 17:27:53 -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 XWMSLmsXFh-3 for ; Thu, 3 Nov 2016 17:27:51 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 083041293F8 for ; Thu, 3 Nov 2016 17:27:51 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id x190so77536852qkb.0 for ; Thu, 03 Nov 2016 17:27:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tr1epHfiCpvNm8FRB1ZdBBc4gBRFHxCvOoWcBMQHLdA=; b=iCXSqf6xrHCfID6BPmCDuid8GyGZsBCRtVIMI9lELjOkmhoC86N+K4KbdaJr4JTXM4 OywMCkNRNdY0pBERx+bnZcRtx7EI24a3EI0a4i3jolv8V3ooU0TR5OXAOZocTAlTxjPi AJYXJKfy+Q/DLZwKdGvbWwGSYqhNvz1ckqYB+ACcYGkElt7FbBwRTfczhCbsO6H8Ojmx 1dBksu6Dk0bHsLqRR8Sm7rxSrMYSCzpEnzzKMWxiTPoPcb3Xz6VQigILcsQTQP0374hb 1aLLbrJVZU26yxvpkshXGlR/WGc7YCxWU2BpCliZA2yxuMp3APCMcJxKMoI1jFsAst2j r8qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tr1epHfiCpvNm8FRB1ZdBBc4gBRFHxCvOoWcBMQHLdA=; b=I2BqT72mHPtwT07fPIOBDKbL3e1cCQfVjctbFWmaDX/iXRvPn1bC6aiBoe9Ng71ooN rcTDbbkGLrOLmrhGUG86QozbikFpisVdsqhvL9+BK8PfSASw2mxtrNmOqJ28lgk3bVT7 dtJcsV83v7BHXjzDVqocNxPZ7163OP8xNAuFaaIVx7VVeW5oSsfdMQOPgqbPYceKX1DH fR+tmX8oc+PGu+5zA3QnpOt+Krsa483LZRwboMSaAu8+ynIhhymcZxq7ceFuNEuhUZjh 1ztcukazJHYg84zX8pXB46BppXva83ajxtTkQScmaQi+dKB3UVxUnumLnkIN9MAmoE5y N57Q== X-Gm-Message-State: ABUngveWkqJ5EhBaw7XB3IE2mORoT0l8dF9PNY6VcvJECSjAT6r0eJsaJmwj0s+AQGU7URWxL2e8uE4LP2g7xw== X-Received: by 10.55.12.2 with SMTP id 2mr10471688qkm.68.1478219270172; Thu, 03 Nov 2016 17:27:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Thu, 3 Nov 2016 17:27:49 -0700 (PDT) In-Reply-To: References: <84f3da33-a9a4-1bbc-f290-e283cec07c22@mozilla.com> From: Martin Thomson Date: Fri, 4 Nov 2016 11:27:49 +1100 Message-ID: To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: JR Conlin , "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Major change to encryption X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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, 04 Nov 2016 00:27:53 -0000 On 2 November 2016 at 15:46, Costin Manolache wrote: > I now understand your concern - no need to steal any octet, just define that > real message size should be 4k. I believe aesgcm also adds few byes for > authentication - we can define that the cleartext can be 4k, with header > and crypto overhead excluded.. I haven't increased the size limit, but I have made the request change. See what you think: https://github.com/webpush-wg/webpush-encryption/pull/9 I've updated my node.js implementation to match (that's how I generated the example): https://github.com/martinthomson/encrypted-content-encoding/pull/28 (I'm working on an update to -vapid as we speak.) From nobody Thu Nov 3 20:09:50 2016 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 AE0C21293FE for ; Thu, 3 Nov 2016 20:09:48 -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 3egsJ5CEdc7g for ; Thu, 3 Nov 2016 20:09:47 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 39E0F12007C for ; Thu, 3 Nov 2016 20:09:47 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id x190so80911502qkb.0 for ; Thu, 03 Nov 2016 20:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VgT/jPq5GgZIvoBT3lhVC5fNvYC4ixb0oXkTthuxtbI=; b=UxMRpwe9Dyb89+JaLA8pxAe1Fnc4r6rDdTZiYTYxNAKb2hpY5g4CYJpPH0GJu+T9Vf URsx89sAVFxPzo6VkdNhBVCCfXwBPFH6ip+M9pYWW1J7itBv1D2uJGbrEz5WMEbEdERy zlxLZo6JNGRSfkvcKT3/SDs7MPCxJY6R8QleOCJXhcdOf6rwpNLlCiojgjQiCSX2aX46 a9tj2D73scFNWBJ6O8NDneQeH6/rn8oxAqIs6QAs9Rw2bsxNYK68N/8N3CMpFsNc79PX Dgx+5JeWflXcFWKd0WvxAnz8msRVyiZ8DAlNJtDoiHWe5jdQEhp/SmrDSNGoGITET/Xi Q8yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VgT/jPq5GgZIvoBT3lhVC5fNvYC4ixb0oXkTthuxtbI=; b=dMpuqWMKQT0vUqNgJpozHcuiWxOAgeCeXQEYdPUBlF6+mfjWcqvjfLOWkoMNwZF64H hqh2gL68RuO/pMZXoaODe81SOVY2e+U8xPa4Gb903CZKCD38ZybRm60zSKHebeRrw4K5 HpT+lwbGtzAFgWjuf7Tflmzli5INpHzoPZFlq2olxEEVnqAo41SPCqXuMZw9dzx5ud33 CK8XOoRiethMW8exrzf5hlKNyZVYMRbnOYszwMTZKfN98ID/iDKihg5/Onu19OHrAswV PfmNCq11Nwb2Tn95SbeHwmM7qud9XkJh9bXlOlwAnECVLaR/eyu55tGeauB0V4VUVArt HcQA== X-Gm-Message-State: ABUngvejEY/TsM1L0oEwP/EFa+msKZqnG2FslSiAk3/71pc1UmUbq3UQTSAApHW98RNj/fJnJoZBXd/T9Zjvug== X-Received: by 10.233.235.72 with SMTP id b69mr12394593qkg.144.1478228986440; Thu, 03 Nov 2016 20:09:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Thu, 3 Nov 2016 20:09:45 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 4 Nov 2016 14:09:45 +1100 Message-ID: To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: jr conlin , "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Vapid public key X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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, 04 Nov 2016 03:09:49 -0000 On 3 November 2016 at 11:56, Martin Thomson wrote: > I could live with either. The second form is recommended by RFC 7235, > so we should probably pick that one. That said, it makes sniffing > marginally harder because the double-quotes are optional and '=' is > valid in either form. You have to look for a comma. Here's the proposed changes: https://github.com/webpush-wg/webpush-vapid/pull/29 From nobody Sat Nov 19 07:53:35 2016 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 15E8212955C for ; Sat, 19 Nov 2016 07:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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 Dh1D5VcrlCoL for ; Sat, 19 Nov 2016 07:53:32 -0800 (PST) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 4C350129465 for ; Sat, 19 Nov 2016 07:53:32 -0800 (PST) Received: by mail-it0-x22e.google.com with SMTP id y23so72009120itc.0 for ; Sat, 19 Nov 2016 07:53:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/1msPGcfirqqCb38zFdBcc1uLpQsDeRcp9JGWPkkk94=; b=QT6Z60sfbk6XV1RLeA1dIvRm0VME1gQvNIbc8G+v0iPThD76N8Rks4ZqE8elYjW49N XC5f+h2VBu7RTywvm0VzbpoMcEemg5raLupnif5nKePnjKdyNRIIL3VZYvtN8NZaW0VC 64hC7AODEwCnp6582HaHjbUE11hUsb3hvTAB5gjaLbbsg9uEgRDSa1RGGn+chvqI4ZPN D3w0GVClVAMZutO9cEMoEVJU3EqNrxkMgtYd/V4U+8a0zDx9v8KaEENHHspeTP/Ykt25 mUhZoWdeeJwmcIFomvXJgcSxoIN91mscbNw2NmBxEKP88ON7eqBuOqzM77S1sCpIza2B rVTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/1msPGcfirqqCb38zFdBcc1uLpQsDeRcp9JGWPkkk94=; b=B25v9Cd113ACjbFRLY+kqU95nuTtsRkTtXuciY9182jvCCLHI+ECbIObAin8t0p+Qj zhJXh1qUzcqijVAr672nm6eAjzrI6StseC4c2/aJ5j683VFF/QJ3GacVzAzRQME3MJFF vivWEC5kNeYJSyUkINF9UIaEvDWcESQ47MB8kakbDiSSmCCNBVLcbTI64xS0RjpeZ1Pi ZwFTqTFG0wXBCuC/tQYguC1V9f72wydFxoZfG+SXR/nVw+FqT4K85LVc55ZmB6Ac4XYz 6d+7DbvM86+echW9U13A6FJnCCWSniykfdeRQOXBT6VaX6b9MWjZdCZeaSOQodlI7LTP LL9g== X-Gm-Message-State: AKaTC018hTYrmgt0TyaAJYsvvCV6Lkw7ShDlAukuyRCpJbjsgbjcrQ+RE0Jh1gfWqvpmzwgHa0Vwlf+4GnFkxQ== X-Received: by 10.36.37.199 with SMTP id g190mr3077369itg.66.1479570811636; Sat, 19 Nov 2016 07:53:31 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Costin Manolache Date: Sat, 19 Nov 2016 15:53:21 +0000 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11450caaa5f9000541a96cb3 Archived-At: Cc: jr conlin , "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Vapid public key X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 19 Nov 2016 15:53:34 -0000 --001a11450caaa5f9000541a96cb3 Content-Type: text/plain; charset=UTF-8 One more small suggestion: one of the pain points ( for me ) is the W3C subscribe taking the vapid pubkey as bytes instead of a string, and having to include the key in .js files as a constant. Would it be possible to define a .well-known/vapid/... file where the public key can be saved ? This may simplify tools, testing ( test env may use test sender keys), etc. One problem is that .well-known is at root - so either have /.well-known/vapid/ENCODED_SW_URL.pub or have a less standard .well-known/ in the same directory with the SW. This would be optional - if the key is not included in the register call explicitly. GCM has a similar mechanism. Costin On Thu, Nov 3, 2016 at 8:09 PM Martin Thomson wrote: > On 3 November 2016 at 11:56, Martin Thomson > wrote: > > I could live with either. The second form is recommended by RFC 7235, > > so we should probably pick that one. That said, it makes sniffing > > marginally harder because the double-quotes are optional and '=' is > > valid in either form. You have to look for a comma. > > Here's the proposed changes: > > https://github.com/webpush-wg/webpush-vapid/pull/29 > --001a11450caaa5f9000541a96cb3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One more small suggestion: one of the pain points ( for me= ) is the W3C subscribe taking the=C2=A0
vapid pubkey as bytes instead = of a string, and having to include the key in .js files as a constant.=C2= =A0

Would it be possible to define a .well-known/vapid/.= .. file where the public key can be saved ?
This may simplify too= ls, testing ( test env may use test sender keys), etc. One problem is that= =C2=A0
.well-known is at root - so either have /.well-known/vapid= /ENCODED_SW_URL.pub or=C2=A0
have a less standard .well-known/ in= the same directory with the SW.=C2=A0

This would = be optional - if the key is not included in the register call explicitly.

GCM has a similar mechanism.

Costin



On Thu, Nov 3, 2016 at 8:09 PM Martin Thomson= <martin.thomson@gmail.com> wrote:
On 3 November 2016 at= 11:56, Martin Thomson <martin.thomson@gmail.com> wrote: > I could live with either.=C2=A0 The second form is recommended by RFC = 7235,
> so we should probably pick that one.=C2=A0 That said, it makes sniffin= g
> marginally harder because the double-quotes are optional and '=3D&= #39; is
> valid in either form.=C2=A0 You have to look for a comma.

Here's the proposed changes:

https://github.com/webpush-wg= /webpush-vapid/pull/29
--001a11450caaa5f9000541a96cb3-- From nobody Sun Nov 20 17:32:24 2016 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 81EF41293EB for ; Sun, 20 Nov 2016 17:32:22 -0800 (PST) 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 FHTpWN5NuNjr for ; Sun, 20 Nov 2016 17:32:21 -0800 (PST) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 DE894126B6D for ; Sun, 20 Nov 2016 17:32:20 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id p16so193593317qta.0 for ; Sun, 20 Nov 2016 17:32:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7H1k2QAJ1O9ZH3h18i+7+xMLZ4osijUCrrwVmJpnfec=; b=Ot14VyY9pS1YKiT8X3v3zDsfKjHEB3j0UBPIT/yCdhfxnJ26NYbohGtZd4m5wEqNYq OT5kbSH1AJp6MS4ekXapfpA4FsTWVZYYsJ8LKQQy001QRrRpGOZixlM5Wy9PDlTe1AgH 0SU4N+VjzoJ/mS0Y91XqJ953w2b6s2M4iMouIWJBdFc7X2/inLCNgkHrbu2oCUsrRDtZ uaAATR+DOVZr294l5bpLeCZkXg7nTLPHIY8aUb/t1Rs9olcgX+XpiGq3XVhfC26Frh+K D3N14pDLNZlOgDhwxV2pW3s+U47miIBc3xHqw+slf8qfF3dItUafs6EIh2nQ5HVjtiPQ MSsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7H1k2QAJ1O9ZH3h18i+7+xMLZ4osijUCrrwVmJpnfec=; b=G0hdzdncCK62RPvpPJR26BHWnAyO3/LIYWGZtevDnf7dbi+dFxdewpL41aUsH4/ILI q9PPSUsOL3/oVX4kW+vc1Uxkq43tkF8arDI0PGrFpiFcAFWElewLXbdoXeC+NSUviRYj BEipXGY2WijfMfjMUViSDmTo4BU2fizLdq117POCNbKOKZ2EMa2Q4rJzdQuIpXdisuoY +GUOTDle6R9s2FW/c5qp6pzIx0BNjSM3eem4+fy0lURAjLusyTTu2clnlXNPtax7Ex6G lJpZ7+Rt08Xj6R2e+qIuRn6ydKlB2QYfGgnbmLLNpd27yA8UwTghvlwZ+9CS9VlNZMeO m9Eg== X-Gm-Message-State: AKaTC01mWlfU1AH4RhgkmuZJN07zNIrOSqTkh9yoG7ajKrdaTmRpE6sagOZGdoC/zR8ryVYZdG3tOBsg24gQbg== X-Received: by 10.200.52.87 with SMTP id v23mr7273223qtb.143.1479691940090; Sun, 20 Nov 2016 17:32:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.101 with HTTP; Sun, 20 Nov 2016 17:32:19 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Mon, 21 Nov 2016 12:32:19 +1100 Message-ID: To: Costin Manolache Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: jr conlin , "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Vapid public key X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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, 21 Nov 2016 01:32:22 -0000 On 20 November 2016 at 02:53, Costin Manolache wrote: > One more small suggestion: one of the pain points ( for me ) is the W3C > subscribe taking the > vapid pubkey as bytes instead of a string, and having to include the key in > .js files as a constant. Your suggestion being that we define a base64url parser. You can include the key in the form Uint8Array.from([4, 5, 6, 6, ...]); It's bigger and you have to work it out once, but it saves shipping a converter. Either way, this is probably something to take here: https://github.com/w3c/push-api/issues > Would it be possible to define a .well-known/vapid/... file where the public > key can be saved ? > This may simplify tools, testing ( test env may use test sender keys), etc. > One problem is that > .well-known is at root - so either have > /.well-known/vapid/ENCODED_SW_URL.pub or > have a less standard .well-known/ in the same directory with the SW. Now that we are considering removal of Crypto-Key (I'm about to send out drafts with that change), I need to work out how to push the keys along with the registration. I don't think that using .well-known will give us the right binding to the subscription request though. Maybe I don't understand the proposal, though. Can you walk through how a client would use this? From nobody Sun Nov 20 20:02:07 2016 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 DCB39129567 for ; Sun, 20 Nov 2016 20:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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 bjR3WGr2oBCf for ; Sun, 20 Nov 2016 20:02:04 -0800 (PST) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 3D1B7129439 for ; Sun, 20 Nov 2016 20:02:04 -0800 (PST) Received: by mail-io0-x234.google.com with SMTP id c21so30356341ioj.1 for ; Sun, 20 Nov 2016 20:02:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6ZZ4qhhWMEcuJcz15zQQkRb3A7XJG9eFXVa08ShSPqI=; b=nCvD3rhC5NvIvQ2bVxEt7A/lkRI41Rmcj88nxF42At0Tkt1yHUpPwP4n7dXPcn0Kl2 B1xPN323dVUeuqriVnHTMTt61F264mFc0lClCaAR+SMGiXiIRc8AWsAVN4FrPLOGnIge Fdfw3e+H4Kdb88j+frL3USjEMzyojxK44OdzrSik9VmzON7pTJ4EIzU6KZz6EI7aYnA3 R2SuAHExrcPDyNbvPS21FP3AztIbKnqgk2C7hE9feyA5LngxGg1zJ4NA1ZG6TRzGai7a a4DVZl9AOJL/6G2cx4gsp8wlpmQBQ1d/1FGwXXP920ttjJPeYSzNT0xCmUEuvyKYPOLF p+cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6ZZ4qhhWMEcuJcz15zQQkRb3A7XJG9eFXVa08ShSPqI=; b=iaBestlvvlJQ3TZ6UfzuWPLpoPDjTKblq/89sWgTJRFZeeMGOOHFngZJsrJSApwMLH sEYv7kYrJBMeW0bfEeQCU5XDnyf6JfPcYI06lECo04NxDlhPcELtIPEti2lxW1kzcnlU xm4hy/ZVL1taei147emjbYvEYOmTKuAK6yAkbQngkJqi8PN8MtDZClAbGowjofaQmBTY oAwG9sR0SI8V5H83sYGMiL8hw/kg34cL3NnurS+tpRL8Mf8vL6sI7CumY/ltbIZAS6Ok aN2zAF2iJvfmDUyYDTtREnvjhi7oVPwflFZLlvFHPwGihX4Y+lKB6NOnvKixSCX1Pr/R Q9UQ== X-Gm-Message-State: AKaTC01SRCu6oYEO1ZKb67AYwXMazKlImhFqBStOpunyv3TKFYetx6nBc+ReiLm3Tp7qMFMYWciaInqTP0osvw== X-Received: by 10.107.18.208 with SMTP id 77mr9311067ios.195.1479700923559; Sun, 20 Nov 2016 20:02:03 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Costin Manolache Date: Mon, 21 Nov 2016 04:01:52 +0000 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113eca92ec37450541c7b70f Archived-At: Cc: jr conlin , "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Vapid public key X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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, 21 Nov 2016 04:02:06 -0000 --001a113eca92ec37450541c7b70f Content-Type: text/plain; charset=UTF-8 On Sun, Nov 20, 2016 at 5:32 PM Martin Thomson wrote: > On 20 November 2016 at 02:53, Costin Manolache wrote: > > One more small suggestion: one of the pain points ( for me ) is the W3C > > subscribe taking the > > vapid pubkey as bytes instead of a string, and having to include the key > in > > .js files as a constant. > > Your suggestion being that we define a base64url parser. You can > include the key in the form Uint8Array.from([4, 5, 6, 6, ...]); It's > bigger and you have to work it out once, but it saves shipping a > converter. > Not really - the UA will need to take the uint8[] and convert it to b64 - since that's what the push service expects. AFAIK the UA has no use with the vapid public key in current protocol (except pass it along in subscribe) - we do not pass the Authorization header from push service to UA > > Either way, this is probably something to take here: > https://github.com/w3c/push-api/issues > > > Would it be possible to define a .well-known/vapid/... file where the > public > > key can be saved ? > > This may simplify tools, testing ( test env may use test sender keys), > etc. > > One problem is that > > .well-known is at root - so either have > > /.well-known/vapid/ENCODED_SW_URL.pub or > > have a less standard .well-known/ in the same directory with the SW. > > Now that we are considering removal of Crypto-Key (I'm about to send > out drafts with that change), I need to work out how to push the keys > along with the registration. I don't think that using .well-known > will give us the right binding to the subscription request though. > > Maybe I don't understand the proposal, though. Can you walk through > how a client would use this? > If client calls subscribe() - the UA will look for .well-known/vapid.pub and pass it in the /subscribe request to the push service. If client calls subscribe( Uint8Array ) - UA will use the explicit key. It is a bit simpler to just copy the key in a defined location - in particular if you have multiple environments. It is possible to do it in code too ( using the URL to decide which key to use ). Some people may also like the more declarative approach. Not a big deal - but I think it would be nice. Re. Crypto-Key: my understanding was that there are use cases for it, as a way to distribute keys, as discussed in the other thread. Subscribe needs some header ( or query param ?) to pass the authorized entity to the push service. We just don't need it for authorization or encrypted body. Costin --001a113eca92ec37450541c7b70f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun= , Nov 20, 2016 at 5:32 PM Martin Thomson <martin.thomson@gmail.com> wrote:
On 20 November 2016 at 02:53, Costin Manolache <costin= @gmail.com> wrote:
> One more small suggestion: one of the pain points ( for me ) is the W3= C
> subscribe taking the
> vapid pubkey as bytes instead of a string, and having to include the k= ey in
> .js files as a constant.

Your suggestion being that we define a base64url parser.=C2=A0 You can
include the key in the form Uint8Array.from([4, 5, 6, 6, ...]);=C2=A0 It= 9;s
bigger and you have to work it out once, but it saves shipping a
converter.

Not real= ly - the UA will need to take the uint8[] and convert it to b64 - since tha= t's what=C2=A0
the push service expects. AFAIK the UA has no = use with the vapid public key in current
protocol (except pass it= along in subscribe) - we do not pass the Authorization header=C2=A0
<= div>from push service to UA


=C2=A0<= /div>

Either way, this is probably something to take here:
https://github.com/w3c/push-api/issues=

> Would it be possible to define a .well-known/vapid/... file where the = public
> key can be saved ?
> This may simplify tools, testing ( test env may use test sender keys),= etc.
> One problem is that
> .well-known is at root - so either have
> /.well-known/vapid/ENCODED_SW_URL.pub or
> have a less standard .well-known/ in the same directory with the SW.
Now that we are considering removal of Crypto-Key (I'm about to send out drafts with that change), I need to work out how to push the keys
along with the registration.=C2=A0 I don't think that using .well-known=
will give us the right binding to the subscription request though.

Maybe I don't understand the proposal, though.=C2=A0 Can you walk throu= gh
how a client would use this?

<= /div>
If client calls subscribe() - the UA will look for .well-known/va= pid.pub and pass it=C2=A0
in the /subscribe request to the push s= ervice.=C2=A0

If client calls subscribe( Uint8Arra= y ) - UA will use the explicit key.=C2=A0

It is a = bit simpler to just copy the key in a defined location - in particular if y= ou have=C2=A0
multiple environments. It is possible to do it in c= ode too ( using the URL to decide
which key to use ). Some people= may also like the more declarative approach.=C2=A0
=C2=A0
Not a big deal - but I think it would be nice.=C2=A0

=
Re. Crypto-Key: my understanding was that there are use cases fo= r it, as a way to=C2=A0
distribute keys, as discussed in the othe= r thread. Subscribe needs some header=C2=A0
( or query param ?) t= o pass the authorized entity to the push service. We just=C2=A0
d= on't need it for authorization or encrypted body.

<= div>Costin
--001a113eca92ec37450541c7b70f-- From nobody Mon Nov 21 09:51:48 2016 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 51994129A9D for ; Mon, 21 Nov 2016 09:51:46 -0800 (PST) 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 gX1dwKd-vwzq for ; Mon, 21 Nov 2016 09:51:43 -0800 (PST) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (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 D56D41295C6 for ; Mon, 21 Nov 2016 09:51:42 -0800 (PST) Received: by mail-pg0-x232.google.com with SMTP id 3so132708793pgd.0 for ; Mon, 21 Nov 2016 09:51:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=fNvlVdyltvENgul0sGQhaboN5U9dwIqejy/WM7MCJI8=; b=gOvMhC7bVVVcOvSBEtlMek8acGLKZvFSc5sQHfsYaKpErREhxqPYYX3YSBwrP0FQUf By7eEuTvpWEg8yXe4CSCJV/ZbVm8fvkmWI8jSDTYkhtULi7G4vioKZad9w0tsM3I7TmR xC3+DfyH4LfYCBDAZ6w2L5s3t7FmMgTqfp2mo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=fNvlVdyltvENgul0sGQhaboN5U9dwIqejy/WM7MCJI8=; b=MsAAsFtt7bJQbu0PtO6M8WpcjGzz3TFWuMXqcRKXvLzHHgpS1MrHhZ8NR8MKNWWNJ4 r8bRo3hBMLxgSPKT0NjUWLTzQ4L/vxEsJIwo2cAJzE99ZH7oAMQBx1lP8MiNxUde9IhT 1PJ82byvdNtdCvHijFm6q5wQOrKsIsiN6v8/Dyo0nVON2QuOQupOilDigtOq7nObn4HW xWQd6KhwevM9tXF8uCp5O2I8DHvYdgOmRmRW9w5r+pYsUfxJ1LrYgRV+wkaAFCEaOhYa bPanNPiIaHWmy352zDcr/HYDpqYsJOs4HYpOsx/nsDDdTm+PfTFVcScZUm/+SyFI4n+d di2w== X-Gm-Message-State: AKaTC039CT74Rw9wl01YQ3oBM+rEdenWEqih0GpL3oV8vBXQILIKJ+2jPRucx9lxcWxKpA0M X-Received: by 10.99.8.133 with SMTP id 127mr34679156pgi.76.1479750702194; Mon, 21 Nov 2016 09:51:42 -0800 (PST) Received: from ?IPv6:2620:101:80fc:224:e116:b3e1:f942:862a? ([2620:101:80fc:224:e116:b3e1:f942:862a]) by smtp.gmail.com with ESMTPSA id i124sm21068164pgd.15.2016.11.21.09.51.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 Nov 2016 09:51:40 -0800 (PST) To: Costin Manolache , Martin Thomson References: From: jr conlin Message-ID: Date: Mon, 21 Nov 2016 09:51:39 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0a2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F0B42A80F6E02EE19ECD0D8F" Content-Language: en-US Archived-At: Cc: "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Vapid public key X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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, 21 Nov 2016 17:51:46 -0000 This is a multi-part message in MIME format. --------------F0B42A80F6E02EE19ECD0D8F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit FWIW, I'm really not a fan of having an extra data path for things like this. More paths mean more things that folks can screw up or not be able to implement for various reasons. I think it's HIGHLY reasonable to ask that for a given restricted update, the Application that is making the request include a public key for the VAPID spec. The application could pull it from where ever, hard code it, or whatever makes most sense to the Application developer team (and the corresponding Subscription Update service provider). Things aren't exactly easy now, making them harder just means that less folks will be able to do it. On 11/20/2016 8:01 PM, Costin Manolache wrote: > > > On Sun, Nov 20, 2016 at 5:32 PM Martin Thomson > > wrote: > > On 20 November 2016 at 02:53, Costin Manolache > wrote: > > One more small suggestion: one of the pain points ( for me ) is > the W3C > > subscribe taking the > > vapid pubkey as bytes instead of a string, and having to include > the key in > > .js files as a constant. > > Your suggestion being that we define a base64url parser. You can > include the key in the form Uint8Array.from([4, 5, 6, 6, ...]); It's > bigger and you have to work itI"m a out once, but it saves shipping a > converter. > > > Not really - the UA will need to take the uint8[] and convert it to > b64 - since that's what > the push service expects. AFAIK the UA has no use with the vapid > public key in current > protocol (except pass it along in subscribe) - we do not pass the > Authorization header > from push service to UA I'm a bit confused here. If you use most key generation tools like $ openssl ecparam -name prime256v1 -genkey -noout -out vapid_private.pem $ openssl ec -in vapid_private.pem -pubout -out vapid_public.pem $ grep -v "^-" vapid_public.pe that dumps a b64 string the user can easily work with. Is the suggestion that we ask users to convert to binary themselves? That may reduce the need for base64 in the UA, but means that developers will need to add one. Considering the fun that happened with "lpad" not too long ago, I'm a bit concerned about the frustration that may come with that. > > > > Either way, this is probably something to take here: > https://github.com/w3c/push-api/issues > > > Would it be possible to define a .well-known/vapid/... file > where the public > > key can be saved ? > > This may simplify tools, testing ( test env may use test sender > keys), etc. > > One problem is that > > .well-known is at root - so either have > > /.well-known/vapid/ENCODED_SW_URL.pub or > > have a less standard .well-known/ in the same directory with the SW. > > Now that we are considering removal of Crypto-Key (I'm about to send > out drafts with that change), I need to work out how to push the keys > along with the registration. I don't think that using .well-known > will give us the right binding to the subscription request though. > > Maybe I don't understand the proposal, though. Can you walk through > how a client would use this? > > > If client calls subscribe() - the UA will look for > .well-known/vapid.pub and pass it > in the /subscribe request to the push service. ... So the subscription provider will have to be able to create and maintain a discrete path, the UA will need to make an extra successful data call, just to provide a string that is for public consumption? > > If client calls subscribe( Uint8Array ) - UA will use the explicit key. Again, bit confused here. Granted, the UA's subscribe() function can do whatever it wants once it has the public key. How the server actually enacts the subscription restriction is irrelevant to both the UA and the Subscription provider. The UA can also accept a key in several different formats by doing simple tests. Likewise, how the Application acquires the key is really up to the Application. I'm seeing this more as "suggested practices" and "platform features" rather than part of the specification. > It is a bit simpler to just copy the key in a defined location - in > particular if you have > multiple environments. It is possible to do it in code too ( using the > URL to decide > which key to use ). Some people may also like the more declarative > approach. Huh, I'd argue that it may not always be possible. Some small vendor platforms may not offer access to directories like "/.well-known" (e.g. if you're working with classical Apache, you may be forced to root under "/username/...", or some platforms may prohibit the use of leading "." because of poor path management. I've had to deal with both in the past. Hopefully, I'm must misunderstanding the proposal again. > > Not a big deal - but I think it would be nice. > > Re. Crypto-Key: my understanding was that there are use cases for it, > as a way to > distribute keys, as discussed in the other thread. Subscribe needs > some header > ( or query param ?) to pass the authorized entity to the push service. > We just > don't need it for authorization or encrypted body. > > Costin --------------F0B42A80F6E02EE19ECD0D8F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
FWIW, I'm really not a fan of having an extra data path for things like this. More paths mean more things that folks can screw up or not be able to implement for various reasons.

I think it's HIGHLY reasonable to ask that for a given restricted update, the Application that is making the request include a public key for the VAPID spec. The application could pull it from where ever, hard code it, or whatever makes most sense to the Application developer team (and the corresponding Subscription Update service provider).

Things aren't exactly easy now, making them harder just means that less folks will be able to do it.

On 11/20/2016 8:01 PM, Costin Manolache wrote:


On Sun, Nov 20, 2016 at 5:32 PM Martin Thomson <martin.thomson@gmail.com> wrote:
On 20 November 2016 at 02:53, Costin Manolache <costin@gmail.com> wrote:
> One more small suggestion: one of the pain points ( for me ) is the W3C
> subscribe taking the
> vapid pubkey as bytes instead of a string, and having to include the key in
> .js files as a constant.

Your suggestion being that we define a base64url parser.  You can
include the key in the form Uint8Array.from([4, 5, 6, 6, ...]);  It's
bigger and you have to work itI"m a out once, but it saves shipping a
converter.

Not really - the UA will need to take the uint8[] and convert it to b64 - since that's what 
the push service expects. AFAIK the UA has no use with the vapid public key in current
protocol (except pass it along in subscribe) - we do not pass the Authorization header 
from push service to UA

I'm a bit confused here. If you use most key generation tools like
$ openssl ecparam -name prime256v1 -genkey -noout -out vapid_private.pem
$ openssl ec -in vapid_private.pem -pubout -out vapid_public.pem
$ grep -v "^-" vapid_public.pe
that dumps a b64 string the user can easily work with. Is the suggestion that we ask users to convert to binary themselves? That may reduce the need for base64 in the UA, but means that developers will need to add one. Considering the fun that happened with "lpad" not too long ago, I'm a bit concerned about the frustration that may come with that.

 

Either way, this is probably something to take here:
https://github.com/w3c/push-api/issues

> Would it be possible to define a .well-known/vapid/... file where the public
> key can be saved ?
> This may simplify tools, testing ( test env may use test sender keys), etc.
> One problem is that
> .well-known is at root - so either have
> /.well-known/vapid/ENCODED_SW_URL.pub or
> have a less standard .well-known/ in the same directory with the SW.

Now that we are considering removal of Crypto-Key (I'm about to send
out drafts with that change), I need to work out how to push the keys
along with the registration.  I don't think that using .well-known
will give us the right binding to the subscription request though.

Maybe I don't understand the proposal, though.  Can you walk through
how a client would use this?

If client calls subscribe() - the UA will look for .well-known/vapid.pub and pass it 
in the /subscribe request to the push service.
... So the subscription provider will have to be able to create and maintain a discrete path, the UA will need to make an extra successful data call, just to provide a string that is for public consumption?

If client calls subscribe( Uint8Array ) - UA will use the explicit key.
Again, bit confused here. Granted, the UA's subscribe() function can do whatever it wants once it has the public key. How the server actually enacts the subscription restriction is irrelevant to both the UA and the Subscription provider.

The UA can also accept a key in several different formats by doing simple tests. Likewise, how the Application acquires the key is really up to the Application.

I'm seeing this more as "suggested practices" and "platform features" rather than part of the specification.
It is a bit simpler to just copy the key in a defined location - in particular if you have 
multiple environments. It is possible to do it in code too ( using the URL to decide
which key to use ). Some people may also like the more declarative approach.
Huh, I'd argue that it may not always be possible. Some small vendor platforms may not offer access to directories like "/.well-known" (e.g. if you're working with classical Apache, you may be forced to root under "/username/...", or some platforms may prohibit the use of leading "." because of poor path management. I've had to deal with both in the past.

Hopefully, I'm must misunderstanding the proposal again.

 
Not a big deal - but I think it would be nice. 

Re. Crypto-Key: my understanding was that there are use cases for it, as a way to 
distribute keys, as discussed in the other thread. Subscribe needs some header 
( or query param ?) to pass the authorized entity to the push service. We just 
don't need it for authorization or encrypted body.

Costin


--------------F0B42A80F6E02EE19ECD0D8F-- From nobody Mon Nov 21 15:36:58 2016 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 BDD741294AB for ; Mon, 21 Nov 2016 15:36:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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 V6wOdU1Ph0m7 for ; Mon, 21 Nov 2016 15:36:55 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 12C0B127078 for ; Mon, 21 Nov 2016 15:36:55 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id j65so54129170iof.0 for ; Mon, 21 Nov 2016 15:36:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Jc6Sdg/uJ1Jvh96ojTzuKewbWIMPF0pcFDnCx1sqJZE=; b=cLi3e0E3pwHyN0p0Hi0++NM3lY9MJm8Y9yAacs+OZpRcF0F0vR+sCeGDkw7pywOnAv 5ZkJ6SSFmICPtIbDdziZljLIGjZe0lKzctiMNcLf1z1th7pe3kUpulsik0suTNSc/ieq ARUKVfALHmCEBi4qefx5nSVnCtAjUoxWn9zOW2oPoLx/Cp60Q5/uLHqMUpK47gdRDnmd 0o+r6PUI4S81fxeaPYEty5zWJitFODIyVm6Ef0Gu3fYWvuAd8J6oOcrjVaWjwu9j5n02 IeezD8Py8ut9w6PJJaBbZiQtHA8P4ak8WL4CDRW/uLLWfQUEaDsgAbMPIcS+bFancsvY +3kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Jc6Sdg/uJ1Jvh96ojTzuKewbWIMPF0pcFDnCx1sqJZE=; b=b+1kdHIS8VE0+8BAZ43aDlqpBl+1jaDdPbe46XVswbgEEe/syQL1zZrv5M/1r9Bnvz 4N0Vpq5SrTuSe56TpQjrkN0wvXbvW0AKApUypMRNEitCLODN+VVKE1bQnoAHNDaaTIUE z9wK05w5N7E0lrndXHboCKOjp/Vky4cMuLvDdnN4LMc1cNrH/JaxriucywdfgXdu2o2n qdfA/amE2Ia9P1MW4Q2sJyFWAHsKQQknNqKF+Lzkb1wLDjB6WoxUfQPm+HoldZn/5w5H r09Mc4mAXRDTD0Z0spw7ZjU2ucTW6+6xqhs+Rzoudv9g4kbmfXgwnk2l71atPdMu4fZS mzjA== X-Gm-Message-State: AKaTC01EPXqF3OU/mBHZm3wqP1ib4RESGS6R6LT203McRo6gy4x1lfOTcggmGcriesYeu37BWNSO3NTtuGegPQ== X-Received: by 10.107.2.8 with SMTP id 8mr12834952ioc.83.1479771414141; Mon, 21 Nov 2016 15:36:54 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Costin Manolache Date: Mon, 21 Nov 2016 23:36:43 +0000 Message-ID: To: jr conlin , Martin Thomson Content-Type: multipart/alternative; boundary=001a113978767d215e0541d821aa Archived-At: Cc: "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Vapid public key X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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, 21 Nov 2016 23:36:58 -0000 --001a113978767d215e0541d821aa Content-Type: text/plain; charset=UTF-8 On Mon, Nov 21, 2016 at 9:51 AM jr conlin wrote: > FWIW, I'm really not a fan of having an extra data path for things like > this. More paths mean more things that folks can screw up or not be able to > implement for various reasons. > > I think it's HIGHLY reasonable to ask that for a given restricted update, > the Application that is making the request include a public key for the > VAPID spec. The application could pull it from where ever, hard code it, or > whatever makes most sense to the Application developer team (and the > corresponding Subscription Update service provider). > > Things aren't exactly easy now, making them harder just means that less > folks will be able to do it. > My goal was to make it easier - in particular in cases where it's easy to screw up. If a developer has a test key and a production key ( which is a good idea - you want the prod private key well protected, and dev/testing be done with a different key ), it would be easier to have a different pub key file rather than different .js file or extra complexity/if It is a bit more work for the UA - but not much more. > > > On 11/20/2016 8:01 PM, Costin Manolache wrote: > > On Sun, Nov 20, 2016 at 5:32 PM Martin Thomson > wrote: > > On 20 November 2016 at 02:53, Costin Manolache wrote: > > One more small suggestion: one of the pain points ( for me ) is the W3C > > subscribe taking the > > vapid pubkey as bytes instead of a string, and having to include the key > in > > .js files as a constant. > > Your suggestion being that we define a base64url parser. You can > include the key in the form Uint8Array.from([4, 5, 6, 6, ...]); It's > > bigger and you have to work itI"m a out once, but it saves shipping a > converter. > > > Not really - the UA will need to take the uint8[] and convert it to b64 - > since that's what > the push service expects. AFAIK the UA has no use with the vapid public > key in current > protocol (except pass it along in subscribe) - we do not pass the > Authorization header > from push service to UA > > > I'm a bit confused here. If you use most key generation tools like > $ openssl ecparam -name prime256v1 -genkey -noout -out vapid_private.pem > $ openssl ec -in vapid_private.pem -pubout -out vapid_public.pem > $ grep -v "^-" vapid_public.pe > that dumps a b64 string the user can easily work with. Is the suggestion > that we ask users to convert to binary themselves? That may reduce the need > for base64 in the UA, but means that developers will need to add one. > Considering the fun that happened with "lpad" not too long ago, I'm a bit > concerned about the frustration that may come with that. > My suggestion is to _not_ ask the users to convert to binary ( or array of decimals ) themselves - that's what the current W3C API requires. I'll file the bug when I return (if Peter or someone else doesn't beat me to it :-). And as currently defined, the browser will need to take the Uint8array and b64 encode it before calling the webpush /subscribe. I think it would be better if W3C subscribe would take a string, and just pass it to the push service with no conversions - and let the pushservice deal with it. It would also be more future proof. > > > > > Either way, this is probably something to take here: > https://github.com/w3c/push-api/issues > > > Would it be possible to define a .well-known/vapid/... file where the > public > > key can be saved ? > > This may simplify tools, testing ( test env may use test sender keys), > etc. > > One problem is that > > .well-known is at root - so either have > > /.well-known/vapid/ENCODED_SW_URL.pub or > > have a less standard .well-known/ in the same directory with the SW. > > Now that we are considering removal of Crypto-Key (I'm about to send > out drafts with that change), I need to work out how to push the keys > along with the registration. I don't think that using .well-known > will give us the right binding to the subscription request though. > > Maybe I don't understand the proposal, though. Can you walk through > how a client would use this? > > > If client calls subscribe() - the UA will look for .well-known/vapid.pub > and pass it > in the /subscribe request to the push service. > > ... So the subscription provider will have to be able to create and > maintain a discrete path, the UA will need to make an extra successful data > call, just to provide a string that is for public consumption? > subscribe is not a very frequent event - and a page requires plenty of fetches. The convenience to just copy a file - instead of editing a JS file - may or may not be worth it, I'm not feeling very strongly about it. > > > If client calls subscribe( Uint8Array ) - UA will use the explicit key. > > Again, bit confused here. Granted, the UA's subscribe() function can do > whatever it wants once it has the public key. How the server actually > enacts the subscription restriction is irrelevant to both the UA and the > Subscription provider. > > The UA can also accept a key in several different formats by doing simple > tests. Likewise, how the Application acquires the key is really up to the > Application. > Agreed. UA can also just pass it to push service, and let the push service decide how to interpret it. > I'm seeing this more as "suggested practices" and "platform features" > rather than part of the specification. > > It is a bit simpler to just copy the key in a defined location - in > particular if you have > multiple environments. It is possible to do it in code too ( using the URL > to decide > which key to use ). Some people may also like the more declarative > approach. > > Huh, I'd argue that it may not always be possible. Some small vendor > platforms may not offer access to directories like "/.well-known" (e.g. if > you're working with classical Apache, you may be forced to root under > "/username/...", or some platforms may prohibit the use of leading "." > because of poor path management. I've had to deal with both in the past. > > Hopefully, I'm must misunderstanding the proposal again. > My concern was to make it easier for developers to specify the public key. The '.well-known' was just one idea, keeping the manifest or using a relative path to SW, or anything else is fine too. Costin > > > > Not a big deal - but I think it would be nice. > > Re. Crypto-Key: my understanding was that there are use cases for it, as a > way to > distribute keys, as discussed in the other thread. Subscribe needs some > header > ( or query param ?) to pass the authorized entity to the push service. We > just > don't need it for authorization or encrypted body. > > Costin > > > --001a113978767d215e0541d821aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 21= , 2016 at 9:51 AM jr conlin <jcon= lin@mozilla.com> wrote:
=20 =20 =20
FWIW, I&= #39;m really not a fan of having an extra data path for things like this. More paths mean more things that folks can screw up or not be able to implement for various reasons.


I think it's HIGHLY reasonable to ask that for a given restricted update, the Application that is making the request include a public key for the VAPID spec. The application could pull it from where ever, hard code it, or whatever makes most sense to the Application developer team (and the corresponding Subscription Update service provider).

Things aren't exactly easy now, making them harder just means tha= t less folks will be able to do it.

My goal was to make it easier - in particular in cases where it= 9;s easy to screw up. If a developer has a test key and=C2=A0
a p= roduction key ( which is a good idea - you want the prod private key well p= rotected, and dev/testing be done with
a different key ), it woul= d be easier to have a different pub key file rather than different .js file= or extra complexity/if

It is a bit more work for = the UA - but not much more.
=C2=A0


On 11/20/2016 8:01 PM, Costin Manolache wrote:
On Sun, Nov 20, 2016 at 5:32= PM Martin Thomson <martin.thomson@gmail.com> wrote:
<= div dir=3D"ltr" class=3D"gmail_msg">
On 20 November 2016 at 02:53, Costin Manolache <costin@gmail.com> wrote:
> One more small suggestion: one of the pain points ( for me ) is the W3C
> subscribe taking the
> vapid pubkey as bytes instead of a string, and having to include the key in
> .js files as a constant.

Your suggestion being that we define a base64url parser.=C2=A0 You can
include the key in the form Uint8Array.from([4, 5, 6, 6, ...]);=C2=A0 It's
bigger and you have to work itI"m a out once, but it saves shipping a
converter.

Not really - the UA will need to take th= e uint8[] and convert it to b64 - since that's what=C2=A0
the push service expects. AFAIK the UA h= as no use with the vapid public key in current
protocol (except pass it along in subscr= ibe) - we do not pass the Authorization header=C2=A0
from push service to UA

I'm a bit confused here. If you use most key generation tools like<= br class=3D"gmail_msg"> $ openssl ecparam -name prime256v1 -genkey -noout -out vapid_private.pem
$ openssl ec -in vapid_private.pem -pubout -out vapid_public.pem
$ grep -v "^-" vapid_public.pe
that dumps a b64 string the user can easily work with. Is the suggestion that we ask users to convert to binary themselves? That may reduce the need for base64 in the UA, but means that developers will need to add one. Considering the fun that happened with "lpad= " not too long ago, I'm a bit concerned about the frustration that ma= y come with that.

My suggestion is = to _not_ ask the users to convert to binary ( or array of decimals ) themse= lves - that's what the
current W3C API requires. I'll fil= e the bug when I return (if Peter or someone else doesn't beat me to it= :-).

And as currently defined, the browser will n= eed to take the Uint8array and b64 encode it before calling the=C2=A0
=
webpush /subscribe. I think it would be better if W3C subscribe would = take a string, and just pass it to the push=C2=A0
service with no= conversions - and let the pushservice deal with it.=C2=A0
It wou= ld also be more future proof.
=C2=A0



=C2=A0

Either way, this is probably something to take here:
https://github.com/w3c/push-ap= i/issues

> Would it be possible to define a .well-known/vapid/... file where the public
> key can be saved ?
> This may simplify tools, testing ( test env may use test sender keys), etc.
> One problem is that
> .well-known is at root - so either have
> /.well-known/vapid/ENCODED_SW_URL.pub or
> have a less standard .well-known/ in the same directory with the SW.

Now that we are considering removal of Crypto-Key (I'm abou= t to send
out drafts with that change), I need to work out how to push the keys
along with the registration.=C2=A0 I don't think that using .well-known
will give us the right binding to the subscription request though.

Maybe I don't understand the proposal, though.=C2=A0 Can yo= u walk through
how a client would use this?

If client calls subscribe() - the UA wil= l look for .well-known/vapid.pub and pass it=C2=A0
in the /subscribe request to the push se= rvice.
... So the subscription provider will have to be able to create and maintain a discrete path, the UA will need to make an extra successful data call, just to provide a string that is for public consumption?

subscribe is not a v= ery frequent event - and a page requires plenty of fetches.=C2=A0
The convenience to just copy a file - instead of editing a JS file - may o= r may not be worth it,=C2=A0
I'm not feeling very strongly ab= out it.

=C2=A0


If client calls subscribe( Uint8Array ) = - UA will use the explicit key.
Again, bit confused here. Granted, the UA's subscribe() function ca= n do whatever it wants once it has the public key. How the server actually enacts the subscription restriction is irrelevant to both the UA and the Subscription provider.

The UA can also accept a key in several different formats by doing simple tests. Likewise, how the Application acquires the key is really up to the Application.

Agreed. UA can also just pass it to push service, and= let the push service decide how to interpret it.=C2=A0

=C2=A0
I'm seeing this more as "suggested practices" and "p= latform features" rather than part of the specification.
=C2=A0
It is a bit simpler to just copy the key= in a defined location - in particular if you have=C2=A0
multiple environments. It is possible to= do it in code too ( using the URL to decide
which key to use ). Some people may also= like the more declarative approach.
Huh, I'd argue that it may not always be possible. Some small vendo= r platforms may not offer access to directories like "/.well-known&q= uot; (e.g. if you're working with classical Apache, you may be forced to root under "/username/...", or some platforms may prohibit th= e use of leading "." because of poor path management. I've had = to deal with both in the past.

Hopefully, I'm must misunderstanding the proposal again.

My concern was to make it easier for developers= to specify the public key.
The '.well-known' was just on= e idea, keeping the manifest or using a relative path to SW, or anything el= se
is fine too.

Costin
=C2=A0<= /div>


=C2=A0
Not a big deal - but I think it would be= nice.=C2=A0

Re. Crypto-Key: my understanding was tha= t there are use cases for it, as a way to=C2=A0
distribute keys, as discussed in the oth= er thread. Subscribe needs some header=C2=A0
( or query param ?) to pass the authoriz= ed entity to the push service. We just=C2=A0
don't need it for authorization or e= ncrypted body.

Costin


--001a113978767d215e0541d821aa-- From nobody Mon Nov 21 15:53:42 2016 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 92D6B12950A for ; Mon, 21 Nov 2016 15:53:40 -0800 (PST) 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 n4CYQ08DsRA4 for ; Mon, 21 Nov 2016 15:53:36 -0800 (PST) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (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 CA0261294B0 for ; Mon, 21 Nov 2016 15:53:36 -0800 (PST) Received: by mail-pg0-x22c.google.com with SMTP id p66so620849pga.2 for ; Mon, 21 Nov 2016 15:53:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=MMeADBPozs3dFieZjXPMLchNeobE/3PAj5K+gmqH2ZY=; b=K4PrbJQcChtL1aiIy/CFQ8VzC8bhFq7/YGLmKVLbM2CNN4eIWwe8+KPgIao9SPA7J1 UeSqVEEy3wCL3f2msK83n4h2KPpcZAnodksoZiXma7wcm+0GtqPItufFLarx0ECcP1Bs fvXg6H5AK/Cg03ZP7TaF6vXqX1v2eX9cYB0qQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=MMeADBPozs3dFieZjXPMLchNeobE/3PAj5K+gmqH2ZY=; b=Zc5QF6PVM9i78U0QmHOS/n+U2/l2NlI0LF8lRpMmMOMtdJY1hsgfup2m5ftxAZ9c+g Q899FUMixe1zrH5SHuYaHWcGNXSJwnZTqRIhWyWhWQ4kzhJKHKvg6B4t7X2z2dkx+ICS ZZfsZtShAZrV5I/DEzSAW1bgqSkVS3EFod4pUY+6cEBRl7bpFyH6qNiwxWwVaYchzXbA CWReuWKkyoOL/OHix6oi0MU9GbDWAE6SNoUdLOXgqIs6KlR8D6YwrtHa2LKN1MKtYKFn /6BTfEVQ+zyoRdKfxJrcEwCCOa2QdndX5jQRrsRwYIjvM7BOEaM3S9ZqBxIlJWCnq4f5 0U7Q== X-Gm-Message-State: AKaTC013j+sYhnLlEabDvE2QU8CWB5RpJ8B2pG2Xv+8nVsOSePGRID/TxYny4Yy+lCg3iUjz X-Received: by 10.98.18.6 with SMTP id a6mr21834960pfj.184.1479772415592; Mon, 21 Nov 2016 15:53:35 -0800 (PST) Received: from ?IPv6:2620:101:80fc:224:1c47:3b6:ae44:cb0d? ([2620:101:80fc:224:1c47:3b6:ae44:cb0d]) by smtp.gmail.com with ESMTPSA id 65sm39271886pfl.21.2016.11.21.15.53.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 Nov 2016 15:53:34 -0800 (PST) To: Costin Manolache , Martin Thomson References: From: jr conlin Message-ID: Date: Mon, 21 Nov 2016 15:53:33 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0a2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4C3D068FC064F52F1593CF6A" Content-Language: en-US Archived-At: Cc: "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Vapid public key X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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, 21 Nov 2016 23:53:40 -0000 This is a multi-part message in MIME format. --------------4C3D068FC064F52F1593CF6A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Ah, ok, my apologies. Summing up my understanding: * Yes, having the UA pass the public key string to the push server would be the easiest for the developer. "Ok, here's a key, you deal with it." There would need to be some effort on either the UA or the Push Service to verify that the string is a valid key set, but I believe you're specifying that. As I understand, a provided public key that is determined as being invalid whether by the UA or PS, would return an error to the application. * How that key is passed in to the UA is a point of discussion. It could be provided as part of the static page content provided by the subscription request page, it could be provided via a secondary delivery mechanism (e.g. included as part of a secondary script), it could be fetched by the application out of a well known URL (be it "/.well-known", via the app manifest, or "bobs-discount-public-key-goes-here.js") I'm less inclined to make this bit part of the formal spec so much as offering guidance for how app developers could do this. Various 3rd party sites, hosting sites, or library authors may have differing opinions based on experience and restrictions. * I should not read spec changes over the weekend. Does this properly sum up the changes? (Again, my apologies if I seem dense) On 11/21/2016 3:36 PM, Costin Manolache wrote: > On Mon, Nov 21, 2016 at 9:51 AM jr conlin > wrote: > > FWIW, I'm really not a fan of having an extra data path for things > like this. More paths mean more things that folks can screw up or > not be able to implement for various reasons. > > > > I think it's HIGHLY reasonable to ask that for a given restricted > update, the Application that is making the request include a > public key for the VAPID spec. The application could pull it from > where ever, hard code it, or whatever makes most sense to the > Application developer team (and the corresponding Subscription > Update service provider). > > Things aren't exactly easy now, making them harder just means that > less folks will be able to do it. > > > My goal was to make it easier - in particular in cases where it's easy > to screw up. If a developer has a test key and > a production key ( which is a good idea - you want the prod private > key well protected, and dev/testing be done with > a different key ), it would be easier to have a different pub key file > rather than different .js file or extra complexity/if > > It is a bit more work for the UA - but not much more. > > > > > On 11/20/2016 8:01 PM, Costin Manolache wrote: >> On Sun, Nov 20, 2016 at 5:32 PM Martin Thomson >> > wrote: >> >> On 20 November 2016 at 02:53, Costin Manolache >> > wrote: >> > One more small suggestion: one of the pain points ( for me >> ) is the W3C >> > subscribe taking the >> > vapid pubkey as bytes instead of a string, and having to >> include the key in >> > .js files as a constant. >> >> Your suggestion being that we define a base64url parser. You can >> include the key in the form Uint8Array.from([4, 5, 6, 6, >> ...]); It's >> >> bigger and you have to work itI"m a out once, but it saves >> shipping a >> converter. >> >> >> Not really - the UA will need to take the uint8[] and convert it >> to b64 - since that's what >> the push service expects. AFAIK the UA has no use with the vapid >> public key in current >> protocol (except pass it along in subscribe) - we do not pass the >> Authorization header >> from push service to UA > > I'm a bit confused here. If you use most key generation tools like > $ openssl ecparam -name prime256v1 -genkey -noout -out > vapid_private.pem > $ openssl ec -in vapid_private.pem -pubout -out vapid_public.pem > $ grep -v "^-" vapid_public.pe > that dumps a b64 string the user can easily work with. Is the > suggestion that we ask users to convert to binary themselves? That > may reduce the need for base64 in the UA, but means that > developers will need to add one. Considering the fun that happened > with "lpad" not too long ago, I'm a bit concerned about the > frustration that may come with that. > > > My suggestion is to _not_ ask the users to convert to binary ( or > array of decimals ) themselves - that's what the > current W3C API requires. I'll file the bug when I return (if Peter or > someone else doesn't beat me to it :-). > > And as currently defined, the browser will need to take the Uint8array > and b64 encode it before calling the > webpush /subscribe. I think it would be better if W3C subscribe would > take a string, and just pass it to the push > service with no conversions - and let the pushservice deal with it. > It would also be more future proof. > > > > >> >> >> >> Either way, this is probably something to take here: >> https://github.com/w3c/push-api/issues >> >> > Would it be possible to define a .well-known/vapid/... file >> where the public >> > key can be saved ? >> > This may simplify tools, testing ( test env may use test >> sender keys), etc. >> > One problem is that >> > .well-known is at root - so either have >> > /.well-known/vapid/ENCODED_SW_URL.pub or >> > have a less standard .well-known/ in the same directory >> with the SW. >> >> Now that we are considering removal of Crypto-Key (I'm about >> to send >> out drafts with that change), I need to work out how to push >> the keys >> along with the registration. I don't think that using >> .well-known >> will give us the right binding to the subscription request >> though. >> >> Maybe I don't understand the proposal, though. Can you walk >> through >> how a client would use this? >> >> >> If client calls subscribe() - the UA will look for >> .well-known/vapid.pub and pass it >> in the /subscribe request to the push service. > ... So the subscription provider will have to be able to create > and maintain a discrete path, the UA will need to make an extra > successful data call, just to provide a string that is for public > consumption? > > > subscribe is not a very frequent event - and a page requires plenty of > fetches. > The convenience to just copy a file - instead of editing a JS file - > may or may not be worth it, > I'm not feeling very strongly about it. > > > > >> >> If client calls subscribe( Uint8Array ) - UA will use the >> explicit key. > Again, bit confused here. Granted, the UA's subscribe() function > can do whatever it wants once it has the public key. How the > server actually enacts the subscription restriction is irrelevant > to both the UA and the Subscription provider. > > The UA can also accept a key in several different formats by doing > simple tests. Likewise, how the Application acquires the key is > really up to the Application. > > > Agreed. UA can also just pass it to push service, and let the push > service decide how to interpret it. > > > > I'm seeing this more as "suggested practices" and "platform > features" rather than part of the specification. > > > >> It is a bit simpler to just copy the key in a defined location - >> in particular if you have >> multiple environments. It is possible to do it in code too ( >> using the URL to decide >> which key to use ). Some people may also like the more >> declarative approach. > Huh, I'd argue that it may not always be possible. Some small > vendor platforms may not offer access to directories like > "/.well-known" (e.g. if you're working with classical Apache, you > may be forced to root under "/username/...", or some platforms may > prohibit the use of leading "." because of poor path management. > I've had to deal with both in the past. > > Hopefully, I'm must misunderstanding the proposal again. > > > My concern was to make it easier for developers to specify the public key. > The '.well-known' was just one idea, keeping the manifest or using a > relative path to SW, or anything else > is fine too. > > Costin > > > > >> >> Not a big deal - but I think it would be nice. >> >> Re. Crypto-Key: my understanding was that there are use cases for >> it, as a way to >> distribute keys, as discussed in the other thread. Subscribe >> needs some header >> ( or query param ?) to pass the authorized entity to the push >> service. We just >> don't need it for authorization or encrypted body. >> >> Costin > > --------------4C3D068FC064F52F1593CF6A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Ah, ok, my apologies.

Summing up my understanding:

* Yes, having the UA pass the public key string to the push server would be the easiest for the developer. "Ok, here's a key, you deal with it." There would need to be some effort on either the UA or the Push Service to verify that the string is a valid key set, but I believe you're specifying that. As I understand, a provided public key that is determined as being invalid whether by the UA or PS, would return an error to the application.

* How that key is passed in to the UA is a point of discussion. It could be provided as part of the static page content provided by the subscription request page, it could be provided via a secondary delivery mechanism (e.g. included as part of a secondary script), it could be fetched by the application out of a well known URL (be it "/.well-known", via the app manifest, or "bobs-discount-public-key-goes-here.js") I'm less inclined to make this bit part of the formal spec so much as offering guidance for how app developers could do this. Various 3rd party sites, hosting sites, or library authors may have differing opinions based on experience and restrictions.

* I should not read spec changes over the weekend.

Does this properly sum up the changes?

(Again, my apologies if I seem dense)

On 11/21/2016 3:36 PM, Costin Manolache wrote:
On Mon, Nov 21, 2016 at 9:51 AM jr conlin <jconlin@mozilla.com> wrote:
FWIW, I'm really not a fan of having an extra data path for things like this. More paths mean more things that folks can screw up or not be able to implement for various reasons.


I think it's HIGHLY reasonable to ask that for a given restricted update, the Application that is making the request include a public key for the VAPID spec. The application could pull it from where ever, hard code it, or whatever makes most sense to the Application developer team (and the corresponding Subscription Update service provider).

Things aren't exactly easy now, making them harder just means that less folks will be able to do it.

My goal was to make it easier - in particular in cases where it's easy to screw up. If a developer has a test key and 
a production key ( which is a good idea - you want the prod private key well protected, and dev/testing be done with
a different key ), it would be easier to have a different pub key file rather than different .js file or extra complexity/if

It is a bit more work for the UA - but not much more.
 


On 11/20/2016 8:01 PM, Costin Manolache wrote:
On Sun, Nov 20, 2016 at 5:32 PM Martin Thomson <martin.thomson@gmail.com> wrote:
On 20 November 2016 at 02:53, Costin Manolache <costin@gmail.com> wrote:
> One more small suggestion: one of the pain points ( for me ) is the W3C
> subscribe taking the
> vapid pubkey as bytes instead of a string, and having to include the key in
> .js files as a constant.

Your suggestion being that we define a base64url parser.  You can
include the key in the form Uint8Array.from([4, 5, 6, 6, ...]);  It's
bigger and you have to work itI"m a out once, but it saves shipping a
converter.

Not really - the UA will need to take the uint8[] and convert it to b64 - since that's what 
the push service expects. AFAIK the UA has no use with the vapid public key in current
protocol (except pass it along in subscribe) - we do not pass the Authorization header 
from push service to UA

I'm a bit confused here. If you use most key generation tools like
$ openssl ecparam -name prime256v1 -genkey -noout -out vapid_private.pem
$ openssl ec -in vapid_private.pem -pubout -out vapid_public.pem
$ grep -v "^-" vapid_public.pe
that dumps a b64 string the user can easily work with. Is the suggestion that we ask users to convert to binary themselves? That may reduce the need for base64 in the UA, but means that developers will need to add one. Considering the fun that happened with "lpad" not too long ago, I'm a bit concerned about the frustration that may come with that.

My suggestion is to _not_ ask the users to convert to binary ( or array of decimals ) themselves - that's what the
current W3C API requires. I'll file the bug when I return (if Peter or someone else doesn't beat me to it :-).

And as currently defined, the browser will need to take the Uint8array and b64 encode it before calling the 
webpush /subscribe. I think it would be better if W3C subscribe would take a string, and just pass it to the push 
service with no conversions - and let the pushservice deal with it. 
It would also be more future proof.
 



 

Either way, this is probably something to take here:
https://github.com/w3c/push-api/issues

> Would it be possible to define a .well-known/vapid/... file where the public
> key can be saved ?
> This may simplify tools, testing ( test env may use test sender keys), etc.
> One problem is that
> .well-known is at root - so either have
> /.well-known/vapid/ENCODED_SW_URL.pub or
> have a less standard .well-known/ in the same directory with the SW.

Now that we are considering removal of Crypto-Key (I'm about to send
out drafts with that change), I need to work out how to push the keys
along with the registration.  I don't think that using .well-known
will give us the right binding to the subscription request though.

Maybe I don't understand the proposal, though.  Can you walk through
how a client would use this?

If client calls subscribe() - the UA will look for .well-known/vapid.pub and pass it 
in the /subscribe request to the push service.
... So the subscription provider will have to be able to create and maintain a discrete path, the UA will need to make an extra successful data call, just to provide a string that is for public consumption?

subscribe is not a very frequent event - and a page requires plenty of fetches. 
The convenience to just copy a file - instead of editing a JS file - may or may not be worth it, 
I'm not feeling very strongly about it.

 


If client calls subscribe( Uint8Array ) - UA will use the explicit key.
Again, bit confused here. Granted, the UA's subscribe() function can do whatever it wants once it has the public key. How the server actually enacts the subscription restriction is irrelevant to both the UA and the Subscription provider.

The UA can also accept a key in several different formats by doing simple tests. Likewise, how the Application acquires the key is really up to the Application.

Agreed. UA can also just pass it to push service, and let the push service decide how to interpret it. 

 
I'm seeing this more as "suggested practices" and "platform features" rather than part of the specification.
 
It is a bit simpler to just copy the key in a defined location - in particular if you have 
multiple environments. It is possible to do it in code too ( using the URL to decide
which key to use ). Some people may also like the more declarative approach.
Huh, I'd argue that it may not always be possible. Some small vendor platforms may not offer access to directories like "/.well-known" (e.g. if you're working with classical Apache, you may be forced to root under "/username/...", or some platforms may prohibit the use of leading "." because of poor path management. I've had to deal with both in the past.

Hopefully, I'm must misunderstanding the proposal again.

My concern was to make it easier for developers to specify the public key.
The '.well-known' was just one idea, keeping the manifest or using a relative path to SW, or anything else
is fine too.

Costin
 


 
Not a big deal - but I think it would be nice. 

Re. Crypto-Key: my understanding was that there are use cases for it, as a way to 
distribute keys, as discussed in the other thread. Subscribe needs some header 
( or query param ?) to pass the authorized entity to the push service. We just 
don't need it for authorization or encrypted body.

Costin



--------------4C3D068FC064F52F1593CF6A-- From nobody Thu Nov 24 16:22:55 2016 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 254ED129D5F for ; Thu, 24 Nov 2016 16:22:53 -0800 (PST) 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 jB06UXkZ3SaS for ; Thu, 24 Nov 2016 16:22:51 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 51CDF129FF5 for ; Thu, 24 Nov 2016 16:22:49 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id c47so52694523qtc.2 for ; Thu, 24 Nov 2016 16:22:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l2cLHiY2EFbEnI5hXhTu8se5yKtCWZ0JlPVBMV6YrXM=; b=ylhVqKMC3s6VojupPJ2yVI8WKCyenz+tc7drOBrUNji0LeeS3CmlNyJlfS5fkj6UYt sdUmDs6WJECllHYKgv8BE3iyS95EwjfeZcfLx9I8lJzjt3VXgPAi3iSBZnAePLrQBVex 8bAb9K4F8JPvAOmsRCKHYZyGKDaOzypeqdwQ1hDEIF2Oz2uNaUoxj2H46Igxazm/kwsO nVH6EbV8oDMmFo2UrU6H8JaAsUm6grXNKMaaohIzMQ4bj2t+M1fkauyvliTOAGdLjUQt l1rSjFuv6/qnOVwc5bbeQOxBvPpVVjH+KMCY/LlMOGVuOl7dhhyNYtgcxSEm/YVoBoqO 4a9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l2cLHiY2EFbEnI5hXhTu8se5yKtCWZ0JlPVBMV6YrXM=; b=UMzYehmzY0k7OQAd7Ogu/HP+RC6y+jNC6/oR1n+W4wTgr0/aRrIz2Bnibi13Z6wtqg 7NnEWQ2pSuSEJVe97fPpf/9TWqSjVTpPZeCGyesqsibimupUV4R55qyLzddaDnLIigyq 4x56lw2qy0T2erkdKBxdDNyR4iBoGc2REmp4VqdXswwt8rbRPxgB0bgtGSS8e+f51I/u DXriFN/lhXYOjcqN2wQmCNTDTdTRwGDltPefFEewZs/+e+iWXQY+gcbyP5cQtnYfleJX rlH0uLEhmDWry2JEJYK/TAQN+NBdWTrMuk+3zSfJZaS5KJ7K/lBCCDDjXKpZYi3eZy35 ruRQ== X-Gm-Message-State: AKaTC00BaZWCWE+qCrn0lO8F/Cei8DdGR7tWr1mTKEQgnMGaox88NlnC3RWM3ONzpAKYpvX5tE/jlUx1HYn8fQ== X-Received: by 10.200.46.249 with SMTP id i54mr4256813qta.13.1480033368291; Thu, 24 Nov 2016 16:22:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.101 with HTTP; Thu, 24 Nov 2016 16:22:47 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Fri, 25 Nov 2016 11:22:47 +1100 Message-ID: To: jr conlin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Costin Manolache , "webpush@ietf.org" , Peter Beverloo Subject: Re: [Webpush] Vapid public key X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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, 25 Nov 2016 00:22:53 -0000 I think that we should discuss this over on the W3C side: Opened: https://github.com/w3c/push-api/issues/226 On 22 November 2016 at 10:53, jr conlin wrote: > Ah, ok, my apologies. > > Summing up my understanding: > > * Yes, having the UA pass the public key string to the push server would be > the easiest for the developer. "Ok, here's a key, you deal with it." There > would need to be some effort on either the UA or the Push Service to verify > that the string is a valid key set, but I believe you're specifying that. As > I understand, a provided public key that is determined as being invalid > whether by the UA or PS, would return an error to the application. > > * How that key is passed in to the UA is a point of discussion. It could be > provided as part of the static page content provided by the subscription > request page, it could be provided via a secondary delivery mechanism (e.g. > included as part of a secondary script), it could be fetched by the > application out of a well known URL (be it "/.well-known", via the app > manifest, or "bobs-discount-public-key-goes-here.js") I'm less inclined to > make this bit part of the formal spec so much as offering guidance for how > app developers could do this. Various 3rd party sites, hosting sites, or > library authors may have differing opinions based on experience and > restrictions. > > * I should not read spec changes over the weekend. > > Does this properly sum up the changes? > > (Again, my apologies if I seem dense) > > > On 11/21/2016 3:36 PM, Costin Manolache wrote: > > On Mon, Nov 21, 2016 at 9:51 AM jr conlin wrote: >> >> FWIW, I'm really not a fan of having an extra data path for things like >> this. More paths mean more things that folks can screw up or not be able to >> implement for various reasons. > > >> >> I think it's HIGHLY reasonable to ask that for a given restricted update, >> the Application that is making the request include a public key for the >> VAPID spec. The application could pull it from where ever, hard code it, or >> whatever makes most sense to the Application developer team (and the >> corresponding Subscription Update service provider). >> >> Things aren't exactly easy now, making them harder just means that less >> folks will be able to do it. > > > My goal was to make it easier - in particular in cases where it's easy to > screw up. If a developer has a test key and > a production key ( which is a good idea - you want the prod private key well > protected, and dev/testing be done with > a different key ), it would be easier to have a different pub key file > rather than different .js file or extra complexity/if > > It is a bit more work for the UA - but not much more. > >> >> >> >> On 11/20/2016 8:01 PM, Costin Manolache wrote: >> >> On Sun, Nov 20, 2016 at 5:32 PM Martin Thomson >> wrote: >>> >>> On 20 November 2016 at 02:53, Costin Manolache wrote: >>> > One more small suggestion: one of the pain points ( for me ) is the W3C >>> > subscribe taking the >>> > vapid pubkey as bytes instead of a string, and having to include the >>> > key in >>> > .js files as a constant. >>> >>> Your suggestion being that we define a base64url parser. You can >>> include the key in the form Uint8Array.from([4, 5, 6, 6, ...]); It's >>> >>> bigger and you have to work itI"m a out once, but it saves shipping a >>> converter. >> >> >> Not really - the UA will need to take the uint8[] and convert it to b64 - >> since that's what >> the push service expects. AFAIK the UA has no use with the vapid public >> key in current >> protocol (except pass it along in subscribe) - we do not pass the >> Authorization header >> from push service to UA >> >> >> I'm a bit confused here. If you use most key generation tools like >> $ openssl ecparam -name prime256v1 -genkey -noout -out vapid_private.pem >> $ openssl ec -in vapid_private.pem -pubout -out vapid_public.pem >> $ grep -v "^-" vapid_public.pe >> that dumps a b64 string the user can easily work with. Is the suggestion >> that we ask users to convert to binary themselves? That may reduce the need >> for base64 in the UA, but means that developers will need to add one. >> Considering the fun that happened with "lpad" not too long ago, I'm a bit >> concerned about the frustration that may come with that. > > > My suggestion is to _not_ ask the users to convert to binary ( or array of > decimals ) themselves - that's what the > current W3C API requires. I'll file the bug when I return (if Peter or > someone else doesn't beat me to it :-). > > And as currently defined, the browser will need to take the Uint8array and > b64 encode it before calling the > webpush /subscribe. I think it would be better if W3C subscribe would take a > string, and just pass it to the push > service with no conversions - and let the pushservice deal with it. > It would also be more future proof. > > >> >> >> >>> >>> >>> Either way, this is probably something to take here: >>> https://github.com/w3c/push-api/issues >>> >>> > Would it be possible to define a .well-known/vapid/... file where the >>> > public >>> > key can be saved ? >>> > This may simplify tools, testing ( test env may use test sender keys), >>> > etc. >>> > One problem is that >>> > .well-known is at root - so either have >>> > /.well-known/vapid/ENCODED_SW_URL.pub or >>> > have a less standard .well-known/ in the same directory with the SW. >>> >>> Now that we are considering removal of Crypto-Key (I'm about to send >>> out drafts with that change), I need to work out how to push the keys >>> along with the registration. I don't think that using .well-known >>> will give us the right binding to the subscription request though. >>> >>> Maybe I don't understand the proposal, though. Can you walk through >>> how a client would use this? >> >> >> If client calls subscribe() - the UA will look for .well-known/vapid.pub >> and pass it >> in the /subscribe request to the push service. >> >> ... So the subscription provider will have to be able to create and >> maintain a discrete path, the UA will need to make an extra successful data >> call, just to provide a string that is for public consumption? > > > subscribe is not a very frequent event - and a page requires plenty of > fetches. > The convenience to just copy a file - instead of editing a JS file - may or > may not be worth it, > I'm not feeling very strongly about it. > > >> >> >> >> If client calls subscribe( Uint8Array ) - UA will use the explicit key. >> >> Again, bit confused here. Granted, the UA's subscribe() function can do >> whatever it wants once it has the public key. How the server actually enacts >> the subscription restriction is irrelevant to both the UA and the >> Subscription provider. >> >> The UA can also accept a key in several different formats by doing simple >> tests. Likewise, how the Application acquires the key is really up to the >> Application. > > > Agreed. UA can also just pass it to push service, and let the push service > decide how to interpret it. > > >> >> I'm seeing this more as "suggested practices" and "platform features" >> rather than part of the specification. > > >> >> It is a bit simpler to just copy the key in a defined location - in >> particular if you have >> multiple environments. It is possible to do it in code too ( using the URL >> to decide >> which key to use ). Some people may also like the more declarative >> approach. >> >> Huh, I'd argue that it may not always be possible. Some small vendor >> platforms may not offer access to directories like "/.well-known" (e.g. if >> you're working with classical Apache, you may be forced to root under >> "/username/...", or some platforms may prohibit the use of leading "." >> because of poor path management. I've had to deal with both in the past. >> >> Hopefully, I'm must misunderstanding the proposal again. > > > My concern was to make it easier for developers to specify the public key. > The '.well-known' was just one idea, keeping the manifest or using a > relative path to SW, or anything else > is fine too. > > Costin > >> >> >> >> >> Not a big deal - but I think it would be nice. >> >> Re. Crypto-Key: my understanding was that there are use cases for it, as a >> way to >> distribute keys, as discussed in the other thread. Subscribe needs some >> header >> ( or query param ?) to pass the authorized entity to the push service. We >> just >> don't need it for authorization or encrypted body. >> >> Costin >> >> > From nobody Sun Nov 27 15:16:00 2016 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 1997112958B for ; Sun, 27 Nov 2016 15:15:59 -0800 (PST) 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 snkQmY16UZvr for ; Sun, 27 Nov 2016 15:15:57 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 8235C12957A for ; Sun, 27 Nov 2016 15:15:57 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id n21so124000534qka.3 for ; Sun, 27 Nov 2016 15:15:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=6wgteQ4BVCY2Ah+G+iyCnLbYuN+IA2Cnv0MySIKx08k=; b=XBGjWoFKSGLl+r3qcrDc5uv2N14nhHbPGNxsAfFfMT/awPnnBy/TriJZCSDFqsed8v P6YJiWujZb9mjwqd9x4I2rnHeFvhF9iw0djXRpPUYQ5EJXB/aIwbVqhMHCFs0E/QiIwp t4Hy1E2ITRWSC/LRlpfMKp6zuGqBYhZt3iog28bMh4oBBq9AoAx745GrOdEh9Hse5cig BMEUgwLTKOxtOst5Y2UkwYcDemiPkgq4/vrPqzadGqJGcSjAB465HmDqc3UwJdr9uVU9 +rGry9Ni6V8/tWpKy3N8f3V7md/4Xh5queT3/YsAtG0zHpR5xSAhClcuvWY1twe79GGo aORA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=6wgteQ4BVCY2Ah+G+iyCnLbYuN+IA2Cnv0MySIKx08k=; b=fIWYHLPnHv3sFM99mTfZAaDvSp80HBJapL7V4KPAxgKBpunXJaT8XVTnvfCM5noM2u RW3B2E/BhDPKies776UAMu9yo7AlnUufOzD8auWSMeZAaXtuzKderqTS+gNJgbTItzZy /ds3pakSQaUcdoD+2EKmSiNmBL27+ry99CRRypl0aeO9nJVlA/6k4W/ql3Ld6K3SBSLE 7fE5GQ0DnpQ3n+5beI4+gFARVB90nqxhFrQ1VwyzKQ4ys7tN3x9ZEp9upZB1VGHzlcB8 1ij8f7Y1oxhjRuHTdVU4atQNl6+QMfJyWC322Y52xpXa6GjeWGYFGk8T10MfM6U7wHvs /GAA== X-Gm-Message-State: AKaTC01cH/iRQbRCq81t1PFIgTHJks2X8OMmZYKwupEdNfcRCkUh0Tf/dXBl9Wxp2n/6VSZkQPeh6oKb98PmfQ== X-Received: by 10.55.158.199 with SMTP id h190mr17854698qke.202.1480288556502; Sun, 27 Nov 2016 15:15:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.101 with HTTP; Sun, 27 Nov 2016 15:15:56 -0800 (PST) From: Martin Thomson Date: Mon, 28 Nov 2016 10:15:56 +1100 Message-ID: To: "webpush@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Webpush] Restricting subscriptions to vapid public keys X-BeenThere: webpush@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 27 Nov 2016 23:15:59 -0000 I've opened a PR that removes the final use of the Crypto-Key header field. A restricted subscription is created by adding a JSON body to the subscription request: https://github.com/webpush-wg/webpush-vapid/pull/31 This is the final change that I'm aware we need for dealing with the changes on the HTTP side of things. I'll be submitting updates to all the drafts soon, but I'd appreciate some feedback before I do that.