Re: [Webpush] Major change to encryption

[jr conlin <[e-mail]>]

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
> <[e-mail] <mailto:[e-mail]>> 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 <[e-mail]
>     <mailto:[e-mail]>> 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
>     <[e-mail] <mailto:[e-mail]>>
>     > wrote:
>     >>
>     >> On 1 November 2016 at 10:07, jr conlin <[e-mail]
>     <mailto:[e-mail]>> 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
>     >> [e-mail] <mailto:[e-mail]>
>     >> https://www.ietf.org/mailman/listinfo/webpush
>     >
>     >
>
>     _______________________________________________
>     Webpush mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/webpush
>