<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Oct 2, 2016 at 2:23 AM, Hanno Böck <span dir="ltr"><<a href="mailto:hanno@hboeck.de" target="_blank">hanno@hboeck.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* I assume your intention is to standardize an encryption layer only<br>
  and not a new messaging protocol, right?</blockquote><div><br></div><div>Yes</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">With the implicit assumption that this protocol is<br>
  supposed to be used within separate protocols that don't<br>
  interoperate. I wonder if a design with lack of interoperability in<br>
  mindmatches IETFs goals.<br></blockquote><div><br></div><div>Well, I think ideally there could be interoperable, IETF-standardized protocols built on it. The Matrix.org work comes to mind. But... baby steps. The interoperable primitives need to be put in place first.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* If you intend to design a crypto only layer I think this needs very<br>
  careful considerations how this is connected to the rest of a<br>
  potential protocol using it. How does it interact with application<br>
  features, e.g. voice com, file transfer, message markup, reading<br>
  confirmations etc.?<br></blockquote><div><br></div><div>What form would this actually take in something like an RFC? A non-normative section on deployment advice?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Is metadata hiding a design goal?<br></blockquote><div><br></div><div>IMO, no. As desirable as that is and as much as I want to see it widely deployed, it's still too much of a nascent research area, whereas I think we're to the "rough consensus and running" code stage of something like the Signal Protocol, and it's seen the same sort of organic proliferation of the design we saw with djb's ciphers prior to standardization work by the CFRG and TLS WG.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* How does this relate to other standardization efforts? (You already<br>
  mentioned olm, there's also OMEMO which is currently gaining some<br>
  traction.)<br></blockquote><div><br></div><div>Ideally the output of such an WG should be an RFC that protocols like OMEMO can reference in their own RFCs, if they ever intend to pursue IETF standardization.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* I haven't followed closely the whole wire/signal/gplv3-debate.<br>
  However there seem to be at least some claims that every<br>
  implementation of the current signal protocol is seen as some kind of<br>
  gplv3 derivative and thus also covered by gplv3.<br></blockquote><div><br></div><div>As an IETF protocol it would have to be free of IP Rights concerns. Unless IPR can be clarified, the design would need to be changed to one which is free of concerns.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* This is a bit of a fuzzy point and relates to the first one, but I'd<br>
  fear that this could turn into some kind of "let's do it like signal,<br>
  because signal is already there". <br></blockquote><div><br></div><div>I don't think the goal of the WG should be to rubber stamp the Signal protocol, however I do think it's a compelling candidate if IPR concerns can be clarified.</div></div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Tony Arcieri<br></div>
</div></div>