Re: [Ecrit] planned-changes: two questions

["Caron, Guy" <[e-mail]>]

Well, this is not going in the direction I thought.

What is the purpose of deleting the URIs at the Server post-validation?

Regarding opening a new DoS, I guess I'm not following. Wouldn't this case be covered by the security considerations in RFC 5222?

What you're proposing puts back significant load on the Servers (a key consideration for creating planned-changes in the first place) and complicates the mechanism.

Guy


-----Message d'origine-----
De : Ecrit <[e-mail]> De la part de Brian Rosen
Envoyé : 30 août 2021 11:22
À : Randall Gellens <[e-mail]>
Cc : ECRIT <[e-mail]>
Objet : [EXT]Re: [Ecrit] planned-changes: two questions

Answer 1: yes.  Since there is going to be a revalidation, just deleting the setting seems right to me.
Answer 2: Up to server.  If I were implementing, I would hash the real ID with the URI and some kind of predictable nonce.  

We probably have to say more about how the server identifies the client, so that replacement of the URI works.  Could we say we use the domain of the URI (the entire domain with all the dots) to identify the client, and anything can occur after it (meaning a slash and whatever)?  If we do that, then how would delete the notification?  Force there to be something other than the domain (ugly).  Explicit delete request?

Hmmm, we’ve opened a DoS attack: a rogue client stores a bunch of URIs for servers it wants to victimize.  In North America we have a real simple solution for that, because we have a PKI, so we know, for sure, who the client is, and could restrict who we allow to store URIs, but that wouldn’t be true in general.  Also, it would be nice for the client to have confidence the mechanism worked before it needed it.

So
Let’s add a “command” to plannedChange in the findService request.  And, have the client have a response to the notification which is the ID (json with the 200)


The client starts by sending a command of “initialize”.  The domain is the identity of the client.  The response is an immediate notification to the with whatever LI was in the request and an ID.  The  response by the client (which is the notification web server) is a piece of json containing the ID.  We can say that the LI in this initialize command could be something simple like the Country Code that wouldn’t get a planned change.

Thereafter, the LoST server (notification client) periodically repeats this keepalive notification every day or week with the initialize LI.  The client has to respond with the ID.

The regular notification request is a command of “notify”.  The server ignores a request for notification from an uninitialized client.
The notification can be deleted with a command of “delete”.  If you delete the initialize LI, then the server won’t send any more notifications to that client and deletes all URIs it was saving for that client.  The client would have to re-initialize to reset.

Brian

> On Aug 27, 2021, at 5:41 PM, Randall Gellens <[e-mail]> wrote:
> 
> I think we're moving to a model where:
> - In a query, a client can request to be notified when the location should be revalidated;
> - In the response, the server provides an ID which the client associates with the location it just validated;
> - The server sends a notification to the URI, containing the ID;
> - The client revalidates each location with which that ID is associated.
> 
> Question 1: Does the server delete/inactivate the URI once it has sent the notification?
> 
> Question 2: Presumably, when the client revalidates the location(s), it will again request notification.  Does the server return the same ID as before, or a different ID?  A different ID could perhaps be useful in edge cases where the server didn't send or the client didn't get the notification, but any utility seems small.  If it's the same ID, then the answer to question 1 can be that the URI remains active until the client asks to no longer be notified (by sending an empty URI?).
> 
> --Randall
> 
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ecrit
------------------------------------------------------------------------------
External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints