[Ecrit] Fwd: PLEASE READ: We need people to comment on planned-changes

[James Kinney <[e-mail]>]

Forgive me if this is a duplicate, but I think I only responded to Randall
the first time. See forwarded email below.

Randall, I think I am caught up a little and I also asked for some feedback
from our LDB Location Subsystem team. My two cents are below, possibly more
to come from others...

I see the URI that is exposed by the LIS client as a callback or webhook. I
could be off on that, but it seems like the LIS is exposing a callback for
the ECRF/LVF to contact. I think it could be seen as a dynamic webhook.


   - In my opinion, you want the ECRF to test whether the URI is reachable
   before responding to the findService; so my recommendation so far is
   "round-trip before the response." That seems more explicit of a test,
   versus the client expecting a callback, timing-out, and indicating a
   failure from the lack of a signal.
   - However, even if you test before the response, I think the keep-alive
   could still be a good idea. This could allow a LIS to cancel a pending
   request, or it could exchange the URI for example. I am not sure any of
   those are necessary, but basically, you are communicating some form of
   mutual status of a planned change request if the ECRF is testing the
   webhook periodically.
   - The only opinion I have on *silent-discard* is that I would lean
   towards the solution that creates the least of a possible vector for
   exploit, e.g. reflection type attacks. On the surface for me that is
   silent-discard.
   - Yes on periodic, I think the minimal amount of traffic it adds is well
   worth the mutual status shared by exercising the URI and poking the
   association. A LIS could still use the lack of keep-alive(s) to alarm
   itself.
   - On the last two *ID* points I need to go back and do some more
   catch-up, I am not quite getting the question totally.



Best regards,
*James Kinney*

*Chief Innovation Officer | INdigital *



*direct: 260.469.2132*

*email: *[e-mail] <[e-mail]>

*main office: *877.469.2010

*website: *indigital.net

*address: *1616 Directors Row, Fort Wayne, IN 46808

*join us online:* Facebook <https://www.facebook.com/INdigital911/> |
Twitter <http://twitter.com/indigital> | Linkedin
<https://www.linkedin.com/company/indigital911>





CONFIDENTIALITY: The information contained in this transmission is
privileged and confidential. It is intended to be received by the
individual or entity named above. If the reader or this message is not the
intended recipient, the reader is hereby notified that any consideration,
dissemination, or duplication of this communication is strictly prohibited.
This email and any attachments are confidential and may also be privileged.
If received in error, please do not disclose the contents to anyone, notify
the sender by return email, and delete this email and any attachments from
your system.


On Wed, Sep 8, 2021 at 3:15 PM Randall Gellens <[e-mail]>
wrote:

