Subject: [rtcweb] Fwd: New Version Notification for draft-thomson-rtcweb-alpn-00.txt

From: Martin Thomson <[email-masked]>
Date: Wed, 9 Apr 2014 11:09:20 -0700

The intent of this draft is to address the isolation issue.

Unlike a TLS extension, this doesn't require that the TLS WG provide
an official blessing.  Though I'll note that this is the advice that
at least two participants in that working group suggested for
addressing this problem.

In short: negotiate "webrtc" if you are doing the usual, insecure
thing; negotiate "c-webrtc" if you would like media confidentiality.

A new version of I-D, draft-thomson-rtcweb-alpn-00.txt
has been successfully submitted by Martin Thomson and posted to the
IETF repository.

Name:           draft-thomson-rtcweb-alpn
Revision:       00
Title:          Application Layer Protocol Negotiation for Web
Real-Time Communications (WebRTC)
Document date:  2014-04-09
Group:          Individual Submission
Pages:          6
URL:
http://www.ietf.org/internet-drafts/draft-thomson-rtcweb-alpn-00.txt
Status:         https://datatracker.ietf.org/doc/draft-thomson-rtcweb-alpn/
Htmlized:       http://tools.ietf.org/html/draft-thomson-rtcweb-alpn-00

Abstract:
   Application Layer Protocol Negotiation (ALPN) labels are defined for
   use in identifying Web Real-Time Communications (WebRTC) usages of
   Datagram Transport Layer Security (DTLS).  Labels are provided for
   identifying a session that uses a combination of WebRTC compatible
   media and data, and for identifying a session requiring
   confidentiality protection.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Apr 2014 15:12:59 -0400

If you propose to use ALPN for this, then "webrtc" and "c-webrtc" must 
be Application Level Protocols - presumably *different* protocols.

But what is the *protocol*? I don't see that mentioned in the draft at all.

IIUC it must be the multiplexing of STUN, SRTP, and SCTP over DTLS. 
(Maybe not STUN - maybe that is *below* or *beside* DTLS.) I see how it 
could make sense to use ALPN to verify that this is the intended use of 
the DTLS session. But that isn't even mentioned in the draft.

And, from a protocol perspective, what is the difference between webrtc 
and c-webrtc? AFAICT this is just two different usages of the same 
"protocol", not two different protocols.

	Thanks,
	Paul

On 4/9/14 2:09 PM, Martin Thomson wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 9 Apr 2014 12:52:42 -0700

> But what is the *protocol*? I don't see that mentioned in the draft at all.

There are two.  Those two are described (perhaps not explicitly
enough) in the list in Section 2.

> IIUC it must be the multiplexing of STUN, SRTP, and SCTP over DTLS. (Maybe
> not STUN - maybe that is *below* or *beside* DTLS.) I see how it could make
> sense to use ALPN to verify that this is the intended use of the DTLS
> session. But that isn't even mentioned in the draft.

Yeah, STUN isn't inside DTLS, so it doesn't make a lot of sense to
"negotiate" its use.

> And, from a protocol perspective, what is the difference between webrtc and
> c-webrtc? AFAICT this is just two different usages of the same "protocol",
> not two different protocols.

Yep.  But that's what a protocol is.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Apr 2014 16:56:11 -0400

> enough) in the list in Section 2.

Not explicitly enough, IMO.

> Yep.  But that's what a protocol is.

Not in my book. I expect two different protocols to look different on 
the wire.

You seem to be saying that SMTP used to talk to ietf mailing lists is a 
different protocol from SMTP used to talk to my lawyer, because I expect 
my lawyer to keep the communications confidential.

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Wed, 9 Apr 2014 14:25:53 -0700

On 9 April 2014 13:56, Paul Kyzivat <[email-masked]> wrote:
> I expect two different protocols to look different on the wire.
>
> different protocol from SMTP used to talk to my lawyer, because I expect my
> lawyer to keep the communications confidential.

They are different on the wire.  They use different identifiers.

That's hair splitting, but there's a real difference between the two
usages.  And I think that it's important enough to do this.

Do you perhaps have an alternative, or is it just that this lack of
solidity is giving you heartburn?  Because I can appreciate that.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 10 Apr 2014 10:52:28 +0200

On 04/09/2014 10:56 PM, Paul Kyzivat wrote:
>>> (Maybe
> You seem to be saying that SMTP used to talk to ietf mailing lists is 
> a different protocol from SMTP used to talk to my lawyer, because I 
> expect my lawyer to keep the communications confidential.

(not to be taken as a comment on the proposal, because I haven't 
read/understood it yet)

an adequate parallel would be SMTP (used for MTA-to-MTA relay on port 
25) and SUBMIT (used for message submission on port 587).

They are identical on the wire (apart from an extension in the EHLO 
response), but have different purposes, and are therefore called 
different protocols.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Apr 2014 10:47:42 -0400

> solidity is giving you heartburn?  Because I can appreciate that.

Heartburn.

It seems like a hack - tunneling - just looking for *something* that can 
be used to convey one more bit of data.

I don't have another suggestion. I only half understand the problem. But 
to the extent that I do, it seems ill-defined. AFAIK it only really has 
meaning in the context of a browser. Once you start signaling it, it 
gets fuzzier. If you *knew* both ends were controlled by a browser 
following these conventions then it would be a bit clearer. But when 
that ceases to be true I can make no sense of what it all means. And as 
best I understand, the isolation is intended to be per-media-stream, so 
solutions that are at a different level seem problematic.

	Thanks,
	Paul