<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 28, 2017 at 6:38 PM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">TLS renegotiation in HTTPS was sometimes used like this (initial<br>
server-authenticated handshake, then the server triggers a<br>
renegotiation for client-auth once it learns which resource the client<br>
is requesting).  Though I think that's discouraged / deprecated<br>
nowadays.<br></blockquote><div><br></div><div>Was there some security reason for why authenticating this way was discouraged?  Other than re-negotiation itself being a problem separately from the auth?<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

One question is whether the internal handshake actually replaces the<br>
session keys, or just runs the handshake phase (not transport).  The<br>
latter case seems maybe simpler and more efficient.</blockquote><div><br></div><div>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.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">  But I'm not sure<br>
existing Noise patterns work well for this:<br>
<br>
 * If you use the server's handshake ephemeral the server can't delete<br>
the private key, which it might prefer for forward-secrecy if it's<br>
doing rekey.<br></blockquote><div><br></div><div>It was actually the client's handshake ephemeral.  Which can be tossed as soon as the authentication step has completed.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
 * If you use the server's static then there's a KCI issue, i.e. the<br>
client-auth can be forged if the server's key is compromised.<br>
<br>
You might prefer something like:<br>
<br>
<- e<br>
-> se<br>
<br>
<br>
With the handshake hash from enclosing session in the prologue.  But<br>
that's an invalid pattern, so we'd need a special rule for that!<br></blockquote><div><br></div><div>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.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
There could be a Noise extension here, but it would be more worthwhile<br>
if we had a customer and use case in mind.</blockquote><div><br></div><div>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.<br><br></div><div>Cheers,<br><br></div><div>Rhys.<br></div></div></div></div>