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

Julien ÉLIE <julien@trigofacile.com> Tue, 17 April 2018 19:51 UTC

Return-Path: <julien@trigofacile.com>
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 7F13E12D878 for <art@ietfa.amsl.com>; Tue, 17 Apr 2018 12:51:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level:
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, 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 p-X1GX_IyBCt for <art@ietfa.amsl.com>; Tue, 17 Apr 2018 12:51:29 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp12.smtpout.orange.fr [80.12.242.134]) by ietfa.amsl.com (Postfix) with ESMTP id B3A24126D73 for <art@ietf.org>; Tue, 17 Apr 2018 12:51:28 -0700 (PDT)
Received: from macbook-pro-de-julien-elie.home ([81.249.206.57]) by mwinf5d23 with ME id bXjv1x00T1Eq75t03XjwVE; Tue, 17 Apr 2018 21:43:57 +0200
X-ME-Helo: macbook-pro-de-julien-elie.home
X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg==
X-ME-Date: Tue, 17 Apr 2018 21:43:57 +0200
X-ME-IP: 81.249.206.57
To: Marc Petit-Huguenin <marc@petit-huguenin.org>
Cc: art@ietf.org, 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>
From: Julien ÉLIE <julien@trigofacile.com>
Organization: TrigoFACILE -- http://www.trigofacile.com/
Message-ID: <3216f82e-ea12-6459-4ce2-42dc38b86e9f@trigofacile.com>
Date: Tue, 17 Apr 2018 21:43:55 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; 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: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/41R54AlV7I2vGOPiPS8ISdn1Yss>
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: Tue, 17 Apr 2018 19:51:31 -0000

Hi Marc,
>>> 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.

If you're going to add some wording about including TLS best current 
practices, maybe you could re-use what we came up with during final RFC 
edition of RFC 8143 <https://tools.ietf.org/html/rfc8143>:

3.  Recommendations

    The best current practices documented in [BCP195] apply here.
    Therefore, NNTP implementations and deployments compliant with this
    document are REQUIRED to comply with [BCP195] as well.

    Instead of repeating those recommendations here, this document mostly
    provides supplementary information regarding secure implementation
    and deployment of NNTP technologies.


Notably, the RFC Editor prefers referencing RFC 7525 as BCP 195 even 
though there currently is only one RFC in this BCP series.  As other 
RFCs may be added in BCP 195, and we want to follow all best practices 
that apply, the reference should be the BCP series.

-- 
Julien ÉLIE

« – C'est joli cette avenue le long de la mer… Ça s'appelle
     comment ?
   – La promenade des Bretons. » (Astérix)