Re: [netconf] netconf-tls wasRe: Summary of updates

[Kent Watsen <[e-mail]>]

Hi Tom,

Pruning resolved items below.



> <tp2.0>
> OK, some references.
> 
> Grepping for the string “tp2.0” returns no results.

Oh, I think that you’re trying to be funny, as <tp2.0> identifies your follow-up comments, which may’ve been marked <tp>.   Do you see now how that wasn’t obvious to me, perhaps next time preface with a comment “see <tp2.0> for follow-ups”.  Better, as I and others have been recommended, you should ditch your web-mail client for something that implements normal indentation for replies...



> tlscmn
> 
> tls-ecc
> needs RFC8446
> 
> Why?  8446 refs and defers to 8422, right?
> <tp>
> wrong IMHO; look at the title of 8422 - "Versions 1.2 and earlier"

Okay, added.



> tls-dhe
> needs 8446
> 
> Okay, 8446 obsoletes 5246.
> <tp>
> Right but I think you need both.  The I-D currently highlights 1.2 and mostly ignores 1.3 where I think they should have equal billing and since they are so different, a reference to 1.3 alone is inadequate so my default position is that both 5246 and 8446 are needed.

The previous git-commit has both.



> tls-gcm
> needs 8446
> 
> Okay, but it’s strange that 8446 doesn’t ref/obsolete 5288…I guess because it uses the NIST “GCM” ref instead…perhaps this draft should as well?
> <tp>
> Well where do you stop? As above, I think that every 5246 needs a 8446 alongside it unless one version does not support the functionality but that is as far as I would go.
> 
> 
> identity ciphersuite
> I do not see the 1.3 values from 8446 B.4
> 
> grepping for “ciphersuite” returns no matches…?
> <tp>
> Bear in mind that 1.3 changes everything it can - try 'cipher suite’

Oh, you meant "cipher-suite-base”

This was Gary’s contribution, so I’m not too familiar with it, but I went ahead and added 5 new derived identities (for the 5 cipher suites listed in B.4), marking each with an “if-feature tls-1_3” statement, while also marking all the other derived identities with an "if-feature tls-1_2” statement.



> case psk
> needs Normative References to the two
> draft-ietf-tls-external-psk-*
> 
> "external-psk-guidance” is Informational and "external-psk-importer” while Standards Track, only regards an interface for importing the PSKs into TLS.  It seems that the existing ref to RFC 4279 (which is NOT obsolete) is pretty good, right?
> 
> <tp>
> Disagree.  The cipher suites of 4279 are invalid with 1.3  1.3 sort of does away with PSK except where there has been a full handshake from which a PSK can be derived for resumption.  1.3 imposes limits on the use of a PSK across versions and with different algorithms which is what  I see the two I-D as addressing.

Okay, added.



> Tom Petch


Updates can be found here: https://github.com/netconf-wg/tls-client-server/commit/d2af1d7707095f2ad977b804d0f9e13024489ab4 <https://github.com/netconf-wg/tls-client-server/commit/d2af1d7707095f2ad977b804d0f9e13024489ab4>

K.