Subject: [Webpush] Minutes from the Thursday's meeting

From: Shida Schubert <[email-masked]>
Date: Sat, 25 Jul 2015 23:51:12 +0200

All;

Below is the minutes / action items from the Thursday meeting. 

I want to thank Darshak Thakore for taking notes. 

*******************************

Webpush IETF 93

Thursday July 23rd 2015 1740-1910
XMPP: [email-masked]

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