The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP)
draft-pd-dispatch-msrp-websocket-15

[Ballot comment]

The first part of this was a DISCUSS that Ben answered.

Thanks for making TLS a MUST-use in section 10. However,
that makes me wonder why it's ever ok to not use TLS
on the other side of the MSRP relay. I assume that's
down to deployments that can't ensure TLS on both sides
but that then raises some questions for me that I didn't
see answered in the document, so I'd like to briefly
check/chat-about those... (and also to ask if you can up
the ante as well:-)

(1) When both sides of the MSRP relay do want TLS, but the
MSRP-relay-as-TLS-client fails to setup the "righthand"
(referring to the draft's diagrams) TLS session, say
because of a bad cert, what does the browser see? (That
may be entirely obvious to someone who knows MSRP and need
no change in the draft, but it wasn't clear to me.)

(2) If the "righthand" MSRP session is not protected with
TLS, then is that fully under the control of the
client/browser? IOW, how does the browser/client express a
desire that it really really wants TLS on both sides or
else to fail?  I think that's down to using msrps URIs but
am not sure.  Again that might be clear to anyone who
knows MSRP but I don't:-) Can you clarify?

(3) The answer is probably "no" but would it be feasible
to say that a client for this MUST only use msrps: URIs?
If it were feasible, that'd be good I think. If it's not
feaasible, that's a pity, but I'm not asking that you add
pretend statements about security we won't get;-)

From here on was not a discuss.




- I also agree with Alissa's comment about the m= line and
am glad to see that change was accepted.

- 5.3.1: Why is there no option for TLS client auth here?
If you allow cookies, then I don't see why you say nothing
about that.

- section 7: I don't get why you want/need CORS here - can
you explain? (Not sure if something needs stating in the
document, but as-is, it's unclear to me.)

- 8.1.2 and elsewhere: It'd have been fine to only say
once that MRSP doesn't allow line folding:-)

- section 9: Thanks! Great to see that.

- section 10: Thanks for saying that TLS MUST be used
between client/browser and MSRP relay. That's a bit buried
down here though - I think it'd have been good to say that
at the top of the document too. (I got the wrong initial
impression that you were allowing cleartext between the
client/browser and MSRP relay from the start of the
document.)

- section 10: Do you need to add a security consideration
saying that the MSRP relay can see the plaintext and that
the client/browser shouldn't indicate e2e security to the
user?

- section 10: Wouldn't it be a good idea to add a
statement that TLS as used here ought follow BCP195?
(RFC7525)

[Ballot discuss]

Thanks for making TLS a MUST-use in section 10. However,
that makes me wonder why it's ever ok to not use TLS
on the other side of the MSRP relay. I assume that's
down to deployments that can't ensure TLS on both sides
but that then raises some questions for me that I didn't
see answered in the document, so I'd like to briefly
check/chat-about those... (and also to ask if you can up
the ante as well:-)

(1) When both sides of the MSRP relay do want TLS, but the
MSRP-relay-as-TLS-client fails to setup the "righthand"
(referring to the draft's diagrams) TLS session, say
because of a bad cert, what does the browser see? (That
may be entirely obvious to someone who knows MSRP and need
no change in the draft, but it wasn't clear to me.)

(2) If the "righthand" MSRP session is not protected with
TLS, then is that fully under the control of the
client/browser? IOW, how does the browser/client express a
desire that it really really wants TLS on both sides or
else to fail?  I think that's down to using msrps URIs but
am not sure.  Again that might be clear to anyone who
knows MSRP but I don't:-) Can you clarify?

(3) The answer is probably "no" but would it be feasible
to say that a client for this MUST only use msrps: URIs?
If it were feasible, that'd be good I think. If it's not
feaasible, that's a pity, but I'm not asking that you add
pretend statements about security we won't get;-)

[Ballot comment]

- I also agree with Alissa's comment about the m= line and
am glad to see that change was accepted.

- 5.3.1: Why is there no option for TLS client auth here?
If you allow cookies, then I don't see why you say nothing
about that.

- section 7: I don't get why you want/need CORS here - can
you explain? (Not sure if something needs stating in the
document, but as-is, it's unclear to me.)

- 8.1.2 and elsewhere: It'd have been fine to only say
once that MRSP doesn't allow line folding:-)

- section 9: Thanks! Great to see that.

- section 10: Thanks for saying that TLS MUST be used
between client/browser and MSRP relay. That's a bit buried
down here though - I think it'd have been good to say that
at the top of the document too. (I got the wrong initial
impression that you were allowing cleartext between the
client/browser and MSRP relay from the start of the
document.)

- section 10: Do you need to add a security consideration
saying that the MSRP relay can see the plaintext and that
the client/browser shouldn't indicate e2e security to the
user?

- section 10: Wouldn't it be a good idea to add a
statement that TLS as used here ought follow BCP195?
(RFC7525)

[Ballot comment]
In Section 10, last para:

  Any security considerations specific to the WebSocket protocol are
  detailed in the relevant specifications ([RFC6455] and [RFC4975]) and
  are considered outside the scope of this document.  The certificate
  name matching and cryptosuite selection will be handled by the
  browser, and the browser's procedures will supercede those specified
  in [RFC4975].

Certificate name matching is described by RFC 6455, so the above text is not accurate.
(The point about certificate matching from [RFC4975] not being used is correct though.)

[Ballot comment]
I see you've addressed Alissa & Mirja's comments, thanks for that.  I also agree with Alexey's, but can't find the discussion, so I am not sure mail went out on it.

[Ballot comment]
In Section 10, last para:

  Any security considerations specific to the WebSocket protocol are
  detailed in the relevant specifications ([RFC6455] and [RFC4975]) and
  are considered outside the scope of this document.  The certificate
  name matching and cryptosuite selection will be handled by the
  browser, and the browser's procedures will supercede those specified
  in [RFC4975].

Certificate name matching is described by RFC 6455, so the above text is not accurate.
(The point about certificate matching from [RFC4975] not being used is correct.)

[Ballot comment]
Nits/minor questions:

1) Please spell out MSRP at the first occurance in the 2. paragraph in the intro and give a reference
s/MSRP/MSRP (Message Session Relay Protocol) [RFC4975]/

2) In section 4.2 the following sentence is not fully clear to me:
"The content of text frames MUST be interpreted as binary by WebSocket Clients and Servers."
Wouldn't that break if the content of the text frame is actually UTF-8? Wouldn't it be better to ignor text frames?

3) Section 8.2.3 has a copy/paste error:
Last transaction should be "F4 200 OK  Alice -> a.example.com (transport WSS)" (and not " F4 200 OK  Bob -> a.example.com (transport TLS)")

4) Inline with Alissa's comment:
These two statement seem to contradict each other:
"it is acceptable for an MSRP WebSocket Client to specify the "TCP/MSRP" or "TCP/TLS/MSRP" protocols in the SDP m-line" (section 5.2.2)
and
"MSRP traffic transported over WebSockets MUST be protected by using a secure WebSocket connection (using TLS [RFC5246] over TCP)." (section 10)

[Ballot comment]
Nits/minor questions:

1) Please spell out MSRP at the first occurance in the 2. paragraph in the intro and give a reference
s/MSRP/MSRP (Message Session Relay Protocol) [RFC4975]/

2) In section 4.2 the following sentence is not fully clear to me:
"The content of text frames MUST be interpreted as binary by WebSocket Clients and Servers."
Wouldn't that break if the content of the text frame is actually UTF-8? Wouldn't it be better to ignor text frames?

