Re: New(ish) draft: Secure Messaging in XMPP

--===============7249039512050445156==
Content-Type: multipart/alternative; boundary=001a113d7514fc49a705271e1a27

--001a113d7514fc49a705271e1a27
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 23 October 2015 at 22:18, Adam Roach <[email protected]> wrote:

> XMPP folks:
>
> Martin and I put together a proposal for an approach that allows for
> end-to-end encrypted XMPP conversations, including in the presence of MUC=
.
> Although not a completely implementable spec, this should give a good ide=
a
> about the direction we have in mind:
>
> https://tools.ietf.org/html/draft-thomson-xmpp-secure-00
>
> Anyone interested in this work should give it a read and provide feedback=
.
> In particular, I'm curious if anyone interested in implementing this kind
> of thing has requirements can't be addressed with the high-level approach
> we're describing.
>

I'm nothing if not prompt in my reviews. :-)

Overall, I'm thinking this deserves more investigation, although =C2=A78 re=
ally
needs pulling out and turning into a (much longer) XEP. It may need killing
with fire; right now it's simply far too sparse to properly judge. But on
the assumption that this is orthogonal to the remainder of the spec, the
actual e2e protocol looks essentially OK to me.

A key factor will be supporting Pubsub (XEP-0060), and (probably)
advertising keys over PEP (XEP-0163) rather than presence - and since PEP
*is* PubSub, that leads into a fascinating discussion of recursion. We need
to look at Carbons (XEP-0280) and MAM (XEP-0313), and how these fit in, too=
.

I'm in two minds as to the right venue for discussion of the bulk of this,
however.

Part of me feels that the IETF has the better understanding of cryptography
and commsec, but with all the other proposals we've ever had, bar one,
being discussed in the XSF I'd be inclined to suggest you brought it there.
This also has the advantage that the majority of the client developers are,
more or less, based within the XSF rather than here, so I think that if
there's traction to be had, it'll be had within the XSF.

Finally, this gives you the golden opportunity to travel to Belgium at the
end of January and discuss this in person at the XSF's Summit - which I'd
love to see happen, and I promise to buy you both a beer or two if you do.

Dave.

--001a113d7514fc49a705271e1a27
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2=
3 October 2015 at 22:18, Adam Roach <span dir=3D"ltr">&lt;<a href=3D"mailto=
:[email protected]" target=3D"_blank">[email protected]</a>&gt;</span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">XMPP folks:<br>
<br>
Martin and I put together a proposal for an approach that allows for end-to=
-end encrypted XMPP conversations, including in the presence of MUC. Althou=
gh not a completely implementable spec, this should give a good idea about =
the direction we have in mind:<br>
<br>
<a href=3D"https://tools.ietf.org/html/draft-thomson-xmpp-secure-00" rel=3D=
"noreferrer" target=3D"_blank">https://tools.ietf.org/html/draft-thomson-xm=
pp-secure-00</a><br>
<br>
Anyone interested in this work should give it a read and provide feedback. =
In particular, I&#39;m curious if anyone interested in implementing this ki=
nd of thing has requirements can&#39;t be addressed with the high-level app=
roach we&#39;re describing.<br></blockquote><div><br></div><div>I&#39;m not=
hing if not prompt in my reviews. :-)</div><div><br></div><div>Overall, I&#=
39;m thinking this deserves more investigation, although =C2=A78 really nee=
ds pulling out and turning into a (much longer) XEP. It may need killing wi=
th fire; right now it&#39;s simply far too sparse to properly judge. But on=
 the assumption that this is orthogonal to the remainder of the spec, the a=
ctual e2e protocol looks essentially OK to me.<br></div><div><br></div><div=
>A key factor will be supporting Pubsub (XEP-0060), and (probably) advertis=
ing keys over PEP (XEP-0163) rather than presence - and since PEP *is* PubS=
ub, that leads into a fascinating discussion of recursion. We need to look =
at Carbons (XEP-0280) and MAM (XEP-0313), and how these fit in, too.</div><=
div><br></div><div>I&#39;m in two minds as to the right venue for discussio=
n of the bulk of this, however.</div><div><br></div><div>Part of me feels t=
hat the IETF has the better understanding of cryptography and commsec, but =
with all the other proposals we&#39;ve ever had, bar one, being discussed i=
n the XSF I&#39;d be inclined to suggest you brought it there. This also ha=
s the advantage that the majority of the client developers are, more or les=
s, based within the XSF rather than here, so I think that if there&#39;s tr=
action to be had, it&#39;ll be had within the XSF.</div><div><br></div><div=
>Finally, this gives you the golden opportunity to travel to Belgium at the=
 end of January and discuss this in person at the XSF&#39;s Summit - which =
I&#39;d love to see happen, and I promise to buy you both a beer or two if =
you do.</div><div><br></div><div>Dave.</div></div></div></div>

--001a113d7514fc49a705271e1a27--


--===============7249039512050445156==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
xmpp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/xmpp

--===============7249039512050445156==--