gha...@gmail.com said:
> Hal, are we talking of the ntske port, 4460/tcp ?
Yes.
> As I understand it, NTS requires an out-of-band pre-arrangement. It makes no
> sense for me to probe random IP addresses for an NTS server to use, why would
> I trust this? So there would be an existing channel b
On Sun, May 31, 2020 at 5:51 AM Hal Murray via devel
wrote:
> I'm expecting there will be a new port number assigned for the KE server.
> Step 1 will be to listen on both old and new port #
> Step 2 is to switch the client side to default to the new port #.
> Step 3 is to stop listening on
On Sat, May 30, 2020 at 5:51 PM Hal Murray via devel wrote:
>
> > I'm thinking of tagging 1.2.0 for when NTS is officially official.
>
> Seems like a good plan.
>
> I'm expecting there will be a new port number assigned for the KE server.
> Step 1 will be to listen on both old and new port #
>
> I'm thinking of tagging 1.2.0 for when NTS is officially official.
Seems like a good plan.
I'm expecting there will be a new port number assigned for the KE server.
Step 1 will be to listen on both old and new port #
Step 2 is to switch the client side to default to the new port #.
Step 3
> In hindsight, we should have pushed a release when we made the incompatible
> change to the new string used to make the c2s and s2c keys. (The draft RFC
> changed a string constant There is no reasonable backward compatibility
> hack.)
You are correct. We should have then.
I'm thinking of
