During ART-ART and IESG review of draft-ietf-tram-stunbis, we realized that just pointing to RFC 7525 might not be enough anymore, now that the TLS 1.3 spec has been approved for publication. 7525bis, anyone?
Peter -------- Forwarded Message -------- Subject: Re: Artart telechat review of draft-ietf-tram-stunbis-16 Date: Tue, 17 Apr 2018 09:11:28 -0600 From: Peter Saint-Andre <stpe...@mozilla.com> To: Marc Petit-Huguenin <petit...@acm.org>, Eric Rescorla <e...@rtfm.com> CC: a...@ietf.org, draft-ietf-tram-stunbis....@ietf.org, IETF discussion list <i...@ietf.org>, t...@ietf.org On 4/17/18 4:02 AM, Marc Petit-Huguenin wrote: > > On 04/16/2018 08:12 PM, Eric Rescorla wrote: >> On Mon, Apr 16, 2018 at 5:22 PM, Peter Saint-Andre <stpe...@mozilla.com> >> 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. >>> >> >> I forgot about this in my review, but you should also profile ciphers for >> TLS 1.3. >> >> -Ekr >> > > Do you have any suggestion for these, or a pointer to a document that I can > use to find these? Off-topic: it sounds like we might need to start work on 7525bis... Peter
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
