[noise] Signatures, and QUIC example

[Tony Arcieri]

I hope I'm not off-topic here, but I have a general question about
signatures.

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.

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

On Wed, Mar 25, 2015 at 1:29 AM, Trevor Perrin <trevp at trevp.net> wrote:

> On Sat, Mar 21, 2015 at 2:27 PM, Trevor Perrin <trevp at trevp.net> wrote:
> >>
> >> 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
> [...]
> >
> > Looking back, I was oversimplifying QUIC and TextSecure by omitting
> > the fact that the remote static key also signs the prekey.
> [...]
> >  I was hoping to keep Noise a DH-only
> > framework, but perhaps it should be able to express this too.
>
>
> I could imagine a "sig" token for Noise, which means "sender signs
> hash of all previous messages in session".
>
> This allows a broader range of protocols.  For example, Google's QUIC
> [1] allows for a signed prekey and 0-RTT.  If the client doesn't have
> a signed prekey, it spends the first round-trip fetching one:
>  ->
>  <- e, sig
>
> Then it executes the 0-RTT handshake, with the server providing a
> fresher ephemeral on response:
>  -> e, dhee
>  <- e, dhee
>
>
> So by using the sig early on your own message you can get "signed
> prekeys" without losing deniability, but by placing it later we can
> get more traditional key-agreement protocols in the style of TLS,
> SIGMA, etc., where the parties are signing values provided by each
> other, e.g.
>  -> e
>  <- e, sig
>  -> dhee
>
>
> This is another thing that could be misused (easy to throw away
> deniability, for example).  And it complicates the question of
> public-key formats.  But it's a nice gain in expressiveness for a
> small addition, and would let Noise cover most types of key agreement.
>
> Trevor
>
> [1]
> https://docs.google.com/a/trevp.net/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise
>



-- 
Tony Arcieri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20150325/dbd9ecbe/attachment.html>