Subject: Re: [tram] Ben Campbell's Discuss on draft-ietf-tram-turn-server-discovery-09: (with DISCUSS and COMMENT)

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 11 Oct 2016 07:01:19 +0000

Hi Ben,

Updated draft https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-10 to address your comments, Please have a look.

Thanks and Regards,
-Tiru

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Ben Campbell
> Sent: Wednesday, September 21, 2016 4:00 AM
> To: Prashanth Patil (praspati) <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked]; draft-ietf-tram-turn-
> [email-masked]; [email-masked]; Simon Perreault
> <[email-masked]>
> Subject: Re: [tram] Ben Campbell's Discuss on draft-ietf-tram-turn-server-
> discovery-09: (with DISCUSS and COMMENT)
> 
> On 20 Sep 2016, at 17:21, Ben Campbell wrote:
> 
> > To be clear, I think that discussion is incomplete. RFC 5766 discusses
> >>> several security considerations that explicitly mention
> >>> authentication as a mitigating factor. For example, 17.1.1, 17.1.3,
> >>> 17.1.7, and 17.2.1.
> >>>
> >>> Those paragraphs (and the bullet list before them) also seem to
> >>> depend on (D)TLS to mitigate some of the issues. But even that is
> >>> only a SHOULD.
> >
> >>
> >> Right, I think we can mandate (D)TLS *if* STUN authentication or
> >> third-party authorization is not used.
> >
> > I think that would help.
> 
> Oops, I meant to type a bit more...
> 
> Even with that addition, I still think the draft needs to address the
> impact on the issues discussed in the aforementioned sections of 5766.
> If (D)TLS solves the same issues, it would be good to say that. If there
> are things not addressed by TLS (likely true for some of the issues
> mitigated by knowing the client identity), then the draft should mention
> those, too.
> 
> Thanks!
> 
> Ben.
> 
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 11 Oct 2016 16:07:59 -0500

Hi,

This version helps, and I will clear my DISCUSS. I assume Spencer will 
figure out the Right Thing to do to make sure the update to 5766 gets 
the right review.

I have a few minor comments on the resulting text. None of these are 
showstoppers:

- Absrtact: Please mention that this draft updates 5766 to relax the 
requirement for authentication in certain cases in the abstract.

- 9, 2nd paragraph, "Making STUN authentication OPTIONAL ..."

Since  you already used a 2119 MAY in the previous paragraph, there's no 
need for the 2119 OPTIONAL here. (In general, 2119 keywords should be 
used to state requirements, not talk about existing requirements)

-9, third paragraph:
I saw a comment on my DISCUSS email thread from Karl Stahl, stating that 
DTLS could not be mandated. Has that input been considered? (I don't 
have an opinion; I just want to make sure people noticed the comment.)

-9, 9th paragraph: "Instead, with an explicit administrator choice, a 
TURN client SHOULD fall-back to encryption-only (D)TLS when (D)TLS 
authentication is not available."
I’m not sure what SHOULD means after adding the explicit choice part. 
Does that means the administrator SHOULD make that choice? Is the point 
that you can fall back, but MUST NOT do so without explicit choice?

-9, 10th paragraph:
-- The first sentence is now redundant with the previous paragraph.
-- is the point of the first part of the second sentence that you MUST 
NOT fall back without explicit choice? (similar to for server 
authentication?)

On 11 Oct 2016, at 2:01, Tirumaleswar Reddy (tireddy) wrote:

> Hi Ben,
>
> Updated draft 
> https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-10 
> to address your comments, Please have a look.
>
> Thanks and Regards,
> -Tiru
>

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Fri, 14 Oct 2016 20:21:01 +0000

Thanks, Ben.
Inline..

On 10/11/16, 2:07 PM, "Ben Campbell" <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

This version helps, and I will clear my DISCUSS. I assume Spencer will figure out the Right Thing to do to make sure the update to 5766 gets the right review.

I have a few minor comments on the resulting text. None of these are showstoppers:

·         Absrtact: Please mention that this draft updates 5766 to relax the requirement for authentication in certain cases in the abstract.

·         9, 2nd paragraph, "Making STUN authentication OPTIONAL ..."

Since you already used a 2119 MAY in the previous paragraph, there's no need for the 2119 OPTIONAL here. (In general, 2119 keywords should be used to state requirements, not talk about existing requirements)

Agreed. Will update accordingly.

