On 04/17/2018 03:00 AM, Marc Petit-Huguenin wrote:
> On 04/16/2018 05:22 PM, Peter Saint-Andre wrote:
>> 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.
>
> All right, makes sense. I'll add something like this on my next round of reviews, most likely this Friday.
Done, see my other emails to Julien Élie and Ekr.
>
>>
>>>> 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?
>
> Well, the text already states that an infinite number of of re-sends is not compliant. Anyway, I am not sure how to determine a reasonable number, but I'll try.
I chose 4 as the maximum number of retransmissions. I based that on error code 508 in TURN that defines a delay of 60 seconds between retransmissions, so we now get a delay of 5 minutes before the client gives up in case of insufficient capacity. The new text reads like this:
"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. Unless a specific error code specifies a different value,
the number of retransmissions MUST be limited to 4."
--
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
