[noise] Comparing SSH and Noise

[Rhys Weatherley]

On Wed, Jun 28, 2017 at 6:38 PM, Trevor Perrin <trevp at trevp.net> wrote:

> 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.
>

Was there some security reason for why authenticating this way was
discouraged?  Other than re-negotiation itself being a problem separately
from the auth?

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.


The latter was my intention - it doesn't contribute to the session keys.
It is solely a case of "if the nested handshake is valid, then the user has
been authenticated". Possibly the new handshake hash could replace the
original as the prologue for further nested Noise operations.


>   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.
>

It was actually the client's handshake ephemeral.  Which can be tossed as
soon as the authentication step has completed.

>
>  * 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!
>

I was hoping for something that could be done with a one-way pattern to
avoid an extra turn-around.  Noise_X on its own would work, with a fresh
ephemeral.  I was exploring ideas to reduce the computational overhead by
reusing previous ephemerals or not using them at all.  Noise_X would be
safer and easier to justify.


> There could be a Noise extension here, but it would be more worthwhile
> if we had a customer and use case in mind.


My use case is funnily enough - SSH.  Or something like it.  Doing any kind
of secure command-and-control on embedded devices is hard because of the
heavy overhead of both TLS and SSH.  There are two shell modes of interest:
devices "phoning home" to a server (device as client), and remote users
connecting to the device to perform administration (device as server).
Also, the SSH protocol is very crufty and showing its age - a refresh of
the transport using Noise might help with that.  But that's a longer term
experiment.

Cheers,

Rhys.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20170629/ff193183/attachment.html>