[noise] New draft: "noh2" branch

[Trevor Perrin]

On Thu, Aug 27, 2015 at 10:22 AM, Tiffany Bennett <tiffany at stormbit.net> wrote:
> 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.

I'm trying to simplify - would a section on "framing layer" make the
spec simpler?

I think it wouldn't (though I'd look at a pull request or draft text,
if you think otherwise).


>> 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),

Still a flaw in some TLS clients, see "cookie cutter":

https://secure-resumption.com/tlsauth.pdf


> I mean having
> an application-layer message. You can't forge application-layer
> packets, so why can't the application handle termination messages?

It could.  Leaving this to the application is an option.

But I worry about applications neglecting this.  For example, if
people use Noise_N to encrypt a file, will they always remember to add
a length field or terminator inside the encryption?

If there's an explicit "final" argument in the API, I think people are
more likely to use this safely.  And putting a type byte in there also
gives an extension point that could come in handy, in future.

Adam Langley has argued for crypto layers that allow streaming
decryption and detect truncation, so that was an influence:

https://www.imperialviolet.org/2015/05/16/aeads.html
https://www.imperialviolet.org/2014/06/27/streamingencryption.html


Trevor