Hi Peter, Thanks for the review and sorry for the delay in responding, I was traveling for the last 4 weeks. See my responses inline. On 04/02/2018 03:59 PM, Peter Saint-Andre wrote: > Reviewer: Peter Saint-Andre > Review result: Ready with Nits > > Section 1 states: > > Implementations and deployments of a STUN usage using TLS or DTLS > should follow the recommendations in [RFC7525]. > > Wouldn't the security considerations be a better location for that text? Moved there. > > And given that this specification cites RFC 8174, I suggest changing > "should" to "SHOULD". Done. > > (I suggest that the authors review the usage of lowercase and uppercase > requirements keywords, because there might be inconsistencies, e.g., in > the first paragraphs of Section 6.1 and Section 6.2.) These sections are identical to RFC 5389 and so I am reluctant to modify them as they already went through an IESG review. I reviewed the lowercase keywords in these two sections and did not find any specific case that would create an interoperability issue, but please let me know if you think otherwise. > > In Section 4, please consider spelling out "SIP" on first use and > including a reference to RFC 3261. Done. > > The first paragaraph of Section 6.2.3 restates recommendations from RFC > 7525; why not simply reference that specification? The original text in RFC5389 said this: " When STUN is run by itself over TLS-over-TCP, the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be implemented at a minimum. [...]" The new text is an attempt at updating it in the same spirit of giving minimal instructions and complementing them with a reference to RFC 7525 - which was the reason for the reference to RFC 7525 there. So I kept the text there, followed by the following paragraph, in addition of moving the original last paragraph in the Security Consideration section: " These recommendations are just a part of the the recommendations in [RFC7525] that implementations and deployments of a STUN usage using TLS or DTLS SHOULD follow." > > Section 6.3.4 states: > > o If the error code is 500 through 599, the client MAY resend the > request; clients that do so MUST limit the number of times they do > this. > > It is reasonable to provide guidance as to the number of re-sends? Same issue here, that's a section that is unmodified from RFC 5389. As long as the client does not enter an endless loop of retransmission, choosing different numbers of re-sends does not affect interoperability. > > Section 9.1.1 and other sections invoke the OpaqueString profile of the > PRECIS FreeformClass; it might be helpful to mention that the profile is > used to handle Unicode characters outside the ASCII range, and that no > changes result if only ASCII characters are used. Hmm. But in that case the application has first to test that the string is in the ASCII range. Isn't that better to always assume that the input string will contain Unicode, and let the implementation of OpaqueString short-circuit the processing in the case of an all-ASCII string? > > In Section 14.2, please consider spelling out "ALG" on first use. Done. > > A reference to RFC 6151 seems appropriate regarding the fact that this > specification retains the use of MD5; in particular, the usage here is > actually HMAC-MD5, which is still sanctioned by RFC 6151. > Done. -- Marc Petit-Huguenin Email: marc@xxxxxxxxxxxxxxxxxx Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug
Attachment:
signature.asc
Description: OpenPGP digital signature
