Re: [tram] I-D Action: draft-ietf-tram-turn-server-discovery-11.txt

Hi Tiru,

You said> This revision addresses comments received from Ben during ISEG
review

--- Not really - The (D)TLS mandating was Author's idea to throw into
version -10 during the discuss and remains in this version -11, breaking the
consensus text since version -7.

--- And do you remember Ben's:
Från: tram [mailto:tram-bounces@ietf.org] För Ben Campbell
Skickat: den 11 oktober 2016 23:08
Till: Tirumaleswar Reddy
Kopia: Prashanth Patil; tram-chairs@ietf.org; tram@ietf.org;
draft-ietf-tram-turn-server-discovery@ietf.org; Simon Perreault; The IESG
Ämne: Re: [tram] Ben Campbell's Discuss on
draft-ietf-tram-turn-server-discovery-09: (with DISCUSS and COMMENT)
...
"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.)"

Let's get this done in connection with next email "[tram] Maybe we have
(D)TLS consensus; WAS: draft-ietf-tram-turn-server-discovery" thread, in the
connection with the technical discussion you brought up again.

I have another question relating to what Author's have in mind regarding the
"explicit administrator choice" in the text under 9 Security Considerations:

"In some auto-discovery scenarios, it might not be possible for the
   TURN client to use (D)TLS authentication to validate the TURN server.
   However, fall-back to clear text in such cases could leave the TURN
   client open to on-path injection of spoofed TURN messages.  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.  Another reason to fall-back to
   encryption-only is for privacy, which is analogous to SMTP
   opportunistic encryption [RFC7435] where one does not require privacy
   but one desires privacy when possible.

   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."

If this should be applicable to TURN servers provided by the local or access
network, do you mean
- There is some (static) configuration to be done e.g. in the WebRTC browser

OR
- The network administrator stands behind the WebRTC browser user and pushes
some button on the screen that the TURN client somehow puts as a choice on
the user's screen
OR
- ???

And should whatever is meant happen at the enterprise LAN and also at the
Internet Café and at the Airport free WiFi? 

Now that Author's in this -11 draft have put in these two MUST NOT instead
of SHOULD, such text cannot be ignored anymore.
And please understand: This is a DISCOVERY draft - We simply cannot have
MUST statements relating to the USAGE of TURN servers. That must be left to
other drafts, understanding the use case and requirements, like the RETURN
draft for WebRTC TURN clients usage of the discovered TURN server.

More technical in next email...
And if we can agree on what is said there, cannot all of this (which is very
hard to understand, even if I try) be removed?

/Karl

-----Ursprungligt meddelande-----
Från: tram [mailto:tram-bounces@ietf.org] För Tirumaleswar Reddy (tireddy)
Skickat: den 15 december 2016 07:19
Till: tram@ietf.org
Ämne: Re: [tram] I-D Action: draft-ietf-tram-turn-server-discovery-11.txt

This revision addresses comments received from Ben during ISEG review.

-Tiru

> -----Original Message-----
> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet-
> drafts@ietf.org
> Sent: Thursday, December 15, 2016 11:47 AM
> To: i-d-announce@ietf.org
> Cc: tram@ietf.org
> Subject: [tram] I-D Action: draft-ietf-tram-turn-server-discovery-11.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the TURN Revised and Modernized of the IETF.
> 
>         Title           : TURN Server Auto Discovery
>         Authors         : Prashanth Patil
>                           Tirumaleswar Reddy
>                           Dan Wing
> 	Filename        : draft-ietf-tram-turn-server-discovery-11.txt
> 	Pages           : 15
> 	Date            : 2016-12-14
> 
> Abstract:
>    Current Traversal Using Relays around NAT (TURN) server discovery
>    mechanisms are relatively static and limited to explicit
>    configuration.  These are usually under the administrative control of
>    the application or TURN service provider, and not the enterprise,
>    ISP, or the network in which the client is located.  Enterprises and
>    ISPs wishing to provide their own TURN servers need auto discovery
>    mechanisms that a TURN client could use with no or minimal
>    configuration.  This document describes three such mechanisms for
>    TURN server discovery.
> 
>    This draft updates [RFC5766] to relax the requirement for mutual
>    authentication in certain cases.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-server-discovery/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-11
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-server-discovery-11
> 
> 
> 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/
> 
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram