Hi Ben, Please see inline > -----Original Message----- > From: Benjamin Kaduk <kaduk@xxxxxxx> > Sent: Saturday, July 13, 2019 7:19 AM > To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@xxxxxxxxxx> > Cc: Christopher Wood <caw@xxxxxxxxxxxxxxx>; secdir@xxxxxxxx; draft-ietf- > tram-turnbis.all@xxxxxxxx; ietf@xxxxxxxx; tram@xxxxxxxx > Subject: Re: [tram] Secdir last call review of draft-ietf-tram-turnbis-27 > > 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, > > Thanks for all the updates, including further downthread with Chris. > Just a couple notes inline... > > On Wed, Jul 10, 2019 at 12:40:37PM +0000, Konda, Tirumaleswar Reddy wrote: > > Hi Ben, > > > > Thanks for the review. Please see inline. > > > > > -----Original Message----- > > > From: Benjamin Kaduk <kaduk@xxxxxxx> > > > Sent: Wednesday, July 10, 2019 2:01 AM > > > To: Konda, Tirumaleswar Reddy > <TirumaleswarReddy_Konda@xxxxxxxxxx> > > > Cc: Christopher Wood <caw@xxxxxxxxxxxxxxx>; secdir@xxxxxxxx; > > > draft-ietf- tram-turnbis.all@xxxxxxxx; ietf@xxxxxxxx; tram@xxxxxxxx > > > Subject: Re: [tram] Secdir last call review of > > > draft-ietf-tram-turnbis-27 > > > > > > 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. > > > > > > Chris, thanks for the review. Some more questions/comments inline > > > as I prepare to ballot on this document... > > > > > > On Mon, Jul 08, 2019 at 02:18:26PM +0000, Konda, Tirumaleswar Reddy > wrote: > > > > Hi Christopher, > > > > > > > > Thanks for the detailed review. Please see inline > > > > > > > > > -----Original Message----- > > > > > From: tram <tram-bounces@xxxxxxxx> On Behalf Of Christopher > Wood > > > > > via Datatracker > > > > > Sent: Monday, July 8, 2019 1:59 AM > > > > > To: secdir@xxxxxxxx > > > > > Cc: draft-ietf-tram-turnbis.all@xxxxxxxx; ietf@xxxxxxxx; > > > > > tram@xxxxxxxx > > > > > Subject: [tram] Secdir last call review of > > > > > draft-ietf-tram-turnbis-27 > > > > > > > > > > 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. > > > > > > > > > > Reviewer: Christopher Wood > > > > > Review result: Has Nits > > > > > > > > > > I have reviewed this document as part of the security > > > > > directorate's ongoing effort to review all IETF documents being > > > > > processed by the IESG. These comments were written primarily for > > > > > the benefit of the security area directors. > > > > > Document editors and WG chairs should treat these comments just > > > > > like any other last call comments. > > > > > > > > > > The summary of the review is: Ready with nits > > > > > > > > > > Summary: > > > > > > > > > > In general, the document is well written and clearly founded in > > > > > operational experience. The security considerations are > > > > > thorough, providing examples where necessary to highlight > > > > > important problem areas. It draws a clear line between issues > > > > > best addressed by applications outside of TURN, and provides > > > > > sufficient detail for those issues in scope. My comments and > > > > > questions are, hopefully, mostly > > > nits. > > > > > > > > > > General comments: > > > > > > > > > > - TURN server authentication in the case of (D)TLS is > > > > > underspecified. Are servers assumed to have WebPKI certificates, > > > > > OOB-trusted raw public keys, or something else? Is there a > > > > > preferred > > > form of authentication? > > > > > Relatedly, in > > > > > Section 3.2, how do clients authenticate the server? > > > > > > > > Server certificate validation is discussed in > > > > https://tools.ietf.org/html/draft- > > > ietf-tram-stunbis-21#section-6.2.3. I have modified the text as follows: > > > > > > > > If (D)TLS transport is used between the TURN client and the TURN > > > > server, the cipher suites, server certificate validation and > > > > authentication of TURN server are discussed in Section 6.2.3 of > > > > [I-D.ietf-tram-stunbis] > > > > > > That helps, but it would still be nice to give some indication of > > > what certificate > > > PKI(s) are expected to be used. Is anything other than the Web PKI > > > under consideration ? > > > > No. Please see https://tools.ietf.org/html/draft-ietf-tram-stunbis- > 21#section-6.2.3, It discusses to verify the certificate path and identity of the > server. > > > > > > > > > >- Section 3.7: Could > > > > > TURN servers not chunk data from stream-oriented transports (TCP > > > > >or > > > > >TLS) to a preferred MTU size before relaying to peers? > > > > > Specifically, there are likely > > > > > some cases wherein the server could deal with the client data > > > > >messages larger than the recommended 500B limit. On that point, > > > > >should servers even accept data larger than this recommended size ? > > > > >- > > > > > > > > Please see > > > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-27#section-15 > > > > for TCP-to-UDP relay. If the PMTU is not known, and on legacy or > > > > otherwise unusual networks, > > > > 500 byte limit for application data is recommended. > > > > > > > > > Section 3.9: There may be > > > > > cases where the TLS connection post TCP connection establishment > > > > > fails. It would therefore seems prudent to not declare victory > > > > > for one connection over the other until TLS connects, too. - > > > > > > > > Agreed, Eric (as part of ISEG review) suggested to simplify the > > > > text. I have > > > updated the text as follows: > > > > > > > > o For TCP or TLS-over-TCP, the results of the Happy Eyeballs > > > > procedure [RFC8305] are used by the TURN client for sending its > > > > TURN messages to the server. > > > > > > Is the editor's copy available for viewing somewhere? It would be > > > good to see this (and other changes) in context. > > > > Yes, Please see https://github.com/tireddy2/TURNbis > > > > > > > > > > Section 3 could benefit from a > > > > > subsection on replays and the nonce role. In particular, as > > > > > later discussed in the security considerations, some of these > > > > > attacks are not new to TURN and should therefore be dealt with > > > > > by the application protocol (SRTP). This section might also > > > > > describe nonce rotation policies with more specificity, as this > > > > > is underspecified in the > > > document. > > > > > > > > It is discussed in Section 5 in the specification, the server > > > > should expire the > > > nonce at least once every hour during the lifetime of the allocation. > > > > > > > > >- Section 3 could also benefit from discussion about cleartext > > > > >versus encryption transports between clients and servers. > > > > > > > > It is discussed in > > > > https://tools.ietf.org/html/draft-ietf-tram-turnbis- > > > 27#section-21.1.6. > > > > > > There's not much discussion about potential information leakage via > > > (e.g.) USERNAME/USERHASH, and really just a claim that the peer > > > address is the "primary protocol content". > > > > Agreed, added the following paragraph : > > > > If the TURN client and server use the STUN Extension for Third-Party > > Authorization [RFC7635], the username does not reveal the real user's > identity, the USERNAME attribute carries an ephemeral and unique key > identifier, and the key identifier can change per call. > > If the TURN client and server use the STUN long-term credential > > mechanism and the username reveals the real user's identity, the > > client need to either use (D)TLS transport between the client and the > server or use the USERHASH attribute instead of the USERNAME attribute to > anonynmize the username. > > > > > > > > > > Encrypting the nonce, username, realm, etc., among other things, > > > > > has obvious benefits. - Why are SOFTWARE and FINGERPRINT > > > > > attributes recommended? It seems like clients should be > > > > > discouraged from sending these if anything, especially if not > > > > > used to make allocation decisions on the server. > > > > > > > > Username may not be the user identity, Please see > > > https://tools.ietf.org/html/rfc7635), It could be an ephemeral and > > > unique key identifier. Further, username can be anonymized (please > > > see https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-14.4). > > > > SOFTWARE and FINGERPRINT attributes are defined in the STUN > > > specification, see https://tools.ietf.org/html/draft-ietf-tram-stunbis-21. > > > > > > These mechanisms are partial mitigations but can still be > > > susceptible to cross- connection correlation attacks. > > > > The use of FINGERPRINT is not mandatory, the TURN client and server may > include the FINGERPRINT attribute. Note that ICE > (https://tools.ietf.org/html/rfc8445) mandates the use of FINGERPRINT > attribute. Added the following line for SOFTWARE attribute (TURNbis is using > the same behavior defined in RFC5766 to use SOFTWARE attribute) : > > > > SOFWATE 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. > > The later suggestion was: > > % We want to avoid double encryption of application data, and SOFTWARE > attribute has > % been sent in clear text all these years in the field, and no attack has been > % detected based on SOFTWARE field. I can revise the text as follows: > % If the software version is known to contain security vulnerabilities, TURN > SHOULD be % run over (D)TLS to prevent leaking the SOFTWARE attribute in > clear text. > > I think some of the concern is over the risk of so-called "zero-day" > exploits, where the attacker knows of a version-specific flaw but the > defenders do not (and have zero days notice to protect against it). Such a > concern would suggest to avoid sending SOFTWARE over enencrypted > transport regardless of the state of known vulnerabilities, but in the end it is > a matter of local policy. Agreed, fixing and releasing a patch will take some time and meanwhile the policy can be modified to use temporarily use (D)TLS. I can add the following text: If zero-day vulnerabilities are detected in the software version, the endpoint policy can be modified to mandate the use of (D)TLS till the patch is in place to fix the flaw. > > > > > > > > > > > - Section 5: When servers receive data that exceeds an > > > > allocation’s > > > > > bandwidth quota, servers silently discard this data. This means > > > > > there’s no allocation-based flow control mechanism between > > > > > client and server beyond what’s provided by the transport protocol, > right? > > > > > > > > Yes, UDP does not include a congestion control mechanism. > > > > > > > > > This seems fine, though > > > > > perhaps some discussion of why this design decision was made > > > > > would be helpful. For example, I could imagine explicit signals > > > > > from servers to clients that indicate server state would reveal > > > > > information about other allocations on the server, which might > > > > > be problematic. - > > > > > > > > The errors 486 (Allocation Quota Exceeded) or 508 (Insufficient > > > > Capacity) > > > do not reveal information of which other users are using the TURN server. > > > > > > At least the latter seems to give some indication that many other > > > users are using the server at the time (so that it's overloaded), > > > though not information about *which* users that is. > > > > Yes, similar to 503 HTTP error response. > > > > > > > > > > Section 7.2 suggests that > > > > > servers can redirect client allocation requests to other servers. > > > > > Can this create a loop, wherein two TURN servers redirect to one > another? > > > > > > > > The client detect and stop the loop, it is similar to HTTP redirection. > > > > > > Where is this specified? > > > > It is specified in the last paragraph of > > https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-10 > > > > <snip> > > If the client has been redirected to a server to which it has already > > sent this request within the last five minutes, it MUST ignore the > > redirection and consider the transaction to have failed. This > > prevents infinite ping-ponging between servers in case of redirection > > loops. > > </snip> > > Thanks for the pointer; as you saw in my ballot position I was quite pressed > for time this week and only was able to look at the diff. No problem, thanks for help. Cheers, -Tiru > > -Ben
