Minutes for WEBPUSH at IETF-93
minutes-93-webpush-1

Webpush IETF 93

Thursday July 23rd 2015 1740-1910
XMPP: webpush@jabber.ietf.org

#### Action Items ####

1. Chairs:
1.1. Announce the use of github for managing the work.

2. Author of core-protocol draft:
2.1. Send the use-case for Ack’s acknowledgement.
2.2. Look into Server authentication Google is using and see if it can be
    adopted.

3. Mike
3.1. Send out report on current status of crypt algorithm supported by
   common dev platform.

#### Summary / Conclusions ####

1. Issue about reliability was discussed regarding the core protocol.
- There was a general consensus to support “Full Reliability” whereby
push and acknowledgement messages are both stored and retried until TTL expires.
- Whether TTL be same for both acknowledgment and push message need to be
debated. - There were some debates about the needs for NACK. - For malformed
message (AS > PS), some believed that 5xx or 4xx be sufficient. - NACK for when
TTL expires is something to consider.

- Discussion about whether acknowledgement is needed for acknowledgement itself
need to be discussed further. The feeling of the room was relatively strong
inclination not to do this.

2. Issue about Crypto
- General feeling was because ease of deployment is critical, there was more
 voice favoring 256.
- Mike was going to send in the current status of the crypto algorithm supported
 by common dev platform informing the discussion.

3. Security draft
- Will work on them separately. May merge the draft into core-protocol, may not.
 AD made a point that neither will progress through IESG unless both are ready.
 If milestone is needed, it’s not an issue.

#### Detail Notes ####

** Status and Agenda Bashing (Chairs) **********************

Floor: No bashing

Shida: Presented use of github for all subsequent work and send out a note on
how to use it (based on the success of httpbis)

Peter: Announced the availability of the prototype for web push (specifically
section 5). Included in chrome  with the GCM.

** Baseline document (E. Damaggio / Martin Thomson) ********

- ISSUE 1 : Reliabilty --------

Slide 1 - Mobile devices are always offline and PS provide reliable delivery
function. Provided an overview of push messaging functionality.

Slide 2 - Talked about acknowledgement of push message delivery and the need
for it for applications (at least some of them)

Slide 3 - Currently UA/client is required to ack every message received.
Decided to make it mandatory because complexity associated with making it
optional is probably not worth it

Slide 4 - Explained flow of positive ack. (Question from Joe from the mic -
clarifying that the ack is an indication that the application actually
received/processed it).

Slide 5 - Scenario 2 - Explained flow of push message timing out before the
UA/client gets a chance to retrieve it. Options are the AS can also maintain a
timer and if it didn’t receive a receipt, it assumes the message was not
delivered. Option 2 is that the PS can send back a nack

Robert Spark: Do you want to be able to tell the diff between the UA didn’t
come online and the UA somehow crashed or something else happened).

Martin Thomson: Currently the AS will keep trying and after a certain time,
give up and determine the client’s offline.

Dan Druta: Scenario describes the life cycle of only one message, if the server
sends 2 (in succession) where the next one supersedes the earlier, how to
handle suppression. Let the app handle that, or do something else?

Martin Thomson: There can be a separate draft that allows collapsing and other
processing on top of the main architecture.

Phil: What is the correlation between user agent and subscription. Presented a
scenario where multiple UA’s wanting to subscribe to the same stream.

Slide 6 - Scenario 3 - Flow of where PS gives up where for unknown reasons the
UA/client does not ack (maybe because its unresponsive/broken)

Slide 7 - Scenario 4 - Ack failure - PS operators can handle a very sizable
traffic. The AS may not always ask for ack and the question is how do PS’s
handle this.

Slide 8 - Reliability of ack

Slide 9 - Option 1 for ack reliability - No reliability of ack (only end-to-end
ack). See slide for implications. Mostly unacceptable to everyone
   Option 2 - Push reliability only - Push messages are stored up to the agreed
   upon TTL messages are retried but ACK’s are not. assumes that the AS can be
   offline Option 3 - Full reliability of PS - Push messages are stored and
   retried and so are acknowledgements. Use same TTL for messages and
   acknowledgements Option 4 - PS chooses between 2 and 3

???: Is it PS chooses or AS indicates. IF AS chooses then the implication is
that PS does have to implement ack storage and retrying.

Slide XX - Proposal - pick one proposing the “Full Reliability”

Franchesco: Application level semantics is not the job of the PS, but the PS
should be attempting to deliver and let know that….

Martin: By default the TTL is 0 of not specified. The PS gets to choose what
max TTL it supports and indicates it by restricting it to the max TTL it
supports in the response to a request that is asking for TTL higher than PS’s
max

Costin: Device is expected to be offline for long times. AS’s may have more
stringent requirements and should be coming online more often. Explained that
we may need some sort of storage even for TTL=0.

Franchsco: There should not be a “nack”.

Elios: Commenting on the benefit of “nack”. Makes it easier for AS to determine
how/when to retry.  If the message is poisonous in some way such that UA is not
able ack a message. We don’t want the AS to keep trying it again and instead
want the AS to know that for some reason the message is not acceptable to the
UA/client.

Martin: “nack” can also be used in cases where the PS gives up (maybe coz it
became overloaded).

Franchesco: Arguing against the need for “nack"

Ellio:  Countered with uses for “nack”. AS’s can have bad code and we want to
try to handle such things.

Robert: provided example - AS sends a push to PS, the PS sends a push to the UA
and crashes it. The PS should be able to say to the AS “don’t send that message
again"

