<div dir="ltr">I hope I'm not off-topic here, but I have a general question about signatures.<div><br></div><div>Noise's pure-DH approach to both authentication and key exchange was quite appealing to me, but most of the use cases I deal with in practice involving TLS tend to include a signature verification chain, and we now always leverage an intermediate cert as we try to keep the primaries completely offline and put the intermediaries in HSMs.</div><div><br></div><div>Should these use cases involve signatures, and if they do, should signatures be used in the traditional TLS-style role and D-H only be used for exchanging ephemeral keys? In for a penny, in for a pound as you will...</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 25, 2015 at 1:29 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, Mar 21, 2015 at 2:27 PM, Trevor Perrin <<a href="mailto:trevp@trevp.net">trevp@trevp.net</a>> wrote:<br>
>><br>
>> QUIC and maybe TLS 1.3 use pre-knowledge of an ephemeral key for<br>
>> 0-RTT, but then the server can present a fresher ephemeral:<br>
>><br>
>> HandshakeNE(s, rs, re):<br>
>>  -> e, dhee, dhes<br>
>>  <- e, dhee<br>
[...]<br>
><br>
> Looking back, I was oversimplifying QUIC and TextSecure by omitting<br>
> the fact that the remote static key also signs the prekey.<br>
[...]<br>
>  I was hoping to keep Noise a DH-only<br>
> framework, but perhaps it should be able to express this too.<br>
<br>
<br>
I could imagine a "sig" token for Noise, which means "sender signs<br>
hash of all previous messages in session".<br>
<br>
This allows a broader range of protocols.  For example, Google's QUIC<br>
[1] allows for a signed prekey and 0-RTT.  If the client doesn't have<br>
a signed prekey, it spends the first round-trip fetching one:<br>
 -><br>
 <- e, sig<br>
<br>
Then it executes the 0-RTT handshake, with the server providing a<br>
fresher ephemeral on response:<br>
 -> e, dhee<br>
 <- e, dhee<br>
<br>
<br>
So by using the sig early on your own message you can get "signed<br>
prekeys" without losing deniability, but by placing it later we can<br>
get more traditional key-agreement protocols in the style of TLS,<br>
SIGMA, etc., where the parties are signing values provided by each<br>
other, e.g.<br>
 -> e<br>
 <- e, sig<br>
 -> dhee<br>
<br>
<br>
This is another thing that could be misused (easy to throw away<br>
deniability, for example).  And it complicates the question of<br>
public-key formats.  But it's a nice gain in expressiveness for a<br>
small addition, and would let Noise cover most types of key agreement.<br>
<br>
Trevor<br>
<br>
[1] <a href="https://docs.google.com/a/trevp.net/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit" target="_blank">https://docs.google.com/a/trevp.net/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit</a><br>
_______________________________________________<br>
Noise mailing list<br>
<a href="mailto:Noise@moderncrypto.org">Noise@moderncrypto.org</a><br>
<a href="https://moderncrypto.org/mailman/listinfo/noise" target="_blank">https://moderncrypto.org/mailman/listinfo/noise</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Tony Arcieri<br></div>
</div>