Re: [Ecrit] planned-changes: two questions

[Randall Gellens <[e-mail]>]

If a malicious client registers a URI that is designed to attack a third 
site, the test transaction causes the LoST server to connect to it and 
POST a command.  Without a test transaction, the LoST server stores the 
URI and at a future time connects to it and sends a command.  Either 
way, a LoST client can register potentially one URI per queried 
location, and a LoST server will connect to that URI and POST a message. 
  A queried location could be tied to many other locations, so there 
could be many locations for which a change would trigger the LoST server 
to use the URI, but is that worse?

--Randall

On 31 Aug 2021, at 10:27, Brian Rosen wrote:

> If the work group wants to have the LoST server keep the URI until 
> expressly deleted, that’s okay with me.
>
> Authenticating the client to the server doesn’t mean the URI is 
> authenticated.  We can’t restrict the URI to be the same entity as 
> the client running the LoST transaction.  And the clients are wide 
> ranging.  Could be an enterprise running its own LIS for example.  We 
> can’t assume the North American PKI is workable everywhere, and even 
> that doesn’t extend to an enterprise LIS.  ISTM we have to run a 
> test transaction with the notification service to make sure it’s 
> what we think it is.
>
> Brian
>
>
>
>> On Aug 31, 2021, at 9:01 AM, Caron, Guy <[e-mail]> wrote:
>>
>> Inline.
>>
>> Guy
>>
>> -----Message d'origine-----
>> De : Brian Rosen <[e-mail] <mailto:[e-mail]>>
>> Envoyé : 31 août 2021 08:11
>> À : Caron, Guy <[e-mail] <mailto:[e-mail]>>
>> Cc : Randall Gellens <[e-mail] 
>> <mailto:[e-mail]>>; ECRIT <[e-mail] 
>> <mailto:[e-mail]>>
>> Objet : [EXT]Re: [Ecrit] planned-changes: two questions
>>
>> You delete the URI when you delete the record in the LIS.
>> [GC] That's fine but that was not the question Randall posed. He 
>> asked whether the URI is deleted after a notification. I agree that 
>> if the Client does not host the location anymore that the URI 
>> associated with that location in the Server should be deleted. This 
>> could be achieved with an empty <plannedChange>.
>>
>> I don’t think this is covered in 5222.  The mechanism causes the 
>> LoST server to send notifications to the client, but the client is 
>> allowed to put any URI in the record, and it can add it to as many 
>> records as it wants.
>> [GC] I thought we agreed on using one generic URI per Client. Clients 
>> should be authenticated by the Servers.
>>  An evil implementation could record URIs against multiple targets 
>> that were unaware that the evil implementation did it, until they got 
>> a large number of PUSH transactions they didn’t expect or 
>> understand as a result of a large planned change.
>> [GC] Only authenticated Clients should be allowed to provide URIs to 
>> be stored by the Servers.
>>
>> The proposed mechanism qualifies the client URI before its used in a 
>> planned change.
>>
>> Brian
>>
>>> On Aug 31, 2021, at 7:37 AM, Caron, Guy <[e-mail]> wrote:
>>>
>>> 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
>>
>> ------------------------------------------------------------------------------
>> External Email: Please use caution when opening links and attachments 
>> / Courriel externe: Soyez prudent avec les liens et documents joints