Joe: Maybe there is some other way to tell the dev/user that there’s issues
with the messages being sent

Franchesco: Message contains metadata and UA cannot know that message is
poisoned. The only entity that can know is the actual application

Andrew: The fact that UA crashed does not mean the message was bad. Could be UA
cannot handle the message size. Low memory / IoT etc.

Dan: There are cases where nack is needed and cases where its not needed.

Martin: Trying to find a middle ground. One PS can detect delivery failure and
send a “nack”. Other one can just keep crashing

Ellio: Providing an example of situations in which nack can be generated. For
IoT use cases,if the single purpose clients are not able to successfully handle
messages, you want to know that asap.

Costin: We can give the advice that AS’s should not attempt to send the same
message again if it receives a “nack” from PS.

Joe: Concerned if the goal of the WG is clear in terms of what “reliability”
features need to be addressed as part of the solution? The issue of what are we
trying to solve, is coming up again and again and if we can figure out some
compromising path. How stringent are we on specific needs/requirements

Franchesco: Agreed that there’s a separate use case where a “nack” may be
useful.

Feeling the room by chair: Everyone leaning and ok with full reliability

Acknowledging ACK’s

Martin: In some of the services the ACK’s actually carry data. We may handle
this in the future

Dan: Please covere this.

Joe: We “pin” this topic and discuss offline first.

Martin: Send the info to the list.

-- ISSUE 2 : What Crypto to use? --------

Push Crypto - Martin hoping to get a number of questions answered.
Slide 1 - Changes - Summarizes where we are at. the http-encryption draft
updated to match TLS 1.3 changes. The record structure has been simplified for
Push. Currently its required that someone sending a Push message use a single
record and receiver required to check for truncation.

Questions from Martin
Q1 - Choice of Curve - P-256 vs 25519 - better deployment vs better crypto

Asked Mike/Peter and Matt Miller to provide comments

Mike: Mentioned that he’s speaking on behalf of Microsoft. MS wants to use P256
because its more deployed

Peter: Provided explanation regarding the status of crypto capabilities.
Suggesting to go for 25519. Martin asked if there’s something we can do to help
deployment of 25519. Peter provided an overview of what Google is doing.

Matt Miller: usually P256 is available because its available in openssl.
There’s a large base of Java applications that also has P256 support. And P-256
also available in all Microsoft crypto libraries also.

Mike: Joe asked question if the same approach is being used for COSE (the
approach for going with P256 now and then be prepared to change as deployment
of 25519 improves)

Martin asked question about JWE’s support. Mike to send some data regarding
that.

Will have continuing discussion on the list based on info shared

Application Server Authentication

See Slide - Currently rely on confidentiality of URL’s and DH shares. concern
raised (by David Benjamin) regarding URL leakage. Public Keys are not treated
with sufficient care. Suggesting use of HMAC. Martin explained how to go about
doing it. Bits can be provided to the AS along with the URI’s by the PS. The AS
uses it along with each message to generate HMAC.

Costin - Mentioned that GCM requires authentication. Not decided which one but
its critical to include AS authentication. Martin commented  - We can look at
what Google has implemented and see if we can adapt/use that.

** Low Energy Requirements for WebPush (Herve Ruellan) *****

Talk about energy requirements.
Slide 1 - Explains where all the energy is consumed in regard to receiving
real-time notifications. Web push is a good first step but can be improved
Slide 2 - TCP Keep-Alive. Required by intermediaries to keep connection open.
Provides stats on what ISP’s require and how much energy is consumed Slide 3 -
HTTP/2 Ping - That will also consume energy Slide 4 - Consecutive notifications
- They should be grouped. Similar to TCP Nagle also. Slide 5 - Asking for
comments/ideas on improving energy efficiency

Joe: Asking if TCP Keep-Alive is being used (check with Joe regarding his
comment)? Franchesco: The best ISP’s have an hour? for timeout (check if that’s
what he said) Matt Miller: TCP Keep-Alive is useless If you can rely on not
depending on the AS and the application to send the TCP Keep-Alive, it would be
better. Don’t rely on Keep-Alive. Costin: Different ports have different
timeouts and we shouldn’t use 443 for web push.

** Subscription-Less Web Push Framework (Fabio Chiussi) ****

Slide 1 - Purpose of draft is to spark discussion on the applicability of
different “flavors” of web-push. Slide 2 - Subscriptionless web push - Asking
question/challenging if we can come up with subscriptions web-push Slide 3 -
Current web-push hinges on the UA creating a subscription. For good reasons.
Slide 4 - Use case 1 & 2 -

UC1 - waking up dormant UE’s. Need to wake up a UE involving only the browser.
(See slides for details) UC2 - Local Alarms or urgent notifications. User may
be willig to give up some privacy to get notifications without subscription
UC3- User knows that upon entering a “venue” the user expects a relationship
with the provider and the subscription is implicit as the UE connects to the
network. UC4 - Cross-application volume control. (see slide)

Slide 5 - are any of the things mentioned reasonable

Comment from the floor - Agree with use cases but they all seem to be a
requirement for some form of “broadcast”.

** Next step ***********************************************

Chair: Would people be upset if we merge the encryption draft into the core
protocol draft?

Darshak: Commented that encryption must be mandatory but if we can make it in
an adjunct draft that gets delivered alongside (if possible)

Martin: Not specifically opposed to having it in a separate draft.

Matt Miller: Also ok with having it as a separate draft

Alyissa Cooper: Commented that from the process perspective - the core spec can
have a reference to the encryption spec. The IESG and others will want to have
all details regarding the encryption/security.