[Webpush] Stephen Farrell's Discuss on draft-ietf-webpush-protocol-11: (with DISCUSS and COMMENT)

["Stephen Farrell" <[e-mail]>]

Stephen Farrell has entered the following ballot position for
draft-ietf-webpush-protocol-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


Apologies if some of this is a bit wrong, I had to review
this while not at a keyboard so I might make a booboo or
two mapping my mental notes to text:-) Apologies also if
some of the earlier discussion affects these, I didn't
get a chance to check the PRs created as a result of
other IESG comments. 

(1) This might just me being confused (in which case,
sorry) but I'm not quite clear on how with works with the
SOP.  Given you (reasonably) recommend a different port
(which is a different origin than 443) are you saying
here that the SOP doesn't apply to the client? (Well,
actually you don't say, so I'm not sure:-) If the SOP
applies, how is the port change handled? If the SOP does
not apply, then what does? (Given that I assume some UAs
at least will not change their handling of the SOP no
matter what we say here.)

(2) So-called "capability URLs" (is that a new term here?
seems like it could be the topic for a useful
informational rfc) are clearly weak, but also clearly as
good as we'll get for some things.  However, those also
become known over time, (in which case they are toast;-)
so why don't you need to provide a way for a push service
to say "hey, instead of <this-URL> in future you'll need
to use <that-URL>"? If that could be done as an extension
later, then I'd be ok with that in terms of clearing the
discuss, but then I think you'd need to mention it, so
that applications and UAs don't build in an assumption
that these URLs are fixed for all time (while also
needing to be kept "secret" as with other bearer tokens).

(3) Why is it not correct to encourage mutual-auth TLS
for the application to push-service connections?  I'm not
arguing to make that mandatory, but it's not that hard in
many cases and is very useful, esp since without some
client auth just knowing the URL will often enable a
sender to send a crap load of updates to possibly many
bandwidth/power-challenged UAs. (This is only a discuss
because of that potential DoS vector.)

(4) Is it really honest to say that the W3C Push API,
webpush encryption and vapid are only informative
references? The first seems easy to make normative, the
second I think really needs to exist before we ought
recommend this all get out into the wild and I'm not
clear if one could sensibly make a service for this
without the 3rd. Yes that might add some delay to the RFC
being issued, but that might be the right thing to do.
Why is it right to not wait on those two IDs and the w3c
rec? This is mainly a discuss in case the answer is "we
know nobody's gonna do webpush-encryption ever" in which
case I'd like to be convinced that implementing and
deploying based on this draft without reading those
references defines a good standard. I'm not saying that
it does not, I'm saying I'm not yet convinced.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------



- Thanks for the MUST use TLS. That's totally necessary
here. (Even if maybe not sufficient:-)

- I just want to check this is correct: I think it'd be
potentially useful to be able to pad the traffic here
with NOOP pushed messages. The argument is that the
existence of a message may sometimes be the same as
knowing the message content and the cost of turning on
the radio to even check is no different from checking and
getting a NOOP pushed message, so there's no major cost
to a reasonably sized NOOP message that's only there for
traffic padding.  (While padding at other layers can also
be done, I think we do not know enough today to say at
which layers traffic padding is most useful, and we
therefore ought define it where we can.) That said, I
think one could later define a new "OnlyKidding" Urgency
or Topic (see 9.1) that'd do the job. If that's right,
consider this me asking if anyone'd like to do that
later? If that's wrong, then consider this me asking:
"how can I effectively pad traffic at this layer?"

- section 6: (A nit) I think this could be clearer if you
better explained how the subscriptions and push messages
are correlated. While the current text is fine, since
it's clear eventually from the examples, it might be
better to not assume so much familiarity with h2.