Re: [Webpush] Major change to encryption

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
>
>