Re: [Webpush] Major change to encryption

[Costin Manolache <[e-mail]>]

I'm not suggesting removing the Crypto-Key as optimization - but for
consistency.
If we send the salt and the keyid in the binary payload, we should also
include the dh key.

In particular, it makes it much easier to send webpush binary messages with
alternate transports - like Websocket or WiSH (https://tools.ietf.org/html/
draft-yoshino-wish-00 <https://tools.ietf.org/html/draft-yoshino-wish-00>)
if push promises are not available.
Technically having headers or binary prefix is equivalent for single
message with push
promises, or for the send API. But if the message has to be layered on a
different transport -
it gets tricky, with more complexity and chances of bugs.



Costin



On Mon, Oct 31, 2016 at 3:38 AM Martin Thomson <[e-mail]>
wrote:

Discussion in the HTTP working group has lead to some fairly
substantial changes to the spec that we rely on.  These are breaking
changes.  See the changes here:
https://github.com/httpwg/http-extensions/pull/252

In short, several of the parameters that were in header fields are now
in the body of the message and the Encryption header field is now
gone.

This completely messes with the use of that spec in Webpush.  It's
easy to detect which version is in use because the identifier has
changed, and there are small gains to be had.  The overall message
size is now slightly smaller, and the key derivation is now slightly
simpler.  The specs also have fewer interdependencies as a result.

I've put together a revision of the webpush-encryption draft.  I've
taken this opportunity to simplify things a little.  You can see a
preview in the editor's draft:

  https://webpush-wg.github.io/webpush-encryption/

I realize that this is a fairly big (and late) change.  I remain
optimistic that it will be the last. Feedback on the changes are
positive so far [1].

I plan to submit this doc very soon, ahead of the draft submission
deadline.  I realize that's short notice, but I'm fully prepared to
back out this change if necessary.

--Martin

[1] Costin suggested that we might also remove Crypto-Key.  That is
technically possible, though it's probably excessively kludgy, the DH
key could be moved to the keyid field.  I'm leery of that sort of
optimization, but I'm willing to be convinced that this is a special
enough case (I don't think that it is that special, but have at it).

_______________________________________________
Webpush mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/webpush