[OTR-dev] Fwd: Re: [xmpp] Proposed XMPP Charter Update

Mon Feb 25 11:58:26 EST 2013

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey folks, there is still interest among IETF participants in seeing
an OTR RFC published (Stephen Farrell is one of the Security Area
Directors). As mentioned, Paul and I have talked about this, and I
recall recent discussion on this list about it (did someone volunteer
to work on an Internet-Draft?) but I can't put my finger on the right
message.

I would be very happy to help work on this with whoever is interested.

Peter

- -------- Original Message --------
Subject: Re: [xmpp] Proposed XMPP Charter Update
Date: Mon, 25 Feb 2013 16:08:03 +0000
From: Stephen Farrell <stephen.farrell at cs.tcd.ie>
To: Ben Campbell <ben at nostrum.com>
CC: XMPP Working Group <xmpp at ietf.org>

Hi,

I've no objection to this charter but do have a question:

Q: loads of us use OTR, but there's no mention of that
in the charter - why don't we just spec that in an RFC?

Or two RFCs if need be, one for what's done now, one with
any changes the WG think are needed and will be deployed.

A quick web search leads me to believe that this [1]
might be how OTR works, but I could be wrong. Even having
an informational RFC as a stable reference would seem
to be an improvement.

Sorry if there's an obvious answer and I've not got the
history.

Ta,
S.

[1] http://www.cypherpunks.ca/otr/Protocol-v3-4.0.0.html

On 02/21/2013 07:59 PM, Ben Campbell wrote:
> Hi Everyone,
> 
> We need to do a minor charter update to add the XMPP/WebSockets
> work.
> 
> Here's the proposed new text. This version is the same as before,
> except it removes the text for XMPP interworking with SIP/SIMPLE,
> an adds text for WebSockets. The new text is the second to last
> paragraph.
> 
> Please send any feedback to the XMPP mailing list as soon as
> possible. (If you agree with the text as is, please say that, too
> :-) )
> 
> Thanks!
> 
> Ben.
> 
> -----------------
> 
> The Extensible Messaging and Presence Protocol (XMPP) is an 
> technology for the near-real-time exchange of messages and
> presence notifications, where data is exchanged over Extensible
> Markup Language (XML) streams. The original XMPP working group
> published RFCs 3920-3923.
> 
> Implementation and deployment experience since that time has
> resulted in errata, clarifications, and suggestions for improvement
> to the core XMPP specifications (RFCs 3920 and 3921). Some
> technologies on which XMPP depends (e.g., Transport Layer Security
> and the Simple Authentication and Security Layer) have undergone
> modifications of their own, which XMPP needs to track. Finally, the
> group needs to define a sustainable solution to
> internationalization of XMPP addresses, since the approach taken in
> RFC 3920 (based on stringprep profiles) is limited to Unicode 3.2
> characters. Both draft-saintandre-rfc3920bis-* and 
> draft-saintandre-rfc3921bis-* reflect community input so far
> regarding these modifications, but the group needs to complete
> this work, especially with regard to internationalization. Because
> of the scope of changes involved, it is envisioned that these
> specifications will be cycled at Proposed Standard.
> 
> Although RFC 3923 defines an end-to-end signing and encryption 
> technology for use by XMPP systems, to date it has not been
> implemented. A goal of the group is to develop an implementable
> method for end-to-end encryption, preferably based on well known
> and widely deployed security technologies.
> 
> XMPP uses TLS for encryption and the Simple Authentication and
> Security Layer (SASL) for authentication. In the case of a
> server-to-server stream, XMPP is deployed using TLS and the SASL
> EXTERNAL mechanism, where each peer presents an X.509 certificate.
> This model introduces scaling challenges in multi-domain
> deployments because RFC 3920 requires that a stream cannot be
> reused for more than one domain, thus necessitating multiple TCP
> connections. The group will work to overcome these challenges by
> defining an optional mechanism for using a single connection with
> multiple identities. It is anticipated that most of the work will
> consist of defining and providing requirements to the TLS and SASL
> working groups.
> 
> In addition to the TCP binding defined in RFC 6120, the XMPP
> community has long employed an HTTP binding (XEP-0124 and XEP-0206
> published by the XMPP Standards Foundation).  Given that this
> binding uses HTTP long polling, which has many known issues (RFC
> 6202), it is reasonable to transition to use of the WebSocket
> protocol (RFC 6455) instead.  Work has begun on defining a
> WebSocket subprotocol for XMPP (draft-moffitt-xmpp-over-websocket).
> The group will complete the definition of such a subprotocol, and
> coordinate reviews with the HYBI WG where appropriate.
> 
> In completing its work, the group will strive to retain backwards 
> compatibility with RFCs 3920 and 3921. However, changes that are
> not backwards compatible might be accepted if the group determines
> that the changes are required to meet the group's technical
> objectives and the group clearly documents the reasons for making
> them. _______________________________________________ xmpp mailing
> list xmpp at ietf.org https://www.ietf.org/mailman/listinfo/xmpp
> 
> 
_______________________________________________
xmpp mailing list
xmpp at ietf.org
https://www.ietf.org/mailman/listinfo/xmpp

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRK5gyAAoJEOoGpJErxa2pxKAQAIeann7GJ6vYfGm40AYj6hm3
DcVuKfKm4K4t5Prym4YoPnKZ7Vm3aHj9jmuGU8oSWtf2WzWYsfa+51GSf/3xYPYj
m22GRhZAuy8kIwUOz1Pwvfh+jhQJikQ/99W30gJsu3A8NIkATBQOUnvA1WoiqyJ+
DSGQTF5uf6z38BEbb7aNfEI9kArsMfnPjyY5gY9NvMHO2TD+8lcy2tXDJT+fBjt9
4pmNHV44w9sAi/xKxdIrPmMjwiHmbCJx0ZZJa6SZ5WELfq75dYaWUF5TuXx6awiH
WZaWv/yKj7AH2xr/iR01boqjLi9Ie9dPgw33gj8g4dLGCKCmAY/oCgS6a6XFYo2g
S6GlscVNkctj51RvCh7ksj7geo7XoiWPraveuJDI/wmvoGfOZSDpyIypUHzND20h
tk9+4szvb9zllRSRL/KRNG+2AeMyiA3ToDKlmkOnieGh3Cz8EJoiMaAvg/1cY2vL
skkz3l801xw46AUca4+EwIINSCoLgXmZSbcZn5yY0mkrZ6CFHwhfYkXZGWcMRfg6
mLHw/AzObSrRaOZXuSuojxdED0rHdc3Rw+v+9nJsGYHyPCp3bCz8gHoORIy6KY/R
2lUgrsqVf4K/Qm5WwUmJ5vr/ovVieYd78Yt5wQVpC0shD46r60f5z7CFhN+zPHyw
uJejS0znGWQWwT7WtXc1
=tcek
-----END PGP SIGNATURE-----