[noise] Comparing SSH and Noise

[Trevor Perrin]

On Wed, Jun 28, 2017 at 6:44 AM, Rhys Weatherley
<rhys.weatherley at gmail.com> wrote:
> I've been re-reading RFC 4253, which describes the SSH transport layer
> protocol (hereafter called "TLP").
>
> The purpose of TLP is to establish an encrypted/authenticated session,
> transfer the host's public key to the client, prove that that host is in
> possession of the corresponding private key, and to output a hash which the
> RFC calls a "session identifier".
>
> That's it.  TLP does not perform user authentication.  That's done by inner
> protocols using the session identifier for channel binding.

Yeah, that's often true in other protocols too (e.g. TLS, IPsec).


> The discussion of NoiseSocket/Link/Transport until now has focused on
> Noise_XX but I'm wondering whether that's the correct pattern.

One point for XX in the simple protocol is that you can use "dummy
keys" in XX to emulate NX, XN, or NN.


>  User
> authentication is a different and difficult problem: passwords, DH
> authentication, Ed25519 signatures, two factor codes sent via SMS, and on
> and on.  Authentication requirements are very application-centric, whereas
> basic TLP can be application-agnostic.
>
> I wonder whether we could use Noise to do something like SSH authentication.
> Perform an NX handshake to secure the transport and then authenticate with a
> nested Noise handshake inside the data transport phase of the session.

Sure, that seems possible.  As you mention there's a lot of
pre-existing client-auth methods, and some newer work (U2F, token
binding) uses signatures, so there's a big question of who would use a
new DH-based client-auth method.

TLS renegotiation in HTTPS was sometimes used like this (initial
server-authenticated handshake, then the server triggers a
renegotiation for client-auth once it learns which resource the client
is requesting).  Though I think that's discouraged / deprecated
nowadays.

One question is whether the internal handshake actually replaces the
session keys, or just runs the handshake phase (not transport).  The
latter case seems maybe simpler and more efficient.  But I'm not sure
existing Noise patterns work well for this:

 * If you use the server's handshake ephemeral the server can't delete
the private key, which it might prefer for forward-secrecy if it's
doing rekey.

 * If you use the server's static then there's a KCI issue, i.e. the
client-auth can be forged if the server's key is compromised.

You might prefer something like:

<- e
-> se


With the handshake hash from enclosing session in the prologue.  But
that's an invalid pattern, so we'd need a special rule for that!
There could be a Noise extension here, but it would be more worthwhile
if we had a customer and use case in mind.

Trevor