Re: [Webpush] Major change to encryption

[Costin Manolache <[e-mail]>]

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

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