More word to nts.adoc

[Achim Gratz]

Hal Murray via devel writes:
>> Not only, any data in encrypted extension fields that goes back to the server
>> is encrypted with the c2s key (from the P portion of the paylod in section
>> 5.6 of the RFC).
>
> The cyphertext of figure 4 contains both the encrypted version of any headers 
> we want to encrypt and the authentication data.  Do we encrypt any headers 
> using this mechanism?  (I haven't noticed anything, but I could have missed 
> something.)

The only one specified in the RFC is cookie placeholders.

> We need to encrypt the new cookies returning from the NTP server.  Are they 
> using this mechanism, or are they encrypted out-of-band from this step?  We 
> can probably find an answer by reading the code.

>From my reading, yes.  So for symmetry using the same in the client
would make sense.

> The out of band approach allows a simple server implementation to construct 
> the response in place, on top of the request.  If we use the AEAD encryption, 
> we have to move things around.

But the response has to be fully encrypted so the new cookies can't be
stolen.  Anyway, the size of the message is the same before and after,
so you can still re-use the message buffer from the client packet.

> There are 2 layers of encryption for cookies.  The data in the raw cookie is 
> encrypted by the server.  When we say "cookie", we are referring to that 
> encrypted version rather than the raw version.

Yes.

> When the NTP server is returning new cookies to the client, they are encrypted 
> so that a spy can't track the client if it moves to a new IP Address before it 
> uses the cookie.

The point is rather that only the client with the correct key material
can decrypt and use those cookies.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada