[Last-Call] Re: Secdir last call review of draft-ietf-jmap-webpush-vapid-05

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Linda,

thank you for your feedback.

On Tue, Dec 10, 2024 at 1:36 AM Linda Dunbar via Datatracker
<noreply@xxxxxxxx> wrote:

> Major issues:
> The document does not introduce any new algorithms, protocols, or significant
> extensions to JMAP, WebPush, or VAPID. There is a section on Key Rotation
> Process which is specified in RFC8292. It seems that the document should be
> "Informational" instead of Standard track, correct?

I do not agree with this assessment. RFC8292 might allow for key
rotations the way we detect and resolve key rotations is unique to
this protocol extension.

> The security considerations of the document seem to primarily reiterate general
> concerns from related RFCs such as JMAP (RFC8620), WebPush (RFC8030), and VAPID
> (RFC8292). However, the document appears to lack a detailed exploration of
> security issues specific to the integration of VAPID with JMAP WebPush. Below
> are potential security risks that deserve some discussion:
>
> - The risk of race conditions if clients and servers are out of sync during the
> key rotation process.
>
> - The document does not address the potential risks associated with the
> exposure of the urn:ietf:params:jmap:webpush-vapid property in the JMAP
> capabilities object.

Here is my proposed update to the Security Considerations:

---
During the key rotation process, synchronization issues between the
client and server may arise. Specifically, a client might restrict a
push subscription with the push service to an outdated key, while the
server sends the PushVerification object signed with the newly rotated
key. This mismatch leads to the push service rejecting the
PushVerification request with HTTP status code 403, as specified in
{{!RFC8292}}, Section 4.2.

Per the requirements of {{!RFC8620}}, Section 7.2, the server MUST NOT
retry the rejected PushVerification request. Consequently, the
PushVerification object will not be delivered to the client.

To mitigate such issues, the client is responsible for detecting and
resolving any synchronization discrepancies, as outlined in the 'Key
Rotation' section of this document.

The inclusion of the `urn:ietf:params:jmap:webpush-vapid` property in
the JMAP capabilities object is limited to providing information about
the server’s support for Voluntary Application Server Identification
(VAPID). This property does not reveal sensitive information, nor does
it introduce new security or privacy risks beyond those inherent to
JMAP and WebPush. The security considerations for JMAP ({{!RFC8620}},
especially Section 8.6 and Section 8.7 of that document), WebPush
({{!RFC8030}}) and VAPID ({{!RFC8292}}) apply to this document.
---

Does this address your concerns?

cheers
Daniel

-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux