Peter Saint-Andre | 11 Jul 03:21 2014

next steps on draft-ietf-xmpp-websocket

Dear Authors and WG,

This morning, at Richard's invitation and as the document shepherd for 
draft-ietf-xmpp-websocket, I briefly joined the IESG telechat to talk 
through the DISCUSS positions lodged by Stephen Farrell and Ted Lemon:

https://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/ballot/

As a result, I'd like to ask the authors to complete several tasks (and 
I will be happy to propose or help with text for these items, since I 
was present during the IESG discussion):

1. More clearly describe the delegation scenario outlined in the second 
paragraph of Section 6:

    Browser based applications are not able to inspect and verify at the
    application layer the certificate used for the WebSocket connection
    to ensure that it corresponds to the domain specified as the "to"
    address of the XMPP stream.  For hosts whose domain matches the
    origin for the WebSocket connection, that check is already performed
    by the browser.  However, in situations where the domain of the XMPP
    server might not match the origin for the WebSocket endpoint
    (especially multi-tenant hosting situations), the web host metadata
    method (see [RFC6415] and [XEP-0156]) MAY be used to delegate trust
    from the XMPP server domain to the WebSocket origin.

In particular, it would be very helpful to add two examples (one in 
which the WebSocket origin matches the domain of the XMPP service, and 
one in which it does not, e.g., delegation of foo.example to 
hosting.example.net) and to explain that the delegation model is 
(Continue reading)

The IESG | 21 Jun 01:56 2014
Picon

Last Call: <draft-ietf-xmpp-websocket-07.txt> (An XMPP Sub-protocol for WebSocket) to Proposed Standard


The IESG has received a request from the Extensible Messaging and
Presence Protocol WG (xmpp) to consider the following document:
- 'An XMPP Sub-protocol for WebSocket'
  <draft-ietf-xmpp-websocket-07.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2014-07-04. Exceptionally, comments may be
sent to iesg <at> ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document defines a binding for the XMPP protocol over a
   WebSocket transport layer.  A WebSocket binding for XMPP provides
   higher performance than the current HTTP binding for XMPP.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/ballot/

No IPR declarations have been submitted directly on this I-D.
Richard Barnes | 20 Jun 22:09 2014

AD review of draft-ietf-xmpp-websocket

I have reviewed this draft in preparation for IETF LC.  Overall, it looks to be in good shape.  Thanks for a nice document.  I've requested last call, and there are a few minor comments below to consider along with LC comments.

Thanks,
--Richard


MINOR

S3.1. "WebSocket messages sent or received will conform"
Should this be "MUST conform"?

S3.6.1. "a different transport, such as BOSH"
How is the recipient of one of these messages supposed to tell what transport?  Does the use of an http- or https-schemed URI imply BOSH?

S3.7. "[Streams implicitly closed]"
Does this usage map cleanly to the TCP case?  That is, would a </stream> element be sent in this closure case?  I'm just imagining that if you have, say, a relatively naïve gateway that translates <stream> to <open> and </stream> to <close>, this could cause problems.

_______________________________________________
xmpp mailing list
xmpp <at> ietf.org
https://www.ietf.org/mailman/listinfo/xmpp
internet-drafts | 20 Jun 05:40 2014
Picon

I-D Action: draft-ietf-xmpp-posh-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF.

        Title           : PKIX over Secure HTTP (POSH)
        Authors         : Matthew Miller
                          Peter Saint-Andre
	Filename        : draft-ietf-xmpp-posh-01.txt
	Pages           : 14
	Date            : 2014-06-19

Abstract:
   Experience has shown that it is extremely difficult to deploy proper
   PKIX certificates for TLS in multi-tenanted environments, since
   certification authorities will not issue certificates for hosted
   domains to hosting services, hosted domains do not want hosting
   services to hold their private keys, and hosting services wish to
   avoid liability for holding those keys.  As a result, domains hosted
   in multi-tenanted environments often deploy non-HTTP applications
   such as email and instant messaging using certificates that identify
   the hosting service, not the hosted domain.  Such deployments force
   end users and peer services to accept a certificate with an improper
   identifier, resulting in obvious security implications.  This
   document defines two methods that make it easier to deploy
   certificates for proper server identity checking in non-HTTP
   application protocols.  The first method enables the TLS client
   associated with a user agent or peer application server to obtain the
   end-entity certificate of a hosted domain over secure HTTP as an
   alternative to standard PKIX techniques.  The second method enables a
   hosted domain to securely delegate a non-HTTP application to a
   hosting service using redirects provided by HTTPS itself or by a
   pointer in a file served over HTTPS at the hosted domain.  While this
   approach was developed for use in the Extensible Messaging and
   Presence Protocol (XMPP) as a Domain Name Association prooftype, it
   can be applied to any non-HTTP application protocol.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-xmpp-posh/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-xmpp-posh-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-posh-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
Ben Campbell | 17 Jun 16:29 2014

Publication Requested for draft-ietf-xmpp-websocket-07

Hi Everyone,

We just requested publication for draft-ietf-xmpp-websocket-07. It's in the hands of the IESG now. 

Thanks to the authors for all the hard work on this (so far :-) ). Thanks also go to all those who reviewed and
discussed it.

Ben.
Dave Cridland | 9 Jun 12:14 2014
Picon

draft-cridland-xmpp-session-00

https://datatracker.ietf.org/doc/draft-cridland-xmpp-session/

After some discussion in the XSF's chatrooms, I've submitted this which I think captures current practise and seems to be the least-unsensible option.

Happy to have the WG adopt this if the chairs and WG desire, otherwise I'll go fishing for an AD sponsor.

The nub is as described in its Section 2:

2.  The Session Establishment Tombstone

   This specification formalizes the <optional/> marker and explicitly
   defines the Session Establishment request itself as a no-op.

Dave.
_______________________________________________
xmpp mailing list
xmpp <at> ietf.org
https://www.ietf.org/mailman/listinfo/xmpp
Matt Miller | 5 Jun 00:17 2014
Picon

Fwd: [POSH] What's the point of using JWKs in POSH?


[ Forwarding to the xmpp <at> ietf.org mailing list on behalf of Thjis
Alkemade ]

Hello,

Today, I've spent some time on trying to implement POSH-checking for
xmpp.net. My implementation aimed to do two things: doing the
validation as described and showing someone how they could set up
their .well-known file by converting their X509 certificates to JSON
Web Keys.

The latter part was a lot more work than the former and made me wonder
why it is defined the way it is.

From draft-ietf-xmpp-posh:

  Each included JWK object MUST possess the following information:

   o  The "kty" field set to the appropriate key type used for TLS
      connections (e.g., "RSA" for a certificate using an RSA key).

   o  The required public parameters for the key type (e.g., "n" and "e"
      for a certificate using an RSA key).

   o  The "x5t" field set to the certificate thumbprint, as described in
      section 3.6 of [JOSE-JWK].

Yet the data that is required in the first and second bullet is never
used. It doesn't specify if and how clients should verify it.
Verification only uses the x5t field and optionally x5c.

There are good arguments for "pinning" just the public key.
draft-ietf-websec-key-pinning only uses the SPKI field, DANE can use
either the full cert or its SPKI field (and optionally hashed). But
the way it is specified here won't allow that: the x5t field always
needs to be present and clients should verify it.

So the public parameters of the key are useless here, but they make a
key >10x as large is they have to be. Generating them is also not as
easy: most certificate viewers show a SHA1 fingerprint and it's really
easy to do with the openssl cli tool, but extracting n and e and
base64-encoding them is a lot more work. I wouldn't even know what to
do for ECDSA keys.

Are there any interoperability reasons for using JWKs that I'm not
aware of? Couldn't it just use a list of SHA1 hashes?

Best regards,
Thijs
Ben Campbell | 30 Apr 16:40 2014

XMPP at IETF 90

Hi,

6122bis and XMPP/Websocket are passed WGLC without major controversy, and our other milestones are
probably not in a state to benefit from intensive face to face communication at this moment. The chairs are
leaning against having an XMPP meeting in Toronto.

If anyone has a substantial objection to that plan, please indicate so on the working group list as soon as possible.

Thanks!

Ben.
Lance Stout | 23 Apr 00:28 2014
Picon

Fwd: New Version Notification for draft-ietf-xmpp-websocket-06.txt

FYI

This version addresses feedback from Ben Campbell:

- Changed the use of <invalid-namespace/> error to a MUST instead of SHOULD
- Specify that TLS MUST be enabled at the WebSocket layer, if used
- Clarify that a server can close the connection with see-other-uri at any time
- Clarify that the closing process mirrors RFC 6120
- Reword the considerations when using XEP-0198 to be clearer
- Explicitly state that whitespace keepalives MUST NOT be used (based on the framing restrictions; use
Ping or Stream Management instead)
- Note that ping control frames MAY be used, but might not be accessible in all cases

Begin forwarded message:

