Re: [netconf] Paul Wouters' Discuss on draft-ietf-netconf-over-tls13-03: (with DISCUSS and COMMENT)

[Sean Turner <[e-mail]>]

> On Dec 21, 2023, at 10:59, Kent Watsen <[e-mail]> wrote:
> 
> As a contributor:
> 
> 
>> On Dec 19, 2023, at 10:12 PM, Sean Turner <[e-mail]> wrote:
>> 
>> 
>>> On Dec 13, 2023, at 09:03, Paul Wouters <[e-mail]> wrote:
>>> 
>>> On Dec 12, 2023, at 11:35, Sean Turner <[e-mail]> wrote:
>>>> 
>>>> ----------------------------------------------------------------------
>>>>> 
>>>>> DISCUSS:
>>>>> ----------------------------------------------------------------------
>>>>> 
>>>>> Why does Section 4 not simply point to the ciphersuites MTI of the respective TLS versions?
> 
> This is my question as well.  This draft pinning any cipher suite (i.e., TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) will likely not age well...
> 
> 
>>>>> TLS 1.3 as per RFC8446bis Section 9.1:
>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-tls-rfc8446bis-09#name-mandatory-to-implement-ciph
>>>>> 
>>>>> TLS 1.2 to RFC9325 Section 4.2:
>>>>> https://datatracker.ietf.org/doc/html/rfc9325#name-cipher-suites-for-tls-12
>>>>> 
>>>>> It almost does this but then decides on its own more limited set of
>>>>> ciphersuites. Is there a good reason for this why to deviate from the
>>>>> TLS 1.2 and 1.3 standards? Or why not to stick to the RECOMMENDED Y
>>>>> column in the IANA registry for TLS Ciphersuites ?
>>>> 
>>>> For TLS 1.2:
>>>> 
>>>> RFC 7589 includes the following text:
>>>> 
>>>> Implementations MUST support TLS 1.2 and are REQUIRED to
>>>> support the mandatory-to-implement cipher suite.
>>>> 
>>>> That cipher suite is TLS_RSA_WITH_AES_128_CBC_SHA. RFC 7589
> 
> RFC 5246 is obsoleted by RFC 8446.  https://datatracker.ietf.org/doc/html/rfc8446#section-9.1 says:
> 
>    A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256
>    [GCM] cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384
>    [GCM] and TLS_CHACHA20_POLY1305_SHA256 [RFC8439] cipher suites (see
>    Appendix B.4).
> 
> So TLS_RSA_WITH_AES_128_CBC_SHA is no longer required.
> 
> 
>>>> also includes:
>>>> 
>>>> Implementations SHOULD follow the recommendations given in [RFC7525].
>>>> 
>>>> So what I did was go look at the four algorithms in RFC 9325:
>>> 
>>> Now I am a bit worried about the use of “I” here. If you picked the TLS 1.2 parameters based on existing netconf implementations, I would feel better. But now it seems based on your assumptions on netconf? Are there any netconf people who can weigh in ?
>> 
>> “I" was just providing background as to how the I-D ended up the way it did, so don’t read too much into the “I”. But, I get your point. Let me see if I can get some more input.
>> 
>>>> * TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
>>>> * TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
>>>> * TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
>>>> * TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
>>>> 
>>>> and I (potentially naively) thought RSA AES_128 CDC to RSA AES_128 GCM seemed like an easy enough swap so let’s specify TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. So, I picked one from the list as opposed to pointing at the entire list. The difference is that implementations are required to support only one and not 4 algorithms.
> 
> This doesn’t make sense to me.  How does RFC 7589’s "Implementations SHOULD follow the recommendations given in [RFC7525]” get promoted to requiring a specific algorithm?  [Note: 7525 obsoleted by 9325]
> 
> 
>>> That might of course be a valid enough reason. Do we have any implementers or operators in the room to guide us ?
>>> 
>>>> But, what I think you are suggesting (and I can live with) is the following ? :
>>>> 
>>>> Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to
>>>> support the cipher suites from Section 4.2. [RFC9325
>>> 
>>> I am saying we should do this, but I did want to hear some justification if we are not doing this. But I don’t know if AES-GCM is as available as AES-CBC on netconf devices for example. I was hoping the WG would have guidance here that would explain the choices made. (Generally, “Sean thought this was wise” is a good choice, but it would be better if we could make a more informed discussion)
> 
> Is this not the expected collateral damage that the IETF creates when, e.g., RFC 8446 obsoletes RFC 5246 with different MTIs.  This affects all apps, it isn't a NETCONF-specific problem, right?
> 
> Being very practical, NETCONF servers implemented prior to RFC 8446 MUST support TLS_RSA_WITH_AES_128_CBC_SHA.  NETCONF servers implemented after to RFC 8446 don’t have to but, in order to maintain interoperability with existing clients, likely will.
> 
> Kent  // contributor

Agreed that picking one is not a good idea and you’re probably right that to maintain interop with existing implementations TLS_RSA_WITH_AES_128_CBC_SHA is going to keep right on getting used. But, I can’t really in good conscious include it in an I-D anymore (except to deprecate it).  So, here’s my proposal:

OLD:
   Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to
   support the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite
   [RFC9325].

NEW:
   Implementations MUST support TLS 1.2 [RFC5246] and they are, as specified
   in [RFC9325], recommended to support the cipher suites found in Section 4.2 of
   [RFC9325].

I purposely used “recommended” and not “RECOMMENDED" because the recommendation is already in RFC 9525; I have been told repeating requirements is bad.

Cheers,
spt