Re: [tram] Artart telechat review of draft-ietf-tram-stunbis-16

[Peter Saint-Andre <[e-mail]>]

Hi Marc, a few further comments inline.

On 4/16/18 5:43 PM, Marc Petit-Huguenin wrote:
> 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
>>

<snip/>

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

I would instead suggest that we do something like Section 2 of RFC 7590
for XMPP:

   The best current practices documented in the "Recommendations for
   Secure Use of TLS and DTLS" [RFC7525] are included here by reference.
   Instead of repeating those recommendations here, this document mostly
   provides supplementary information regarding secure implementation
   and deployment of XMPP technologies.

Here's the rationale: RFC 7525 is likely to be updated/replaced more
quickly than STUNbis. If STUNbis recommends a particular cipher suite
that 7525bis stops recommending, in the absence of STUNter will STUN
implementations keep following STUNbis or will they upgrade to whatever
7525bis recommends? I suggest it will be the former, which is not what
we want.

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

I understand. Now is our chance to fix it. :-)

>  As long as the client does not enter an endless loop of retransmission, choosing different numbers of re-sends does not affect interoperability.

Choosing different numbers is OK, but choosing an infinite number is
not. Can we provide guidance as to how many is too many? 10? 50? 100?

>> 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?

Yes, I meant that as an informational note to implementers so they would
worry less. But it's not necessary and I think you can safely ignore it.

Peter