> From: internet-drafts <at> ietf.org
> Subject: New Version Notification for draft-ietf-xmpp-websocket-06.txt
> Date: April 22, 2014 at 3:22:20 PM PDT
> To: "Lance Stout" <lance <at> andyet.net>, Eric Cestari <eric <at> cstar.io>, "Eric Cestari"
<eric <at> cstar.io>, "Jack Moffitt" <jack <at> metajack.im>, Lance Stout <lance <at> andyet.net>, Jack Moffitt <jack <at> metajack.im>
> 
> 
> A new version of I-D, draft-ietf-xmpp-websocket-06.txt
> has been successfully submitted by Lance Stout and posted to the
> IETF repository.
> 
> Name:		draft-ietf-xmpp-websocket
> Revision:	06
> Title:		An XMPP Sub-protocol for WebSocket
> Document date:	2014-04-22
> Group:		xmpp
> Pages:		14
> URL:            http://www.ietf.org/internet-drafts/draft-ietf-xmpp-websocket-06.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/
> Htmlized:       http://tools.ietf.org/html/draft-ietf-xmpp-websocket-06
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-websocket-06
> 
> Abstract:
>   This document defines a binding for the XMPP protocol over a
>   WebSocket transport layer.  A WebSocket binding for XMPP provides
>   higher performance than the current HTTP binding for XMPP.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

Attachment (smime.p7s): application/pkcs7-signature, 5731 bytes
_______________________________________________
xmpp mailing list
xmpp <at> ietf.org
https://www.ietf.org/mailman/listinfo/xmpp
internet-drafts | 23 Apr 00:22 2014
Picon

I-D Action: draft-ietf-xmpp-websocket-06.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF.

        Title           : An XMPP Sub-protocol for WebSocket
        Authors         : Lance Stout
                          Jack Moffitt
                          Eric Cestari
	Filename        : draft-ietf-xmpp-websocket-06.txt
	Pages           : 14
	Date            : 2014-04-22

Abstract:
   This document defines a binding for the XMPP protocol over a
   WebSocket transport layer.  A WebSocket binding for XMPP provides
   higher performance than the current HTTP binding for XMPP.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-xmpp-websocket-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-websocket-06

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
Ben Campbell | 21 Apr 23:15 2014

Comments on draft-ietf-xmpp-websocket-05

Here's some just under the wire comments on draft-ietf-xmpp-websocket-05. It mostly looks fine, but I
have a few comments, mainly about some 2119 language, and about connection managers:

-- 3.1: "During the WebSocket handshake, the client MUST include the Sec-WebSocket-Protocol header in
its handshake, and the value |xmpp| MUST be included in the list of protocols. "

Isn't the "MUST include Sec-WebSocket-Protocol" part really a requirement of WebSocket in general? That
is, is it in any way specific to XMPP?, if it's simply a repetition of a general WebSocket requirement, we
should not state it normatively here. ( In any case, it seems to be implied by the "value MUST include xmpp"  part.)

-- 3.2.2: "...  MUST close the stream with an error, which SHOULD be <invalid-namespace> ..."

Why SHOULD and not MUST? Are there reasonable circumstances to choose something else? Can you offer
guidance on why one might choose something else, and what impact that would have?

-- 3.6:

Do we have to worry about half-closes situations where the peer does not respond in a timely manner? How
about glare?

How does the XEP-0198 guidance after the figure interact with the guidance saying the closing party SHOULD
close the stream? That would seem to imply one SHOULD NOT keep the stream alive, since that would involve
not closing the stream.

-- 3.6.1: Can a server (or connection manager) redirect the client at any time?

-- 3.8:

First paragraph says clients can use extra whitespace, but goes onto say you SHOULD use WebSocket ping
control frames. Does that mean we are recommending _against_ using the extra whitespace? If so, I'd avoid
language saying you "can" do it in the first place, or add some qualification to make it clear those are
"standard" XMPP clients and servers, but _WebSocket_ implementations SHOULD do things differently.

Are the uses of XMPP Ping or Stream Management for this purpose limited to the connection manager case? If
not, does the aforementioned SHOULD also recommend against doing these?

Are clients and servers expected to know that a connection manager exists in the first place? Can we have
plain-vanilla XMPP servers with a websocket connection manager? If so, how would they know to follow the
XMPP/WebSocket recommendations? 

-- 3.9: " ... enabling TLS SHOULD be done at the WebSocket layer ... "

Why not MUST? Can you give guidance about when it might make sense not to do it, and the consequences?

Does the possibility of a connection manager change anything?

Gmane