<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 29, 2016 at 1:55 AM, Rhys Weatherley <span dir="ltr"><<a href="mailto:rhys.weatherley@gmail.com" target="_blank">rhys.weatherley@gmail.com</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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_extra"><span class="">On Sun, Aug 28, 2016 at 5:27 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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span></span>We previously discussed whether to treat a DH+PQ scheme as:<div> (A) A hybrid DH function that redefines the "e" token to send a hybrid DH+PQ key, and redefines "dhee" to call MixKey() on the combined DH+PQ output. </div><div> (B) Separate functions triggered by their own tokens ("f" and "dhff", for example).</div></div></div></div></blockquote></span></div></div></div></blockquote><div>[...] </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_extra"><div>I did explore (A) and started to code it up in a trial branch.  The "Discussion" section of the proposed extension talks about why it didn't really work.</div></div></div></div></blockquote><div><br></div><div><div>Yeah, that made sense to me.</div></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_extra"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div>But if we're going this route, I wonder if we should go all the way to (B):</div></span></div></div></div></blockquote></div></div></div></blockquote><div>[...] </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_extra"><div>I'm not against this idea.  Using tokens gives more flexibility as to where the extra fs operations occur.  In New Hope, Alice is the one that can pre compute parameters.  Which means that it can make more sense if the responder sends the first f token instead of the initiator; e.g.<br></div><div><br><div>Noise_XXreversehfs</div><div>  -> e </div><div>  <- e, dhee, f, s, dhse</div><div>  -> f, dhff, s, dhse</div><div><br></div><div>That type of pattern isn't possible with a straight doubling of e and dhee.  But would be possible with a token-based approach.<br></div></div></div></div></div></blockquote><div><br></div><div><div><br></div><div>That's interesting, though of course that loses PQFS for the server's identity.  But allowing people to choose these trade-offs does seem like a good argument for the flexibility of tokens.</div><div><br></div><div>Another argument is that we'll probably have more ways of transforming patterns in the future, and we'd like these to be composable.  If transformations are expressed as operations on patterns, then it's easy to try composing them.  If they're expressed by redefining the text for existing tokens, it's harder to visualize the final outcome, and we have to worry about clashing text changes.</div><div><br></div><div>For example, here's some transformations applied to XX ("hfs", "sig", and "ss" are speculative, but they should be easy to figure out).</div><div><br></div><div>It's fairly easy to read the final protocol from the pattern, I think it would be harder if the transformations were rewriting the spec text without changing the pattern:</div><div><br></div><div><br></div><div>Noise_XX(s, rs):</div><div>  -> e</div><div>  <- e, dhee, s, dhse</div><div>  -> s, dhse</div><div><br></div><div>Noise_XXsig(s, rs):</div><div>  -> e</div><div>  <- e, dhee, s, sig</div><div>  -> s, sig</div><div><br></div><div>Noise_XXsig+hfs(s, rs):</div><div>  -> e, f</div><div>  <- e, f, dhee, dhff, s, sig</div><div>  -> s, sig</div><div><br></div><div>Noise_XXsig+hfs+noidh(s, rs):</div><div>  -> e, f</div><div>  <- e, f, s, dhee, dhff, sig</div><div>  -> s, sig</div><div><br></div><div>Noise_XXsig+hfs+noidh+ss(s, rs):</div><div>  -> e, f</div><div>  <- e, f, s, dhee, dhff, sig</div><div>  -> s, dhss, sig</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_extra"><div>However, I was trying to keep the system orthogonal in that adding a new feature to Noise applies equally to existing patterns.  New cipher and hash algorithms, features like PSK's and SSK's, etc, operate independently of the pattern.<br></div></div></div></div></blockquote><div><br></div><div><br></div><div><div>PSKs are orthogonal, and violate what I just said about transforms (since they change the processing rules, and don't modify the pattern).  If we were designing PSKs now, we might consider expressing "psk" as a transformation.  However that's not a backwards-compatible change (since "Noise_XXpsk" is a different name from "NoisePSK_XX"), and I don't think we should change core features like this without a much better reason.</div><div><br></div><div>SSKs were maybe added too quickly.  They were intended to be a cheap-and-easy way to add PQFS, but it seems like we're working out a better approach.  I don't think anyone's using them, and I don't like cluttering the spec with unused features.  </div><div><br></div><div>Perhaps we should remove SSK?</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_extra"><div>My goal was "existing behaviour plus this one new thing" - Noise_XX_25519+NewHope is still essentially XX in its structure.  Adding new explicitly named patterns like XXhfs kind of breaks this - now we have patterns that only work with specific combinations of non-pattern parameters.  Maybe it is unavoidable - NewHope already only works with interactive patterns and not one-way patterns.<br></div></div></div></div></blockquote><div><br></div><div>But it seems reasonable that some patterns might impose conditions on the non-pattern parameters - a "hybrid forward secrecy" pattern requires specifying an additional public-key algorithm for hybrid forward secrecy, that seems OK?</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_extra"><div>If we defined a "default hfs transformation", then existing patterns could be accommodated.  For instance, the presence of a forward secrecy algorithm name might implicitly apply the default transformation of "e -> e, f", "e, dhee -> e, dhee, f, dhff" if the pattern doesn't already involve f.  If that isn't what the user requires then they can define a new pattern.<br></div></div></div></div></blockquote><div><br></div><div><div>I think it's better to have transformations be an explicit part of the pattern name.  Also, listing multiple public-key algorithms might be used for other things besides an "hfs" transformation.</div><div><br></div><div>For example, in addition to a "sig" transformation that uses the same public-key type for DH and signatures, you could imagine a "sig2" that allows static public keys that are different from DH keys.  For example, "XXsig2_25519+RSA3072" might mean use 25519 for ephemeral DH, but use static RSA keys for signing.  "sig3" could allow different static public key types for initiator and responder.</div><div><br></div><div>So it seems better to explicitly indicate an "hfs" transformation, rather than infer it from the presence of multiple public-key algos.</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_extra"><div></div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Naming and separator chars</div></div></div></div></blockquote><div><br></div><div>I have no preference one way or the other on this.  All of the proposals so far are awkward in different ways.  Whatever consensus decides.<br></div></div></div></div></blockquote><div><br></div><div>I guess "+" still seems as good as anything, to me.</div><div><br></div><div>  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_extra"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>Encrypting the forward-secrecy values</div><div>[...snip...]<br></div><span class="">I'm not sure I've thought this through, but maybe this argues for encrypting the PQ public values?</span></div></div></div></blockquote><div><br></div><div>Sure.<br><br></div><div class="gmail_quote">Although, as I outlined in the thread "Oddity with IKnoidh, IXfallback, and PSK's", fallback patterns can get odd if values needed to perform the fallback are encrypted too early in the handshake.  But fallback scenarios already define specific pairs of patterns, so a PQ Noise Pipes need only choose a combination that works even if other combinations don't.</div></div></div></div></blockquote><div><br></div><div>Good point, I'll need to think about that more, particularly in combination with PSK.</div><div><br></div><div>If you were able to try a writeup of the transformation/token-based approach, that would be super-helpful in comparing approaches, and seeing whether this pans out.</div><div><br></div><div>Trevor</div><div><br></div><div><br></div></div></div></div>