3) Section 8.2.3 has a copy/paste error:
Last transaction should be "F4 200 OK  Alice -> a.example.com (transport WSS)"
(and not " F4 200 OK  Bob -> a.example.com (transport TLS)")

4) Inline with Alissa's comment:
These two statement seem to contradict each other:
"it is acceptable for an MSRP WebSocket Client to specify the "TCP/MSRP" or "TCP/TLS/MSRP" protocols in the SDP m-line" (section 5.2.2)
and
"MSRP traffic transported over WebSockets MUST be protected by using a secure WebSocket connection (using TLS [RFC5246] over TCP)." (section 10)

[Ballot comment]
I see in 5.2.2 that it is acceptable for clients to specify "TCP/MSRP" in an SDP m-line. But then in Section 10 there is the requirement for MSRP-over-websocket traffic to be protected by TLS, and RFC 4976 requires the same for all client-relay communications. What is the use case where a client would signal TCP/MSRP in an m-line while also indicating use of a websocket relay? I'm having trouble understanding why the option to specify TCP/MSRP is needed.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-pd-dispatch-msrp-websocket-12.txt. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the WebSocket Subprotocol Name Registry in the WebSocket Protocol Registries located at:

https://www.iana.org/assignments/websocket/

a single new subprotocol name will be registered as follows:

Subprotocol Identifier: msrp
Subprotocol Common Name: WebSocket Transport for MSRP (Message Session Relay Protocol)
Subprotocol Definition: [ RFC-to-be ]
Reference: [ RFC-to-be ]

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 


Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: ben@nostrum.com, draft-pd-dispatch-msrp-websocket@ietf.org, mary.ietf.barnes@gmail.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP)) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'The WebSocket Protocol as a Transport for the Message Session Relay
  Protocol (MSRP)'
  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@ietf.org mailing lists by 2016-07-08. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The WebSocket protocol enables two-way real-time communication
  between clients and servers in situations where direct access to TCP
  and UDP are not available (for example, from within Javascript in a
  web browser).  This document specifies a new WebSocket sub-protocol
  as a reliable transport mechanism between MSRP (Message Session Relay
  Protocol) clients and relays to enable usage of MSRP in new
  scenarios.  This document normatively updates RFC 4975 and RFC 4976.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-pd-dispatch-msrp-websocket/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-pd-dispatch-msrp-websocket/ballot/


No IPR declarations have been submitted directly on this I-D.

Here is my AD evaluation of draft-pd-dispatch-msrp-websocket-12. Nothing here need block the IETF Last Call.

-1, last paragraph: Consider citing RFC4976 for "MSRP relay". (I also suggest citations to 4975 and 4976 when you talk about "normal" clients and relays.

-5.1, first paragraph: "...messages MUST be routed
via an MSRP WebSocket Server"

This seems more a statement of fact than a normative requirement. That is, it is an implication of the fact that websocket clients cannot directly connect to other websocket clients. Please consider removing the upper-case MUST.

5.3.1. 4th paragraph (1st after numbered list): s/event/even

- General: IDNits emits the following:

-- The document seems to contain a disclaimer for pre-RFC5378 work, and may
    have content which was first submitted before 10 November 2008.  The
    disclaimer is necessary when there are original authors that you have
    been unable to contact, or if some do not wish to grant the BCP78 rights
    to the IETF Trust.  If you are able to get all authors (current and
    original) to grant those rights, you can and should remove the
    disclaimer; otherwise, the disclaimer is needed and you can ignore this
    comment. (See the Legal Provisions document at
    http://trustee.ietf.org/license-info for more information.)


. Is any part of the document that old? I suspect this is due to the update of 4975 and 4976. Do you incorporate substantial text or examples from those RFCs? If not, I'm not sure we need the disclaimer.

(I vaguely recall discussing this before, but maybe that was for a different MSRP related draft.)