-9, third paragraph:
I saw a comment on my DISCUSS email thread from Karl Stahl, stating that DTLS could not be mandated. Has that input been considered? (I don't have an opinion; I just want to make sure people noticed the comment.)

Yes, I believe this has already been discussed. As suggested in the last paragraph of the section, not mandating DTLS opens up man-in-the-middle attacks and on-path packet injection.

-9, 9th paragraph: "Instead, with an explicit administrator choice, a TURN client SHOULD fall-back to encryption-only (D)TLS when (D)TLS authentication is not available."
I’m not sure what SHOULD means after adding the explicit choice part. Does that means the administrator SHOULD make that choice? Is the point that you can fall back, but MUST NOT do so without explicit choice?

It was the latter ie MUST NOT do so without explicit choice.

New text: “A TURN client could fall back to encryption-only (D)TLS when (D)TLS authentication is not available, but MUST NOT fall back without explicit administrator choice.”

-9, 10th paragraph:

Yes, will remove it.

-- is the point of the first part of the second sentence that you MUST NOT fall back without explicit choice? (similar to for server authentication?)

Yes, that was the intention. New text: “A TURN client could fall back to clear text if it does not support unauthenticated (D)TLS, but MUST NOT fall back without explicit administrator choice. Fallback to clear text is NOT RECOMMENDED because it makes the client more susceptible to man-in-the-middle attacks and on-path packet injection.”

-Prashanth

---

From: Karl Stahl <[email-masked]>
Date: Mon, 17 Oct 2016 10:14:59 +0200

Prashanth,

You have not addressed that (D)TLS cannot be mandated (as introduced during this discuss), which Ben asked about. See inline below.

Please also address the first point in https://www.ietf.org/mail-archive/web/tram/current/msg02191.html 

which has not been handled since first highlighted February 10 during version -06 of this draft.

Thanks,

Karl

Från: tram [mailto:[email-masked]] För Prashanth Patil (praspati)
Skickat: den 14 oktober 2016 22:21
Till: Ben Campbell; Tirumaleswar Reddy (tireddy)
Kopia: [email-masked]; Simon Perreault; [email-masked]; The IESG; [email-masked]
Ämne: Re: [tram] Ben Campbell's Discuss on draft-ietf-tram-turn-server-discovery-09: (with DISCUSS and COMMENT)

Thanks, Ben.

Inline.. 

On 10/11/16, 2:07 PM, "Ben Campbell" <[email-masked]> wrote:

Hi,

-9, third paragraph:

Yes, I believe this has already been discussed. 
[Karl] But the input has NOT BEEN CONSIDERED (Which is what Ben questions.) 
Please read https://www.ietf.org/mail-archive/web/tram/current/msg02191.html 
Throwing in the DTLS mandate has now (with the text in version -10 of the draft) destroyed this draft, making unusable for its main purpose.
 
As suggested in the last paragraph of the section, not mandating DTLS opens up man-in-the-middle attacks and on-path packet injection.
[Karl] With a network provided turn server, the turn client is seeking a better path for the real-time traffic than through the default gateway. You cannot put any higher requirements or ideas of protection on sending the real-time traffic to that network provided turn than to the default gateway.
 
And also:
 
[Karl] In  <https://www.ietf.org/mail-archive/web/tram/current/msg02191.html> https://www.ietf.org/mail-archive/web/tram/current/msg02191.html I pointed out:
It seem like it is forgotten that a protocol like WebRTC (which really needs this specification to finally deal with the old NAT/Firewall traversal problem that has been plaguing the real-time communication over the Internet for 15 years now), provides security and trust in itself for the media exchanged between endpoints – It does not have to be added by the TURN server. And specifically, for the network provided TURN server, where the purpose of the TURN server is to offer a better working path for the real-time media than through the default gateway (where media otherwise has to pass) – you cannot/must not expect that it also gives you some higher trust or security level that when it goes through the default gateway.
 
Please read complete  <https://www.ietf.org/mail-archive/web/tram/current/msg02191.html> https://www.ietf.org/mail-archive/web/tram/current/msg02191.html and address!

[Karl] This is also a showstopper making this draft unusable for its main purpose. Simply take it away. Again, is it really up to a discovery draft to specify usage?

-9, 10th paragraph:

Yes, will remove it.

[Karl] No, again see above and read complete https://www.ietf.org/mail-archive/web/tram/current/msg02191.html and address!

-Prashanth

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 18 Oct 2016 17:32:53 -0500

I'm replying to Ben's original Discuss here, although he has cleared and
there are multiple threads where I could be replying ...

After talking with Ben and the TRAM chairs, it looks like two issues came
up while resolving Ben's Discuss that seem appropriate for me to work
through at this point in the process.

First, the proposed resolution handles authentication in a way that assumes
deployment in some scenarios, but not others, and the TRAM working group
hasn't had an opportunity to look at the proposed resolution in this form
yet.

The working group needs to have rough consensus on a product of the working
group. So, I will ask the TRAM working group to review that change, in
discussion on the TRAM mailing list, and report back.

The discussion on the TRAM mailing list can start now.

Second, the proposed resolution added a significant update to a requirement
RFC 5766 placed on the use of authentication, and the broader community
hasn't had an opportunity to review that because it happened after Last
Call. Ben and I talked, and I think a second Last Call that draws attention
to the update will be appropriate.

I'll wait until the TRAM working group reports back to start that second
Last Call.

Conveniently, Terry Manderson still holds a Discuss for an issue that's
been resolved, but if Terry does clear his Discuss before we've finished
the two steps I listed above, I'll ballot a Discuss for the reasons listed
in this email, to hold the document in IESG Evaluation.

Thanks, all, for your input, and we'll work through this, too.

Spencer, as responsible Area Director