[noise] Replacing TLS with noise

[Scratch]

Thanks, Trevor, I'm very glad to meet you. Kinda your fan )
Right now I'm looking at TLS and Wireguard specs and your suggestion
is what I think is the minimal required useful packet structure. Maybe
it's worth playing with frame type (handshake/data, etc), dynamic
frame size\etc, but it's not critical. Right now I want a plug-n-play
replacement for TLS in Golang and already working on a proof of
concept. I've already done some speed tests with tcp/udp/utp with and
without TLS/Noise and TCP+Noise is my choice so far. Let's see what
we'll come to.

Thanks for your support,
Alex.

2016-12-29 20:37 GMT+05:00 Trevor Perrin <trevp at trevp.net>:
> On Wed, Dec 28, 2016 at 11:08 PM, Scratch <scratch.net at gmail.com> wrote:
>>
>> I'm looking into implementing a secure transport layer for communication
>> between micro services. I don't want TLS because I don't need x.509 and all
>> that stuff. I know that there's a proposal for TLS 1.3 to have a"keys only"
>> mode, but it's still not accepted and i'm not sure it will get into
>> standard. Keys are perfectly enough for me. But I also don't want to invent
>> a bicycle here and use as much already invented things as possible.
>
>
> The spec mentions a "length field" and a "type field" which you could
> use for some minimal framing.  Basically, before each handshake
> message, you could include:
>  - 1-byte type (zero by default)
>  - 2-byte length
>
> The type byte can be changed for new versions of your protocol, or if
> your handshake has alternative messages (like Noise Pipes).
>
> After the handshake, you no longer need the type byte, so you can just
> include the 2-byte length before each transport message.
>
> You can make different decisions if your application has a different
> approach to framing.  For example, WhatsApp embeds Noise fields within
> XML, but it's not publicly documented.  WireGuard is adding extra
> padding for alignment reasons.
>
> You'll also need to make choices about handshake pattern, and crypto functions.
>
> Definitely feel free to discuss these on list, it's been awhile since
> we worked through a new application of Noise. It's always useful to
> get another perspective, see what the confusing points are, etc..
>
> Trevor