Re: [tram] Roman Danyliw's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT)

[Roman Danyliw <[e-mail]>]

Hi Tiru!

This proposed -28 addresses all of my concerns.  Thank you for the update.

Roman

> -----Original Message-----
> From: Konda, Tirumaleswar Reddy
> [mailto:[e-mail]]
> Sent: Wednesday, July 17, 2019 8:34 AM
> To: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: RE: [tram] Roman Danyliw's Discuss on draft-ietf-tram-turnbis-27:
> (with DISCUSS and COMMENT)
> 
> Hi Roman,
> 
> I have updated the draft to address your Discuss and comments (see
> https://github.com/tireddy2/TURNbis/blob/master/Diff%20%20draft-ietf-
> tram-turnbis-27.txt%20-%20draft-ietf-tram-turnbis-28.pdf).
> Please have a look.
> 
> Cheers,
> -Tiru
> 
> > -----Original Message-----
> > From: Konda, Tirumaleswar Reddy
> > Sent: Friday, July 12, 2019 2:43 PM
> > To: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>
> > Cc: [e-mail]; [e-mail];
> > [e-mail]; [e-mail]
> > Subject: RE: [tram] Roman Danyliw's Discuss on draft-ietf-tram-turnbis-27:
> > (with DISCUSS and COMMENT)
> >
> > Hi Roman,
> >
> > Please see inline
> >
> > > -----Original Message-----
> > > From: Roman Danyliw <[e-mail]>
> > > Sent: Friday, July 12, 2019 7:00 AM
> > > To: Konda, Tirumaleswar Reddy
> > > <[e-mail]>; The IESG <[e-mail]>
> > > Cc: [e-mail]; [e-mail];
> > > [e-mail]; [e-mail]
> > > Subject: RE: [tram] Roman Danyliw's Discuss on draft-ietf-tram-turnbis-
> 27:
> > > (with DISCUSS and COMMENT)
> > >
> > > This email originated from outside of the organization. Do not click
> > > links or open attachments unless you recognize the sender and know
> > > the content is safe.
> > >
> > > Hi Tiru!
> > >
> > > > -----Original Message-----
> > > > From: iesg [mailto:[e-mail]] On Behalf Of Konda,
> > > > Tirumaleswar Reddy
> > > > Sent: Thursday, July 11, 2019 5:07 AM
> > > > To: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>
> > > > Cc: [e-mail]; [e-mail];
> > > > [e-mail]; [e-mail]
> > > > Subject: RE: [tram] Roman Danyliw's Discuss on draft-ietf-tram-turnbis-
> 27:
> > > > (with DISCUSS and COMMENT)
> > > >
> > > > Hi Roman,
> > > >
> > > > Thanks for the review. Please see inline
> > > >
> > > > > -----Original Message-----
> > > > > From: tram <[e-mail]> On Behalf Of Roman Danyliw
> > > > > via Datatracker
> > > > > Sent: Thursday, July 11, 2019 4:20 AM
> > > > > To: The IESG <[e-mail]>
> > > > > Cc: [e-mail]; [e-mail];
> > > > > [e-mail]; [e-mail]
> > > > > Subject: [tram] Roman Danyliw's Discuss on draft-ietf-tram-turnbis-
> 27:
> > > > > (with DISCUSS and COMMENT)
> > > > >
> > > > > This email originated from outside of the organization. Do not
> > > > > click links or open attachments unless you recognize the sender
> > > > > and know the content is safe.
> > > > >
> > > > > Roman Danyliw has entered the following ballot position for
> > > > > draft-ietf-tram-turnbis-27: Discuss
> > > > >
> > > > > 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-tram-turnbis/
> > > > >
> > > > >
> > > > >
> > > > > ----------------------------------------------------------------
> > > > > --
> > > > > --
> > > > > --
> > > > > DISCUSS:
> > > > > ----------------------------------------------------------------
> > > > > --
> > > > > --
> > > > > --
> > > > >
> > > > > (1) Section 12.1.6.  (Per the back-and-forth on Chris Wood’s
> > > > > SECDIR review – thank you Chris!) Per “Confidentiality is only a
> > > > > secondary concern, as TURN control messages do not include
> > > > > information that is particularly sensitive”, wouldn’t the
> > > > > USERNAME and REALM potentially be privacy sensitive?  If they
> > > > > aren’t sensitive in all cases (e.g., usernames might be
> > > > > ephemeral), this should
> > be noted and cited.
> > > >
> > > > Agreed, added the following paragraph:
> > > >
> > > >    If the TURN client and server use the STUN Extension for Third-Party
> > > >    Authorization [RFC7635] (for example it is used in WebRTC), the
> > > >    username does not reveal the real user's identity, the USERNAME
> > > >    attribute carries an ephemeral and unique key identifier.  If the
> > > >    TURN client and server use the STUN long-term credential mechanism
> > > >    and the username reveals the real user's identity, the client needs
> > > >    to use (D)TLS transport between the client and the server or use the
> > > >    USERHASH attribute instead of the USERNAME attribute to
> anonynmize
> > > >    the username.
> > > >
> > > >    If the TURN client and server use the STUN long-term credential
> > > >    mechanism and realm information is privacy sensitive, TURN can be
> run
> > > >    over (D)TLS.  As a reminder, STUN Extension for Third-Party
> > > >    Authorization does not use realm.
> > >
> > > Thank you.  This text would address my concern.
> > >
> > > > > ----------------------------------------------------------------
> > > > > --
> > > > > --
> > > > > --
> > > > > COMMENT:
> > > > > ----------------------------------------------------------------
> > > > > --
> > > > > --
> > > > > --
> > > > >
> > > > > (2) This draft relies on the draft-ietf-tram-stunbis’s STUN
> > > > > Password Algo Registry which has MD5 and SHA-256.  Section
> > > > > 16.1.1 of that draft already discusses the limitation of SHA-256
> > > > > (which it might be useful to
> > > > reference).
> > > > > Nevertheless, are there cases where MD5 should be used over
> > > > > SHA-256 if there is a choice?  Is there a reason not to
> > > > > recommend that implementations “SHOULD NOT use MD5”?
> > > >
> > > > The only reason draft-ietf-tram-stunbis retained MD5 is for
> > > > backward- compatibility (client using older version of STUN (RFC5389)).
> > >
> > > Understood.  Could we say something on the order of "if a client
> > > supports both MD5 and SHA-256, the latter SHOULD BE used"?
> >
> > Yes, modified the above text as follows:
> >
> > Note that if the response contains a PASSWORD-ALGORITHMS attribute
> and
> > this attribute contains both MD5 and SHA-256 algorithms, and the
> > client also supports both the algorithms, the request MUST contain a
> > PASSWORD- ALGORITHM attribute with the SHA-256 algorithm.
> >
> > Cheers,
> > -Tiru
> >
> > >
> > > > >
> > > > > (3) Section 5. Per “The client SHOULD include the SOFTWARE …”
> > > > > and “The client and the server MAY include the FINGERPRINT
> > > > > attribute …”, why is the sending of SOFTWARE not a “MAY” too?
> > > >
> > > > This same behavior is defined in RFC5766 and turnbis does not
> > > > modify the behavior, and to address the comment from Chris Wood
> > > > (Secdir
> > > > review) added the following line to Security Considerations section:
> > > >
> > > > SOFTWARE attribute can reveal the specific software version of the
> > > > TURN client and server to eavesdropper and it might possibly allow
> > > > attacks against vulnerable software that is known to contain
> > > > security holes. If it is important to prevent an eavesdropper from
> > > > learning the software version, TURN can be run over (D)TLS.
> > >
> > > Understood.  I can live with an argument that turnbis shouldn't
> > > modify the behavior in this case given this additional (helpful) language.
> Thanks.
> > >
> > > > >
> > > > > (4) Section 5.  (Per the back-and-forth on Chris Wood’s SECDIR
> > > > > review) Recommend citing Section 6.3.1 of
> > > > > [draft-ietf-tram-stunbis] as source of 40 second request buffer
> > > > > timeout
> > > >
> > > > Done.
> > >
> > > Thanks.
> > >
> > > > >
> > > > > (5) Section 21.4.  Per “It is RECOMMENDED that TURN servers not
> > > > > accept allocation or channel binding requests from addresses
> > > > > known to be tunneled”, I concur with the advice.  How would one
> > > > > recognize that the address is being tunneled?
> > > >
> > > > By managing drop-list of tunnel IP addresses, it is the same
> > > > technique used by several websites to block VPN access (see
> > > > https://www.howtogeek.com/403771/why-do-some-websites-block-
> > > vpns/)
> > >
> > > Right.  I didn't know if there was something fancier I was missing.
> > >
> > > I appreciate these changes and explanations!
> > >
> > > Roman
> > >
> > >
> > > > Cheers,
> > > > -Tiru
> > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > tram mailing list
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/tram