> Hi ECRIT Members,
>
> There are a few technical choices to be made in the planned-changes draft.
> Up to now it's been just Brian, Guy, and myself discussing the issues. We
> need other group members to speak up, please. If the issues aren't clear,
> please say what is confusing.
>
> --Randall
>
> Forwarded message:
>
> From: Brian Rosen <[e-mail]>
> To: Randall Gellens <[e-mail]>
> Cc: Caron, Guy <[e-mail]>, ECRIT <[e-mail]>
> Subject: Re: [Ecrit] planned-changes: two questions
> Date: Fri, 3 Sep 2021 12:37:28 -0400
> It would be great to hear from others on what they think of these ideas.
> If we haven’t explained what we’re talking about sufficiently, what is
> unclear?
>
> Do you like Randall’s “do the roundtrip notify before completing the
> findService response, which could then have an error response?  (Once per
> URI) or my “notify immediately after a new URI is presented, and
> periodically after that (keep alive) with no explicit error on the
> findService, noting that the client knows the notification is coming and if
> it doesn’t appear there was an error.
> Do you think we should have an explicit URI-not-stored error or silently
> discard?
> Do you think periodic keep alives (per URI) should be supported?
> Do you think we need an explicit delete of an ID from triggering notify at
> a given URI?
> If your answer to the above is “yes” would you prefer an explicit delete
> “command” or use something in the LI that somehow indicated delete?
>
> Any other concerns?
>
> On Sep 2, 2021, at 6:04 PM, Randall Gellens <[e-mail]>
> wrote:
>
> We need to do it once per new URI. If the URI already is stored, there's
> no reason to validate it again.
>
> The overhead of a new TCP/TLS connection and one round-trip isn't much,
> and is only once per new URI.
>
> Also, for URI deletion, we should have an explicit way to do this, perhaps
> a "delete" parameter along with the URI to be deleted.
>
> --Randall
>
> On 2 Sep 2021, at 14:51, Brian Rosen wrote:
>
> You are proposing that you set up a TLS connection, POST on that
> connection, the server sets up a reverse connection, POSTs on that, the
> client responds to that POST, and then the server responds to that post?
> Not a great plan I think.  If second TLS connection already exists, so you
> are asking to do a complete transaction B->A before the response to A->B I
> might be less worried.  Doesn’t sound like a great plan
>
>
> Also, we need only do this once per client.  Not once per validation.
>
> Brian
>
> On Sep 2, 2021, at 5:45 PM, Randall Gellens <[e-mail]>
> wrote:
>
> I think a simpler approach is that when a query includes a URI, before
> returning the response, the server POSTS to the URI. If it receives a
> success response, it stores the URI and returns the response. If it
> receives a non-success response, it informs the client that the URI was not
> stored. We can use uriNotStored or have a new warning such as
> uriTestFailure. This way, the server does not need to maintain a pending
> URI and retry the test, and the client knows immediately if there's a
> problem. Presumably, if the URI is bogus, the URI host will not return a
> success result. I think that should be good enough, but if we want stronger
> protection, we could tie in the TLS authentication when the server does the
> POST.
>
> --Randall
>
> On 2 Sep 2021, at 14:29, Brian Rosen wrote:
>
>
>
> On Sep 2, 2021, at 3:48 PM, Caron, Guy <[e-mail]> wrote:
>
> Inline under [GC].
>
> If you agree with my comments inline below, here is how I see the process
> (building on what Randall initially provided on this thread):
>
> 1) In a validation query, a Client can request to be notified when the
> proffered LI should be revalidated, and provides a URI to send the
> notifications to;
> 2) In the validation response, the Server provides an ID that the Client
> associates with the LI it just validated;
> 3) Immediately thereafter, the Server sends a ‘test’ notification to the
> URI, without any ID;\
>
> [br[For every new ID?  Or just once?  I wanted this to be a one time
> registration.
>
> 4) The recipient at the URI is expected to respond with the ID provided in
> step 2. If it does, the Server stores the URI for future notifications. If
> it does not, the Server [let’s pick one: reject silently the URI and block
> the Client permanently/provides a ‘uriNotStored’ warning response to the
> URI {not compatible with the current proposal to test outside of
> LoST}/reject silently the URI and block the Client temporarily/other?];
>
> [br]I don’t think an explicit failure is a problem.  The LoST server can
> limit retries if it needs to.
>
>
> 5) Some time after, the Server notifies the Client of an upcoming planned
> change by sending a notification to the successfully tested URI with the
> location ID;
> 6) The client revalidates each LI in its database that matches the ID as
> of the date of the planned change. If no ID matches, it is a no-op at the
> Client. Revalidations may also result in no-op at the Client.
> 7) LIs at the Client that are invalidated by the planned change are
> modified in its database to be valid (which probably mean another
> revalidation cycle) with an effective date set to <revalidateAsoF> value.
>
> [br]I wanted periodic keep alives.  How would that work?
>
>
> Guy
>
> *De :* Brian Rosen <[e-mail]>
> *Envoyé :* 1 septembre 2021 19:17
> *À :* Caron, Guy <[e-mail]>
> *Cc :* Randall Gellens <[e-mail]>; ECRIT <[e-mail]>
> *Objet :* [EXT]Re: [Ecrit] planned-changes: two questions
>
> 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
> *[GC] Could we not, for example, declare a value/element/attribute 'test'
> to be passed in the notification with no IDs? Would that meet your idea of
> an explicit test mechanism?*
>
> [br] I suppose.  Doesn’t seem much different than a parameter to the
> findService, but I’m okay with it
>
>
>
>
> 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.
> *[GC] On a second thought, what's the value of testing the URI after the
> first test? If it passed, it's valid and the Server stores it for use when
> a planned change occurs. If after that and for some reason, the Client is
> not responsive to the notification, does the Server care?*
>
> Generally when we have things that don’t do anything for months and then
> we need it, I would like to see periodic keep alives.  Things change on
> both sides and both sides have a vested interest in making sure the
> mechanism works when they need it.
>
>
>
>
> 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.
> *[GC] Why? A Client that no longer wants to be notified for a given ID
> sends an empty <plannedChange> for the LI it no longer has. If that ID at
> the Server is associated with only one location (say one specific civic
> number), it deletes the Client's URI. If it is associated with more than
> one record (say a range of civic numbers), it accepts the transaction but
> keeps the URI. A notification for that ID sent to the Client that only had
> the civic number would result in a no-op.*
>
> That means that the client has to be identified by something like the TLS
> cert, because the URI isn’t there for the delete.  I was using the domain
> of the URI as the ID of the client.
>
> But we have another problem: I think the server does not track the LI.  On
> any findService with the new option, it looks for a matching record and
> returns the ID it has for that record.  It’s the client that tracks
> possible multiple LIs for one ID, not the server.  So in your example, the
> client would notice that any address in the range had the same ID.  It
> would get one notification if the range record changed, and it would update
> all its records in the range.  But if it deleted one of a set of records
> that have the same ID, it wouldn’t request delete.  Only if it got down to
> one record with a given ID, and it needed to delete that record, would it
> request delete for that ID at the server.
>
>
>
>
> 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.
> *[GC] Only if the URI fails the validity test.  *
>
> [br]I wanted to allow the server to limit the number of IDs it was
> tracking for a given client.  I wanted to limit the number of queries the
> server is responding to (although it might well silently discard a DOS
> attack.
>
>
>
> 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.
> *[GC] It's one generic URI per Client with one or more IDs stored by the
> Client against its LIs, right? As you suggesting we go back to one URI per
> Client record in its database?*
>
> [br]  One generic URI per client.  So if the client asks for its URI to be
> stored against too many IDs, it can be told no.
>
>
>
>
> 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]>
> 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]> wrote:
>
> Inline.
>
> Guy
>
> -----Message d'origine-----
> De : Brian Rosen <[e-mail]>
> Envoyé : 31 août 2021 08:11
> À : Caron, Guy <[e-mail]>
> Cc : Randall Gellens <[e-mail]>; ECRIT <[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
>
>
>
>
> ------------------------------
> *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*
>
>
>
>
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit
>