8. Security Considerations

Le protocole MUST utiliser HTTP sur TLS [RFC2818] selon [RFC7525], entre user agent et service push et entre serveur d'application et service push. Tous les URI utilisent https, ce qui protège confidentialité et intégrité vis-à-vis des tiers.

8.1. Confidentiality from Push Service Access

TLS n'empêche pas le service push d'inspecter ou modifier le contenu sans mesures supplémentaires.

Les applications MUST utiliser mécanismes offrant confidentialité, intégrité et authentification de l'origine de bout en bout. Souvent le même logiciel côté serveur et user agent ; la distribution de l'abonnement sert aussi à l'établissement de clés.

La Push API du W3C [API] utilise [ENCRYPT] pour protéger le contenu vis-à-vis du service.

Le champ Topic expose des informations permettant une corrélation plus fine ; cela peut aider l'analyse de trafic par le service.

8.2. Privacy Considerations

La confidentialité du message ne protège pas qui communique ni quand. L'exposition peut toutefois être limitée.

Les URI push MUST NOT permettre de corréler les communications d'un user agent donné. Deux URI push MUST NOT être corrélables uniquement par leur contenu.

Les URI de message MUST NOT permettre de corréler entre abonnements. Pour un même abonnement, MAY contenir des indices de corrélation avec l'abonnement ou d'autres messages du même abonnement.

Les informations utilisateur et appareil MUST NOT apparaître dans les URI push ou message.

Les URI établis par le même user agent ou pour le même abonnement MUST NOT permettre de corréler avec le user agent.

Note : l'ensemble d'anonymat ([RFC6973], 6.1.1) doit être suffisamment grand. Un URI push identifie au moins le service ou une instance.

Le user agent MUST pouvoir créer de nouveaux abonnements avec de nouveaux identifiants à tout moment.

8.3. Authorization

Le protocole ne définit pas comment le service autorise la création d'abonnements ou la livraison. Le service MAY utiliser toute méthode d'autorisation compatible HTTP. Le processus et les identifiants sont configurés avec l'URL du service dans le user agent.

L'autorisation repose sur des capability URLs [CAP-URI] pour abonnement, push et accusés. La connaissance de l'URL suffit.

Elles facilitent le partage et les API client sans relations préalables supplémentaires.

Ce sont des jetons bearer : connaître l'URI d'abonnement autorise réception ou suppression ; l'URI push autorise l'envoi ; l'URI message la lecture et l'accusé ; l'URI d'abonnement aux accusés la réception des accusés.

Au moins 120 bits d'entropie aléatoire dans le chemin rend la devinette difficile.

8.4. Denial-of-Service Considerations

Limiter la diffusion des URI push aux serveurs autorisés contrôle l'origine. Des URI difficiles à deviner limitent l'abus.

Les messages non authentifiés ne sont pas livrés mais peuvent épuiser la batterie même en petit volume.

La Push API adopte [VAPID] pour lier l'abonnement à un serveur d'application ; le service peut alors rejeter le spam sans réveiller le user agent.

Un acteur malveillant avec une URI push valide peut abuser des ressources du service. Le service SHOULD limiter le débit par user agent.

Le service MAY renvoyer 429 [RFC6585] et SHOULD inclure Retry-After [RFC7231].

Le service ou le user agent MAY résilier les abonnements trop sollicités (7.3).

Le service peut aussi refuser de servir des user agents ; la panne délibérée est difficile à distinguer d'une erreur réseau ou d'une panne.

8.5. Logging Risks

Les journaux peuvent révéler des URI d'abonnement ou leurs relations. Limites de rétention et contrôles d'accès réduisent l'exposition.