Subject: [rtcweb] Alexey Melnikov's No Objection on draft-ietf-rtcweb-alpn-03: (with COMMENT)

From: "Alexey Melnikov" <[email-masked]>
Date: Thu, 28 Apr 2016 09:01:09 -0700

Alexey Melnikov has entered the following ballot position for
draft-ietf-rtcweb-alpn-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-alpn/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Please excuse my ignorance (pointers would be appreciated, if this is
explained elsewhere): do RTP intermediary need to be updated to
understand this spec?
If yes, how can you enforce requirements on "c-webrtc"?

---

From: Martin Thomson <[email-masked]>
Date: Fri, 29 Apr 2016 09:51:20 +1000

> explained elsewhere): do RTP intermediary need to be updated to

No.  Mostly.  RTP intermediaries can choose to implement this spec as
an endpoint, but there is typically no benefit from doing so.  RTP
intermediaries don't usually have a strong distinction between "the
thing that does (S)RTP" and "the thing that controls signaling" and so
don't gain much by isolating media from the latter.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 29 Apr 2016 10:30:09 +0100

> don't gain much by isolating media from the latter.

Section 3 says:

   RTP middleboxes and entities that forward media or data cannot
   promise to maintain confidentiality.  Any entity that forwards
   content, or records content for later access by entities other than
   the authenticated peer, MUST NOT offer or accept a session with the
   "c-webrtc" identifier.

So, my questions are:

1) Do RTP middleboxes frequently forward content, or records content for
later access by entities other than
   the authenticated peer?
2) If the answer to 1) is "yes", why would RTP middlebox software
developers bother to update software to comply with this specification?

Please help me understand, if I misunderstood the text.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 29 Apr 2016 20:06:03 +1000

> developers bother to update software to comply with this specification?

(I should really read my own doc before answering.)

Yes, middleboxes do this all the time.  However, they don't need to
update their software.  Endpoints that implement this spec will assume
that the absence of ALPN means that there is no confidentiality.  And
I realize now that I never actually said that.  That was extremely
remiss of me...

https://github.com/martinthomson/drafts/commit/21b84074a671bd