On 17/04/18 16:22, Peter Saint-Andre wrote: > 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?
I also think it's a bit early, but no harm to start the work, as long as it's not rushed. I'd say it'll be a while before e.g. we see some of the 0rtt car-crashes that it'd be good to advise against;-) S. > > 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 <[email protected]> > To: Marc Petit-Huguenin <[email protected]>, Eric Rescorla <[email protected]> > CC: [email protected], [email protected], IETF discussion > list <[email protected]>, [email protected] > > 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 <[email protected]> >>> 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 > > > > > > > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta >
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
