[noise] Potential redesign?

[Trevor Perrin]

On Thu, Mar 19, 2015 at 12:31 AM, Trevor Perrin <trevp at trevp.net> wrote:
> On Tue, Mar 17, 2015 at 10:28 PM, Tony Arcieri <bascule at gmail.com> wrote:>
>>
>> Maybe a list of Noise use cases would be helpful? Some examples:
[...]
>
> I don't have a great list, but we can work through some protocols and
> see how they'd be rendered in Noise1 (previous) vs Noise2
> (descriptors).
>
[...]
>
> QUIC and maybe TLS 1.3 use pre-knowledge of an ephemeral key for
> 0-RTT, but then the server can present a fresher ephemeral:
>
> HandshakeNE(s, rs, re):
>  -> e, dhee, dhes
>  <- e, dhee
[...]
>
> TextSecure uses pre-knowledge of an ephemeral "prekey" for a 0-RTT key
> agreement with sender authentication, e.g.
>
> BoxXE(s, rs, re):
>   e, dhee, dhes, s, dhse

Looking back, I was oversimplifying QUIC and TextSecure by omitting
the fact that the remote static key also signs the prekey.  That
prevents the 3rd-party who provides the prekey from providing their
own prekey, which would remove the forward-secrecy property from the
initiator's message, since the 3rd-party would only have to compromise
the responder's static key to decrypt that message (Hugo Krawczyk
calls this "weak forward secrecy", see the HMQV paper).

This property is of debateable importance, but to achieve it
signatures are necessary.  I was hoping to keep Noise a DH-only
framework, but perhaps it should be able to express this too.

Something to think about.

Trevor