Re: [netconf] WGLC on draft-ietf-netconf-over-tls13

[Jürgen Schönwälder <[e-mail]>]

Future proofing is always hard since we do not know the future. I
meanwhile find concrete advice more effective than generalized advice
- but I might have answered differently some 20 years ago. ;-)

That said, I am fine with both versions (with a slight preference for
concrete advice over generalized advice).

/js

On Wed, Mar 08, 2023 at 09:00:43PM -0500, Sean Turner wrote:
> Jürgen,
> 
> I am about to start landing these PRs and just wanted to confirm that what you were thinking about in terms of an “update” to RFC 7589 is captured by:
> https://github.com/netconf-wg/netconf-over-tls13/pull/11
> 
> spt
> 
> > On Feb 9, 2023, at 13:32, Sean Turner <[e-mail]> wrote:
> > 
> > Jürgen,
> > 
> > Thanks for your review. Responses below.
> > 
> > I’ll let these and the other PRs settle for a week before merging.
> > 
> > spt
> > 
> >> On Jan 25, 2023, at 09:32, Jürgen Schönwälder <[e-mail]> wrote:
> >> 
> >> On Mon, Jan 09, 2023 at 09:54:28PM +0000, Kent Watsen wrote:
> >>> We are starting a 2 week WGLC on:
> >>> 	- draft-ietf-netconf-over-tls13-01. 
> >>> 
> >>> The document can be found here:
> >>> 	https://datatracker.ietf.org/doc/draft-ietf-netconf-over-tls13
> >>> 
> >>> Please respond on this thread indicating your support or concerns about why this document should/should not be adopted.
> >>> 
> >>> We are particularly interested in statement of the form:
> >>> 	- I have reviewed the draft and found no issues. 
> >>> 	- I have reviewed the draft and found the following issues …
> >>> 
> >>> This WGLC will conclude on Monday, January 23.   
> >> 
> >> I have reviewed the document and I believe that what it is technically
> >> aims to achieve is OK and on track but the document itself is not ready.
> >> 
> >> - Does this document formally update RFC 7589? I am aware that updates
> >> means many different things (extending, depending-on, rewriting
> >> parts) so I should probably not even ask this question. ;-) But my
> >> gut feeling is that you really want a formal Updates: RFC 7589 here.
> > 
> > We were purposely trying to avoid updating RFC 7589, because we were trying to stay out of picking the MTI protocol. But based on a suggestion in UTA about how to deal with a similar update for syslog, I think we could follow the recommendations in RFC 9325 and not have to get embroiled in a lengthy debate because RFC 9235 is BCP 195:
> > 
> > *  Implementations MUST support TLS 1.2 [RFC5246].
> > *  Implementations SHOULD support TLS 1.3 [RFC8446] and, if
> >  implemented, MUST prefer to negotiate TLS 1.3 over earlier
> >  versions of TLS.
> > 
> > The following PR includes the proposed changes:
> > https://github.com/netconf-wg/netconf-over-tls13/pull/11
> > 
> > The change of course opens a can worms. Do we change the TLS1.2 MTI cipher suite? The MTI cipher suites based on this RFC 7589 (and this PR) is TLS_RSA_WITH_AES_128_CBC_SHA. There is no chance that cipher suites makes it through the IESG at this point. We could change it to what’s in RFC 9325. I understand why RFC 7589 did not make the 7525 recommendations a MUST; when RFC 7589 was published, RFC 7525 was pretty new. However, it’s been almost 8 years since then so I am hoping some of the recommendations, 2 of the four recommended in 2015 are still there, are widely supported. If that’s the case then maybe the 1st para should be:
> > 
> > Implementations MUST support TLS 1.2 {{RFC5246}}. The mandatory-to-implement
> > cipher suite is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. Implementations
> > SHOULD follow the recommendations given in [RFC9325].
> > 
> >> - As already noted by others, there is colloquial discussion around
> >> Section 9.1 of I-D.ietf-tls-rfc8446bis in the document that one
> >> would not expect in a WG last call document.
> > 
> > Yep deleting it. The section kind of did it’s job, i.e., “made you look” :)
> > The following PR removes it:
> > https://github.com/netconf-wg/netconf-over-tls13/pull/7
> > 
> >> - In the Security Considerations, what does 'please review" really
> >> mean? Is it required or expected to do what the referenced documents
> >> say or are these just some reading suggestions that can be ignored?
> >> I would prefer to see much clearer guidelines, in particular since
> >> we talk about security.
> > 
> > I guess this didn’t bother me as much as some, when I read “the security considerations of RFCxyz apply” that’s pretty much the same thing as "Please review  RFCxyz”. But, I can swap it out for the more common language. Note that because it’s an update, the security considerations actually got a lot shorter because we copied a lot them over. Here’s a PR to address this:
> > https://github.com/netconf-wg/netconf-over-tls13/pull/10
> > 
> >> - Editorial: Fix the following "describes defines" double verb.
> > 
> > Please see:
> > https://github.com/netconf-wg/netconf-over-tls13/pull/9
> > 
> >> /js
> >> 
> >> -- 
> >> Jürgen Schönwälder              Constructor University Bremen gGmbH
> >> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> >> Fax:   [phone]         <https://www.jacobs-university.de/>
> >> 
> >> _______________________________________________
> >> netconf mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/netconf
> > 
> 

-- 
Jürgen Schönwälder              Constructor University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://constructor.university/>