[noise] Session identifiers

[Trevor Perrin]

On Mon, Apr 18, 2016 at 6:21 PM, Rhys Weatherley
<rhys.weatherley at gmail.com> wrote:
> SSH has a concept of a "session identifier" which is output from the
> transport handshake (RFC 4253) and then used in higher-level session
> authentication (RFC 4252) to strongly bind the authentication process to the
> session.
[...]
> The text mentions the "exchange hash H", which sounds similar to Noise's
> handshake hash "h" value.  The main difference is that SSH's hash value also
> includes the shared secret, whereas Noise's "h" is computed over publicly
> known values.  A secret session identifier would be preferable so that an
> eavesdropper cannot determine the value being signed by the login key.
>
> Is there some equivalent session identifier for Noise, and/or should we
> specify one?


Interesting topic...

I believe the SSH session identifier is used for what the Noise spec
calls "channel binding", and the Noise "h" value already works well
for this.

According to RFC 4251 on SSH architecture, the SSH "H" or "session
identifier" is a "unique session identifier ... that can be used by
higher level protocols to bind data to a given session and prevent
replay of data from prior sessions.  For example, the authentication
protocol uses this to prevent replay of signatures from previous
sessions".

So I believe the important property is uniqueness, not secrecy.  The
higher-level signatures that are calculated over the channel binding
are sent inside the SSH transport encryption, so secrecy is already
provided.  The goal is just to bind these signatures (or other auth
protocol messages) to a particular session, so they can't be re-used
outside of it.

You're right that SSH mixes the DH secret into the session identifier,
but that doesn't seem necessary to me (in RFC 4253 section 8 you can
see that H hashes in the DH public keys as well as the DH output; the
DH output is determined by the public keys, so hashing the output
doesn't add add any uniqueness).

It's also true that some approaches for TLS channel bindings use
functions of the shared secret.  For example, I think the latest idea
for TLS channel bindings is to the use "Extended Master Secret"
extension to trigger mixing the entire handshake hash into the session
keys, then use "TLS Extractors" to take some additional PRF output,
like you describe.

But again, I don't think this secrecy is necessary - for the uses /
requirements on TLS channel bindings in, say, RFC 5056, I believe you
could just as well use the handshake hash directly, like Noise does.
That's nice and simple, and doesn't add any new machinery, so I like
the current Noise design.

Trevor