Re: [art] Artart telechat review of draft-ietf-tram-stunbis-16
Marc Petit-Huguenin <marc@petit-huguenin.org> Sat, 21 April 2018 21:39 UTC
Return-Path: <marc@petit-huguenin.org>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3365F12E8D7; Sat, 21 Apr 2018 14:39:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level:
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2_VXDnAAaUQ; Sat, 21 Apr 2018 14:39:33 -0700 (PDT)
Received: from implementers.org (unknown [IPv6:2001:4b98:dc0:45:216:3eff:fe7f:7abd]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DD8012E8D4; Sat, 21 Apr 2018 14:39:33 -0700 (PDT)
Received: from [IPv6:2601:648:8301:730f:3134:3153:e7ee:f8f7] (unknown [IPv6:2601:648:8301:730f:3134:3153:e7ee:f8f7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id CE8D3AE844; Sat, 21 Apr 2018 23:39:29 +0200 (CEST)
From: Marc Petit-Huguenin <marc@petit-huguenin.org>
To: Peter Saint-Andre <stpeter@mozilla.com>, art@ietf.org
Cc: draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org
References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> <ec1d7013-4886-6f96-21a2-3c758fc633cf@petit-huguenin.org> <c6df754b-8aea-637c-a8bf-7ccadc0d8704@mozilla.com> <6422219a-5c2d-4590-3088-0f1afa3feb8f@petit-huguenin.org>
Message-ID: <00ddbc05-2a96-d77e-f260-7d0b3c0f4074@petit-huguenin.org>
Date: Sat, 21 Apr 2018 14:39:28 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <6422219a-5c2d-4590-3088-0f1afa3feb8f@petit-huguenin.org>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="s98ikjH5z0Zsqqs2k3YOVMmKQGsTBjEp5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/ysSqjYoEQ6egHxjCvGtmfRCoWI8>
Subject: Re: [art] Artart telechat review of draft-ietf-tram-stunbis-16
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Apr 2018 21:39:35 -0000
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@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug
- [art] Artart telechat review of draft-ietf-tram-s… Peter Saint-Andre
- Re: [art] Artart telechat review of draft-ietf-tr… Marc Petit-Huguenin
- Re: [art] Artart telechat review of draft-ietf-tr… Peter Saint-Andre
- Re: [art] Artart telechat review of draft-ietf-tr… Eric Rescorla
- Re: [art] Artart telechat review of draft-ietf-tr… Marc Petit-Huguenin
- Re: [art] Artart telechat review of draft-ietf-tr… Marc Petit-Huguenin
- Re: [art] Artart telechat review of draft-ietf-tr… Peter Saint-Andre
- Re: [art] Artart telechat review of draft-ietf-tr… Julien ÉLIE
- Re: [art] Artart telechat review of draft-ietf-tr… Marc Petit-Huguenin
- Re: [art] [tram] Artart telechat review of draft-… Marc Petit-Huguenin
- Re: [art] [tram] Artart telechat review of draft-… Marc Petit-Huguenin
- Re: [art] Artart telechat review of draft-ietf-tr… Peter Saint-Andre
- Re: [art] [tram] Artart telechat review of draft-… Marc Petit-Huguenin