[noise] New draft: "noh2" branch

[Tiffany Bennett]

On Thu, Aug 27, 2015 at 12:58 PM, Trevor Perrin <trevp at trevp.net> wrote:
> I'd argue the length fields are harmless.  If your specific case
> doesn't need them just omit them and say they're implied.
>
> But specifying them is simple and encourages interop, e.g. if you use
> Noise over TCP it's obvious what to do.

The point I was trying to get at here is that session has no need to
be aware of any length fields, since the buffer length is already
known before the use of the session API. It has no need to use it. It
should still be a standard part of the protocol, but I don't feel like
it should be integrated into the session layer, which is why I
suggested a separate framing layer. I feel similarly about the branch
field.

> It's actually moved into the first byte of transport message payloads.
>
> You could ignore it if you want, but by default it's safest for the
> crypto layer to resist truncation attacks (of sessions, or one-way
> messages).  It at least forces you to think about that.

I don't see what this has to do with truncation attacks. I don't mean
calling close() on the TCP socket as the main way of terminating the
connection (as was the case in SSLv2, and a major flaw), I mean having
an application-layer message. You can't forge application-layer
packets, so why can't the application handle termination messages?
There isn't even any lower-level "terminate connection" in the case of
UDP, so noise is introducing it out of nowhere. I am against
out-of-band connection termination, if that makes it clearer. I
suppose this might be the wrong place to be fighting that battle, as
users who aren't instructed to use a noise-specific OoB termination
operation may just default to the TCP-specific OoB termination
operation instead of doing it in-band, and there are plenty of
existing protocols which rely on OoB termination.

> Maybe, but error messages often get used against you (to enable oracle
> attacks, or timing attacks), and complicate things, so I would leave
> those for the application to add if it insists.

It would have to be before any sort of encryption to work, because of
the possibility of the encryption failing. But I suppose it's not that
large of a concern, since it's a bug in the application anyway to have
such an issue.