Intent to Implement and Ship: draft-ietf-webpush-encryption-08

[Peter Beverloo]

Contact emails

pe...@chromium.org 

 

Spec

https://tools.ietf.org/html/draft-ietf-webpush-encryption-08

https://tools.ietf.org/html/draft-ietf-httpbis-encryption-encoding-09

 

Summary

We currently support the `aesgcm` content coding for encrypted push message payloads, which is based on a previous version of the webpush-encryption draft:

 

https://tools.ietf.org/html/draft-ietf-webpush-encryption-03

 

The latest version, draft 8, makes a number of changes to the steps necessary to transform a payload. The content coding of this version is identified as `aes128gcm`. Input for the transformations remains the same. Developers will implement support on their application server.

 

https://tools.ietf.org/html/draft-ietf-webpush-encryption-08

 

As part of this change, support for the `aes128gcm` content coding will be advertised in the PushManager.supportedContentEncodings property, assuming that Intent gets approved, enabling phased updates of their server-sided code.

 

Motivation

We should support the latest version of the encryption scheme. Support is already mandated by the W3C Push API:

 

https://w3c.github.io/push-api/#dom-pushmanager-supportedcontentencodings

 

Interoperability and Compatibility Risk

Some. The draft is currently in last call phase after which it’ll go out for wider review. httpbis-encryption-encoding-09 was already approved as a Proposed Standard.

 

We’ll disable support in time for M60 beta in case breaking changes are necessary, but we’re not expecting this. 

 

Edge: No signals

Firefox: Public support (https://bugzilla.mozilla.org/show_bug.cgi?id=1345665)

Safari: No signals

Web developers: No signals

 

We’ll continue to support both versions for the foreseeable future, and will work with libraries and large partners to help them update to the new format when it’s commonly supported. This should enable a deprecation path later on.

Ongoing technical constraints

None.

 

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

All but Android WebView, where the Push API is not supported.

 

OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=679789

 

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5665412549181440

 

Requesting approval to ship?

Yes

 

[Rick Byers]

Is there any plan for interoperability testing for IETF protocol specs like this?   Our current template includes this section, but I'm not sure exactly how it should apply in the case of a protocol spec.  web-platform-test isn't specifically about W3C specs, but what is the testing strategy for this IETF group generally?

Is this feature fully tested by web-platform-tests?

Please link to the test suite. If any part of the feature is not tested by web-platform-tests, please include links to issues, e.g.:

• A web-platform-tests issue with the "infra" label explaining why a certain thing cannot be tested. (example)

• A spec issue for some change that would make it possible to test. (example)

• A Chromium issue to upstream some existing tests. (example)

An Intent to Ship requires either a web platform test suite or such issues to be filed explaining why such a test suite is currently impossible or in the progress of being upstreamed.

[d...@google.com]

Some spec feedback from Quan Nguyen:

I would suggest adding a section about verifying peer's public key is on the private key's curve in ECDH protocol. Without this check, for the curve that they use P-256, it would allow attacker to extract the private key.

Peter, are you a member of the IETF group developing the spec?

[Peter Beverloo]

Hi Rick,

I've already filed an issue against web-platform-tests covering the Push API. It briefly talks about a possibility in including the protocol in such tests.

https://github.com/w3c/web-platform-tests/issues/5630

There is no shared test suite for the Web Push Protocol (RFC8030). The semantics that developers are being exposed to are straightforward and, beyond a few bugs in header parsing, we have not seen major issues. There are also features, notably delivery receipts, that none of the push services backing browsers support yet.

Specifically to the encryption draft, the binary and mathematical nature of doing these transformations means that it either works, or it doesn't. This is confirmed through the reference tests included in the drafts, which we have (for -03) and will have (for -08) as unit tests.

Sorry for missing this section in my intents. Since the Intent to Implement template still includes the "requesting approval to ship" bit, perhaps it should be updated to include it.

Thanks,

Peter

[Peter Beverloo]

Hi David,

Yes, I am a member of the working group and have relayed Quan's feedback. Thanks! :)

Thanks,

Peter

[Chris Harrelson]

LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Rick Byers]

Thanks Peter, LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-Ns9D-UPRLB3_sYv7bPGmgPJZ_aH6JVF%3Dr5b8NFN7j-Q%40mail.gmail.com.

[Jochen Eisinger]

lgtm3

Thanks Peter, LGTM2

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-Ns9D-UPRLB3_sYv7bPGmgPJZ_aH6JVF%3Dr5b8NFN7j-Q%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-AiwOq4nhNjRzXgyEGZc6-Q7GtUPT4QjWOUa_vWmE0Kw%40mail.gmail.com.