Re: [Ecrit] planned-changes: two questions

[Randall Gellens <[e-mail]>]

I'm concerned that the mechanism not get too complex.  I think we might 
consider having servers consolidate the records to associate with a URI 
to limit the number of notifications, which can mitigate the ability to 
leverage the notification mechanism as an attack against unsuspecting 
entities.  We might allow a server to consolidate identical URIs and 
send up to some number of IDs in one notification.  We can require 
clients to support at least this number of IDs in one notification.

If we do have a test function, it should be blocking: the LoST server 
tests it immediately, and if it fails for any reason, the server returns 
uriNotStored and the client can try again later.

--Randall

On 1 Sep 2021, at 16:16, Brian Rosen wrote:

> Inline
>
>> On Sep 1, 2021, at 3:28 PM, Caron, Guy <[e-mail]> wrote:
>>
>> Ok. You have convinced me of the necessity of validating the URI 
>> before the Server stores it and that the security considerations in 
>> RFC5222 do not cover this threat.
>>
>> I observe that this vulnerability was already mentioned in the 
>> Security section of the planned-changes draft:
>>
>> The server is subject to abuse by clients because it is being asked 
>> to store something and may need to send data to an uncontrolled URI.
>>
>> However, the original threat vector and associated response is 
>> probably insufficient to cover the DoS you raised, hence this new 
>> proposal to test the URI.
>>
>> So, I’m conceptually favorable to adding a mechanism to test the 
>> URI before being stored by the Server.
> Good
>
>>
>> I would like this mechanism to be as simple as possible and I think 
>> the goals can be achieved by testing the URI and receiving a response 
>> with at least one of the IDs previously supplied by the Server. I 
>> would leave it to policy at the Server to determine when and how 
>> often the URIs would be tested, with a recommendation (MUST? SHOULD?) 
>> to test it upon reception before storing it.
> I think you are suggesting we add text that says the LoST server can 
> send a notification to the LoST client that has no changes, and just 
> serves as a keep alive.  I’m sure we can make that work but 
> generally, I find this kind of implicit test to be less satisfactory 
> than an explicit keep alive transaction.   I get that an actual change 
> may not be seen as a change to the client, and thus it works with no 
> real code, but it doesn’t seem as clean as an explicit keep alive.  
> I’d be interested in herring from others on that
>>
>> We probably need to say something about what to do if the URI test 
>> fails. Do we inform the Client that provided the URI that it may have 
>> been compromised? Do we simply drop the URI silently? Do we block the 
>> Client that provided the URI entirely?
> At minimum wait and try again, the client could be down for a while.  
> I would not allow a lot of location records to be marked with the URI 
> that didn’t test valid.
>
> I am somewhat leery of creating circumstances where the client has to 
> go through and revalidate it’s entire record set because the 
> mechanism failed in some way.  There clearly would be circumstances 
> where that happened, but missing a keep alive shouldn’t be one of 
> them.  The initial one however should be a hard block.  If you can’t 
> get the first ID returned, then we have to not accept other 
> registrations.
>>
>> I’m not sure if the <command> thing is necessary since it requires 
>> the Server to keep state. I would think that if the URI has been 
>> tested and stored, it means it is active and valid until it is 
>> deleted through the reception of an empty <plannedChange> for 
>> example, or replaced through the reception of a new URI in 
>> <plannedChange>.
> I don’t think there is any server state other than the URI is valid. 
>  Each transaction stands alone.
>
> Without the delete, you can’t remove one location record from the 
> set that gets notified of planned changes.  You can change the URI, 
> but that changes it for all notifications.
>
>>
>> Lastly, I’m not sure we still need the warning ‘uriNotStored’ 
>> given that we’re going with one generic URI per Client. The only 
>> argument I can think of for keeping it would be the proliferation of 
>> Clients within the coverage aria of the Server that would be so large 
>> that the Server couldn’t store them all. A counter argument to that 
>> would be that doing so could be seen as giving privileges to certain 
>> Clients over others.
>
> We’re creating circumstances where the client won’t get a 
> notification.  I think we need to tell them that.
>
> One limit I might put on a client is how many locations they can ask 
> to be notified.  If they try to set up a situation where no matter 
> what changed, they get a notification, I think that may be too much to 
> ask, and the server can have a limit.  It would be okay if it’s one 
> URI per valid record at the LIS, but the LoST server doesn’t have 
> that data.
>>
>> Thanks,
>>
>> Guy
>>
>>
>> De : Brian Rosen <[e-mail]>
>> Envoyé : 31 août 2021 13:54
>> À : Randall Gellens <[e-mail]>
>> Cc : Caron, Guy <[e-mail]>; ECRIT <[e-mail]>
>> Objet : [EXT]Re: [Ecrit] planned-changes: two questions
>>
>> Of course an attacker would conceal itself and register multiple URIs 
>> under different identities.  But the bigger  problem is that if a 
>> large planned change occurred, the victim could receive a large 
>> number of notifications it didn’t expect.
>>
>> With a test transition, we know that the client expects to see 
>> notifications, we only need one per URI (we could specify one per 
>> domain — after the scheme and before the first slash).  If we 
>> don’t get the ID, we know not to allow that URI to be provisioned.  
>> So it’s one test transaction vs a large number of planned change 
>> transactions.
>>
>> Brian
>>
>>
>>
>> On Aug 31, 2021, at 1:35 PM, Randall Gellens 
>> <[e-mail] <mailto:[e-mail]>> wrote:
>>
>> 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] 
>> <mailto:[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] 
>> <mailto:[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] <mailto:[e-mail]>> 
>> De la part de Brian Rosen Envoyé :
>> 30 août 2021 11:22 À : Randall Gellens <[e-mail] 
>> <mailto:[e-mail]>> Cc
>> : ECRIT <[e-mail] <mailto:[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] <mailto:[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] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/ecrit 
>> <https://www.ietf.org/mailman/listinfo/ecrit>
>>
>> _______________________________________________
>> Ecrit mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/ecrit 
>> <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
>>
>>
>> External Email: Please use caution when opening links and attachments 
>> / Courriel externe: Soyez prudent avec les liens et documents joints