[noise] A simple and safe TLS/TCP-like protocol

[Trevor Perrin]

On Sun, Feb 5, 2017 at 1:43 PM, Rhys Weatherley
<rhys.weatherley at gmail.com> wrote:
> On Mon, Feb 6, 2017 at 7:34 AM, Alexey Ermishkin <scratch.net at gmail.com>
> wrote:
>>
>> By n1 (first point in my list) I thought we could use not only protocol
>> names but also add extra info like max packet size if needed. We have 255
>> bytes, we can even use json for that :)
>
>
> Negotiation of extra parameters can occur inside the handshake payloads;
> e.g. the responder offers a maximum packet size in the second XX handshake
> packet payload together with the responder's certificate.  The initiator can
> reduce the maximum in the third XX handshake packet when it sends its
> certificate.

I agree that handshake payloads should be preferred for negotiation
rather than appending fields onto the protocol name / version string.

The handshake payloads have more space (instead of 255 bytes), and
have more flexibility (they don't have to be strings, so the
application can use Protobufs, XML, ASN.1, whatever).

Also, assuming handshake payloads are ignored by default, then you can
add optional negotiation later without breaking compatibility, unlike
changing the version string.


However, if you *need* to break compatibility in the first message,
you might have to mess with the version string.

For example, you deploy an application using XML for handshake
payloads, but you want to migrate to JSON.  You might need to send an
initial message offering two different versions, e.g.
  Noise_XX_25519_AESGCM_SHA256
  Noise_XX_25519_AESGCM_SHA256_json

Old XML servers would respond to the first version, and new JSON
servers would respond to the second.

So that might be something to mention in a NoiseSocket spec, but for
most cases I think it's better to negotiate via handshake payloads.


Trevor