8. Security Considerations

Das Protokoll MUST HTTP über TLS [RFC2818] gemäß [RFC7525] zwischen User Agent und Push-Dienst sowie zwischen Anwendungsserver und Push-Dienst verwenden. Alle URIs nutzen https für Vertraulichkeit und Integrität gegenüber Dritten.

8.1. Confidentiality from Push Service Access

TLS schützt den Inhalt nicht vor dem Push-Dienst. Ohne zusätzliche Maßnahmen kann dieser Inhalt lesen und ändern.

Anwendungen MUST Ende-zu-Ende-Vertraulichkeit, Integrität und Datenursprungsauthentisierung bereitstellen. Häufig sind Server- und Clientkomponenten dieselbe Anwendung; Abonnementverteilung unterstützt Schlüsselvereinbarung.

Die W3C Push API [API] nutzt [ENCRYPT] gegen den Dienst.

Topic ermöglicht feinere Korrelation und kann Traffic-Analyse unterstützen.

8.2. Privacy Considerations

Nachrichtenvertraulichkeit schützt nicht wer wann kommuniziert; die Menge exponierter Daten kann begrenzt werden.

Push-URIs MUST NOT Korrelation für einen User Agent ermöglichen; zwei Push-URIs MUST NOT allein aus dem Inhalt korrelierbar sein.

Push-Message-URIs MUST NOT Korrelation über Abonnements hinweg erlauben; innerhalb eines Abonnements MAY Korrelationshinweise enthalten sein.

Nutzer- und Geräteinformationen MUST NOT in Push- oder Message-URIs stehen.

Push-URIs desselben User Agents bzw. Message-URIs desselben Abonnements MUST NOT den User Agent korrelierbar machen.

Hinweis: Anonymitätsmenge ([RFC6973], 6.1.1) muss ausreichend groß sein.

Der User Agent MUST jederzeit neue Abonnements mit neuen Identifikatoren erstellen können.

8.3. Authorization

Das Protokoll regelt nicht, wie der Dienst Berechtigungen prüft. Der Dienst MAY jede HTTP-kompatible Autorisierung nutzen; Konfiguration erfolgt mit der Push-Service-URL im User Agent.

Capability URLs [CAP-URI] für Abonnement-, Push- und Quittungsressourcen: Wissen um die URL genügt.

Vorteile: einfaches Teilen und einfache Client-APIs ohne zusätzliche Vereinbarungen.

Bearer-Token-Semantik wie im englischen Original beschrieben; mindestens 120 Bit Zufallsentropie im Pfad erschweren Raten.

8.4. Denial-of-Service Considerations

Verteilung der Push-URI nur an autorisierte Server begrenzt die Quelle. Schwer erratbare URIs helfen.

Nicht authentisierte Nachrichten werden nicht zugestellt, können aber Batterien leeren.

Die Push API nutzt [VAPID], um Abonnements an Server zu binden; der Dienst kann Spam ohne User-Agent-Kontakt ablehnen.

Bösartige Nutzung gültiger URIs mit Dienstressourcen: der Dienst SHOULD Raten pro User Agent begrenzen.

Bei Überschreitung MAY 429 [RFC6585]; SHOULD Retry-After [RFC7231].

Abonnements mit zu vielen Nachrichten MAY beendet werden (7.3).

Der Dienst kann User Agents auch verweigern; absichtliches Versagen ist schwer von Ausfällen zu unterscheiden.

8.5. Logging Risks

Server-Logs können Abonnement-URIs oder Beziehungen offenlegen. Kürzere Aufbewahrung und Zugriffskontrollen mindern das Risiko.