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

Marc Petit-Huguenin <petithug@acm.org> Sat, 21 April 2018 21:02 UTC

Return-Path: <petithug@acm.org>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC7B12DA12; Sat, 21 Apr 2018 14:02:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.441
X-Spam-Level:
X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, 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 odj9VI5Hz6Zg; Sat, 21 Apr 2018 14:02:54 -0700 (PDT)
Received: from implementers.org (unknown [92.243.22.217]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 328811242F5; Sat, 21 Apr 2018 14:02:54 -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 A6853AE844; Sat, 21 Apr 2018 23:02:50 +0200 (CEST)
To: =?UTF-8?Q?Julien_=c3=89LIE?= <julien@trigofacile.com>
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> <3216f82e-ea12-6459-4ce2-42dc38b86e9f@trigofacile.com>
From: Marc Petit-Huguenin <petithug@acm.org>
Message-ID: <ccab17ed-f5c6-2fca-1249-c47db36cf118@acm.org>
Date: Sat, 21 Apr 2018 14:02:48 -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: <3216f82e-ea12-6459-4ce2-42dc38b86e9f@trigofacile.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uveg8IQlS7aDvv6qn8mVKtqgZcmr5zzAw"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/epX9nmNpChup8GrkrW9K3X_PYr4>
Subject: Re: [tram] [art] Artart telechat review of draft-ietf-tram-stunbis-16
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Apr 2018 21:02:57 -0000

On 04/17/2018 12:43 PM, Julien ÉLIE wrote:
> 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.
> 

Thanks, I used the BCP as reference, and changed the SHOULD to MUST.

-- 
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug