Subject: [netconf] Summary of updates

From: Kent Watsen <[email-masked]>
Date: Tue, 18 May 2021 18:37:16 +0000

Thank you to all that contributed to the WGLC of the tcp-, ssh-, tls-, and http- client-server drafts.  Below is the result change log for each draft, but the highlights for me are:

   1) for the “tcp” draft, the abstract/introduction sections were enhanced by Michael, my co-author and TCP WG co-chair.
   2) for the “ssh” draft, we added and then removed the keyboard-interactive and GSS-API support.
   3) for the “tls” draft, we marked the feature statements for versions  other than 1.3 as “not recommended”.
   4) for the “http” draft, no significant update (really? hmm...)
   5) for the “netconf” draft, whilst not in WGLC, significant updates wrt the "client-identity-mappings” nodes.

Notably, beware that the Last Call YANG-doctor review for some of these four drafts has been pending this update, so expect to see a little more activity on these drafts yet. 

K.

DETAILS:

crypto-types:
   *  Nits found via YANG Doctors reviews.
   *  Aligned modules with `pyang -f` formatting.

truststore:
   *  Added prefixes to 'path' statements per trust-anchors/issues/1
   *  Renamed feature "truststore-supported" to "central-truststore-supported".
   *  Associated with above, generally moved text to refer to a
      "central" truststore.
   *  Removed two unecessary/unwanted "min-elements 1" and associated
      "presence" statements.
   *  Aligned modules with `pyang -f` formatting.
   *  Fixed nits found by YANG Doctor reviews.

keystore:
   *  Added prefixes to 'path' statements per trust-anchors/issues/1
   *  Renamed feature "keystore-supported" to "central-keystore-
      supported".
   *  Associated with above, generally moved text to refer to a
      "central" keystore.
   *  Aligned modules with `pyang -f` formatting.
   *  Fixed nits found by YANG Doctor reviews.

tcp-client-server:
   *  Updated Abstract and Intro to address comments by Tom Petch.
   *  Removed the "tcp-connection-grouping" grouping (now models use the
      "tcp-common-grouping" directly).
   *  Added XML-comment above examples explaining the reason for the
      unusual top-most element's presence.
   *  Added Securty Considerations section for the "local-binding-
      supported" feature.
   *  Replaced some hardcoded refs to <xref> elements.
   *  Fixed nits found by YANG Doctor reviews.
   *  Aligned modules with `pyang -f` formatting.
   *  Added an "Acknowledgements" secetion.

ssh-client-server:
   *  Removed the 'supported-authentication-methods' from {grouping ssh-
      server-grouping}/client-authentication.
   *  Added XML-comment above examples explaining the reason for the
      unexepected top-most element's presence.
   *  Added RFC-references to various 'feature' statements.
   *  Renamed "credentials" to "authentication methods"
   *  Renamed "client-auth-*" to "userauth-*"
   *  Renamed "client-identity-*" to "userauth-*"
   *  Fixed nits found by YANG Doctor reviews.
   *  Aligned modules with `pyang -f` formatting.
   *  Added a 'Contributors' section.

tls-client-server:
   *  Added missing reference to "FIPS PUB 180-4".
   *  Added identity "tls-1.3" and updated description statement in
      other identities indicating that the protocol version is obsolete
      and enabling the feature is NOT RECOMMENDED.
   *  Added XML-comment above examples explaining the reason for the
      unexpected top-most element's presence.
   *  Added missing "client-ident-raw-public-key" and "client-ident-psk"
      featutes.
   *  Aligned modules with `pyang -f` formatting.
   *  Fixed nits found by YANG Doctor reviews.
   *  Added a 'Contributors' section.

http-client-server:
   *  Added XML-comment above examples explaining the reason for the
      unusual top-most element's presence.
   *  Renamed 'client-auth-config-supported' to 'client-auth-supported'
      consistent with other drafts.
   *  Wrapped 'container basic' choice inside a 'case basic' per best
      practice.
   *  Aligned modules with `pyang -f` formatting.
   *  Fixed nits found by YANG Doctor reviews.

netconf-client-server:
   *  Floated an 'if-feature' statement in a grouping down to where the
      grouping is used.
   *  Clarified 'client-identity-mappings' for both the SSH and TLS
      transports.
   *  For netconf-client, augmented-in a 'mapping-required' flag into
      'client-identity-mappings' only for the SSH transport, and
      refined-in a 'min-elements 1' only for the TLS transport.
   *  Aligned modules with `pyang -f` formatting.

restconf-client-server:
   *  Further clarified why some 'presence' statements are present.
   *  Addressed nits found in YANG Doctor reviews.
   *  Aligned modules with `pyang -f` formatting.

---

From: tom petch <[email-masked]>
Date: Wed, 19 May 2021 11:50:06 +0000

From: netconf <[email-masked]> on behalf of Kent Watsen <[email-masked]>
Sent: 18 May 2021 19:37

<tp>
I still think that the I-D lacks clarity about supported versions.

Introduction 
TLS Protocol [RFC5246] 
Clearly this is TLS1.2 only

s.2
This model supports both TLS1.2 and TLS1.3
Ah, no, TLS1.2 and TLS1.3 but not TLS1.0 or TLS1.1

s.2.1.1
Features
tls-1_0
tls-1_1
tls-1_2
tls-1_3
Ah no, it may not support 1.0 and 1.1 but it ........ for them but I know not what.

2.2 
an example for 1.1 and 1.2 but not 1.3; interesting.

Reverse engineering the YANG I find that that 'Version 1.0 is supported', 'Version 1.1 is supported'.

hello-params-grouping
Only 1.2 is referenced as indeed is repeatedly the case in the YANG modules

Mmm I dunno!

I want the Introduction to set the scene which subsequent sections expand on and that I see as lacking.  Support fot 1.0 and 1.1 would, for me, catering for the different cipher suites that they have.

In passing, I was wrong about public keys.  I misread the statement that only certificates and PSK are supported in TLS1.3, forgetting that certificate(255) is a public key!

Tom Petch

K.

DETAILS:

crypto-types:

truststore:

keystore:

tcp-client-server:

ssh-client-server:

tls-client-server:

http-client-server:

netconf-client-server:

restconf-client-server:

_______________________________________________
netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Kent Watsen <[email-masked]>
Date: Thu, 20 May 2021 23:12:50 +0000

Hi Tom,

> Clearly this is TLS1.2 only

Yes.   In keeping with the original intention (to reference just the current, not obsoleted, document), this should be updated to RFC 8446.   But I wonder if you think the document should reference all four documents (2246, 4346, 5246, and 8446) and then have DOWNREFS?

Background: the document generally references TLS 1.2 as that *was* the “current” TLS version when most of the text was written.  TLS 1.3 happened later, and a minimal (and apparently inadequate) update was made to accommodate it.  What you’re finding are the remnants of that history...

PS:  I don’t claim to be a TLS expert.  It would be helpful if corrected text could be provide.  Pointing out the issues is great, but it takes time for me to determine what update is needed, something you may have well in mind?

K.

---

From: tom petch <[email-masked]>
Date: Fri, 21 May 2021 10:27:37 +0000

From: Kent Watsen <[email-masked]>
Sent: 21 May 2021 00:12

Hi Tom,

Introduction
TLS Protocol [RFC5246]

<tp>
Yes, I did divine that the I-D appeared before TLS1.3 and so that was retrofitted.  Since that is now the current version and has been for a while, I think that all references to TLS1.2 need a parallel reference to 1.3 as long as 1.3 has the same constructs (which in places it has not).  This applied throughout the YANG modules

I was all for ditching any mention of 1.1 and 1.0 if only for the extra complication.  I no longer recall where 1.2 differs from its predecessors e.g. extensions incorporated in the base, signature algorithms, and it is probably overkill to find the relevant references for those older versions and adding them to the YANG as well but do think something needs adding in the body of the I-D to the effect that support for 1.0, 1.1 is partial, identity for the version number but not details of cipher suites, relevant RFC and so on.

I will look some more at the TLS1.3 references next week.

Tom Petch

K.

s.2

s.2.1.1
Features
tls-1_0
tls-1_1
tls-1_2
tls-1_3

2.2

hello-params-grouping

Mmm I dunno!

Tom Petch

K.

DETAILS:

crypto-types:

truststore:

keystore:

tcp-client-server:

ssh-client-server:

tls-client-server:

http-client-server:

netconf-client-server:

restconf-client-server:

_______________________________________________
netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

---

From: tom petch <[email-masked]>
Date: Mon, 24 May 2021 09:07:25 +0000

From: tom petch <[email-masked]>
Sent: 21 May 2021 11:27
From: Kent Watsen <[email-masked]>
Sent: 21 May 2021 00:12

Hi Tom,

<tp2.0>
OK, some references.

tlscmn

tls-ecc
needs RFC8446

tls-dhe
needs 8446

tls-3des
ok no support in 1.3

tls-gcm 
needs 8446

identity ciphersuite
I do not see the 1.3 values from 8446 B.4

hello-params
needs 8446

tls-client
I note that the feature statements do not have references which some YANG doctors say they should have.

container client-identity
needs 8446 and a reference in the body to 8446 s.4.4.2

case psk
needs Normative References to the two
draft-ietf-tls-external-psk-*

tls-server

container server-identity
as client-identity

case psk
as for tls-client

Tom Petch

Introduction
TLS Protocol [RFC5246]

<tp>

Tom Petch

K.

s.2

s.2.1.1
Features
tls-1_0
tls-1_1
tls-1_2
tls-1_3

2.2

hello-params-grouping

Mmm I dunno!

Tom Petch

K.

---

From: Kent Watsen <[email-masked]>
Date: Mon, 24 May 2021 23:16:30 +0000

[CC-ing Gary in case he can help]

Hi Tom,

> Yes.   In keeping with the original intention (to reference just the current, not obsoleted, document), this should be updated to RFC 8446.   But I wonder if you think the document should reference…

I didn’t get what you wanted to do here but, for now, I replaced that reference with this paragraph:

    Any version of TLS may be configured, including
     <xref target="RFC2246"/>,  <xref target="RFC4346"/>,
     <xref target="RFC5246"/>, and <xref target="RFC8446"/>.
     Configuring obsolete protocol versions for use in production
     networks is NOT RECOMMENDED.

> I was all for ditching any mention of 1.1 and 1.0 if only for the extra complication.

By “was all for”, do you mean that you’re no longer?  That is, that “supporting” all versions is fine?

>   I no longer recall where 1.2 differs from its predecessors e.g. extensions incorporated in the base, signature algorithms, and it is probably overkill to find the relevant references for those older versions and adding them to the YANG as well but do think something needs adding in the body of the I-D to the effect that support for 1.0, 1.1 is partial, identity for the version number but not details of cipher suites, relevant RFC and so on.

Would you suggest adding said comment to the above paragraph?

> Ah, no, TLS1.2 and TLS1.3 but not TLS1.0 or TLS1.1

Do you mean that the sentence is incorrect because the model does support 1.0 and 1.1?  Perhaps simple remove the sentence altogether in light of the above new paragraph?

> Ah no, it may not support 1.0 and 1.1 but it ........ for them but I know not what.

I don’t understand this comment.

> an example for 1.1 and 1.2 but not 1.3; interesting.

That example is completely arbitrary IMO but, alas, it was created by Gary Wu, who is listed as a “Contributor”, but we haven’t heard from in a long time since...

> Reverse engineering the YANG I find that that 'Version 1.0 is supported', 'Version 1.1 is supported'.

Correct.  All the versions as “supported”; all but 1.3 are NOT RECOMMENDED.  Is this a problem?

> Only 1.2 is referenced as indeed is repeatedly the case in the YANG modules

Again, 1.2 *was* “current” before and so everything just pointed to it, assuming that it is a superset of 1.0 and 1.1?  We could just replace all refs to “1.2” with “1.3” and call it a day, but I don’t know if that would be technically accurate.

> I want the Introduction to set the scene which subsequent sections expand on and that I see as lacking.  Support fot 1.0 and 1.1 would, for me, catering for the different cipher suites that they ha…

So we need to define additional ciphersuites for 1.0 and 1.1 or dump support for those protocol versions?

> In passing, I was wrong about public keys.  I misread the statement that only certificates and PSK are supported in TLS1.3, forgetting that certificate(255) is a public key!

Gotcha

> Tom Petch

THANK YOU!

Updates can be found in https://github.com/netconf-wg/tls-client-server/commit/b94588b5a33c0852cfacbc415ca0a626bc1c5763.

K.

---

From: Kent Watsen <[email-masked]>
Date: Mon, 24 May 2021 23:43:35 +0000

[CC-ing Gary again...]

Hi Tom,

> I still think that the I-D lacks clarity about supported versions.

Grepping for the string “tp2.0” returns no results.

> needs RFC8446

Why?  8446 refs and defers to 8422, right?

> needs 8446

Okay, 8446 obsoletes 5246.

> ok no support in 1.3

Ack.  Unmodified.

> 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?

> I do not see the 1.3 values from 8446 B.4

grepping for “ciphersuite” returns no matches…?

> needs 8446

Added.

> I note that the feature statements do not have references which some YANG doctors say they should have.

Added (for X.509, PSK, and RPK)

> needs 8446 and a reference in the body to 8446 s.4.4.2

Added.

> 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?

> container server-identity

Added.

> as for tls-client

Same.

THANK YOU!

K.

---

From: tom petch <[email-masked]>
Date: Tue, 25 May 2021 09:50:44 +0000

Sent: 25 May 2021 00:43

[CC-ing Gary again...]

Hi Tom,

<tp2.0>
OK, some references.

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"

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.

tls-3des
ok no support in 1.3

Ack.  Unmodified.

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

grepping for “ciphersuite” returns no matches…?
<tp>
Bear in mind that 1.3 changes everything it can - try 'cipher suite'

hello-params
needs 8446

Added.

tls-client

Added.

case psk

<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.

Tom Petch

tls-server

Added.

case psk
as for tls-client

Same.

Tom Petch

THANK YOU!

K.

---

From: tom petch <[email-masked]>
Date: Tue, 25 May 2021 09:56:52 +0000

Sent: 25 May 2021 00:16

Hi Tom,

<tp>
I would still drop 1.0 and 1.1 entirely but see that others disagree.  As things stand, I do think that you need to differentiate between 1.2/1.3 and 1.0/1.1, the former being comprehensively supported, the latter not.  I do not have a good set of words for this but think that you need something in the Introduction to set expectations. You could add more details of 1.0/1.1 but I would see that as a retrograde step.

Tom Petch 

Tom Petch

Gotcha

THANK YOU!

K.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 25 May 2021 12:06:52 +0200

Hi,

RFC 5539 (published in May 2009) defines NETCONF over TLS and it is
very specific that it requires TLS 1.2 or future versions of TLS:

   Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to
   support the mandatory-to-implement cipher suite, which is
   TLS_RSA_WITH_AES_128_CBC_SHA.  This document is assumed to apply to
   future versions of TLS; in which case, the mandatory-to-implement
   cipher suite for the implemented version MUST be supported.

Given this, I do not think we need to consider TLS versions < 1.2
since there was never a specification for NETCONF over TLS versions <
1.2 - a NETCONF over TLS 1.1 implementation is using a non-standard
transport.

/js

PS: And as I said before, if any updates to RFC 5539 are necessary to
    support NETCONF over TLS 1.3 properly, then we should spin RFC
    5539 and not deal with the definition of a transport mapping in
    the configuration document.

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Kent Watsen <[email-masked]>
Date: Tue, 25 May 2021 14:04:02 +0000

Hi Juergen,

> 1.2 - a NETCONF over TLS 1.1 implementation is using a non-standard

The tls-client-server draft is not exclusive to NETCONF.  For example, RESTCONF and PCE WG has a “peep-yang” draft...

That said, it seems Tom is saying that TLS 1.0 and 1.1 are effectively historic at this point (no longer used) and so support for those versions should be dropped for that reason?

>    the configuration document.

Adding TLS 1.3 to the tls-client-server draft is not for NETCONF’s sake.  

The netconf-client-server doesn’t yet, but perhaps should, state that the tls-client-server’s draft support for 1.3 should be ignored until RFC 5539 is updated? 

Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 25 May 2021 16:40:40 +0200

> The tls-client-server draft is not exclusive to NETCONF.  For example, RESTCONF and PCE WG has a “peep-yang” draft...

Yep, I tend to forget this...
 
> That said, it seems Tom is saying that TLS 1.0 and 1.1 are effectively historic at this point (no longer used) and so support for those versions should be dropped for that reason?

If there are any features provided to configure historic versions of
TLS, then the features and identities for TLS 1.0 and 1.1 should
likely have a status obsolete and the feature and identities for TLS
1.2 may have status deprecated.
 
> The netconf-client-server doesn’t yet, but perhaps should, state
> that the tls-client-server’s draft support for 1.3 should be ignored
> until RFC 5539 is updated?

I guess someone (Tom?) should review RFC 5539 from the TLS 1.3
perspective to tell the WG if any changes are needed so that the WG
can take an informed decision whether an update of RFC 5539 is
necessary or whether what we have is good enough.

/js

---

From: tom petch <[email-masked]>
Date: Tue, 25 May 2021 15:58:10 +0000

From: Juergen Schoenwaelder <[email-masked]>
Sent: 25 May 2021 15:40

<tp>
Well, I tend to forget that RFC5539 is obsolete, obsoleted by RFC7589 which is X.509 certificate only; no PSK, no naked public keys.  My concerns with TLS1.3 mostly relate to PSK which allows data to flow before the handshake is complete, before authentication is complete, which is a problem for some applications as I mentioned before; but staying with X.509 authentication only for Netconf makes life simpler for a 7589bis, replace 1.2 by 1.3 and think about the extensions to see what may be needed.

Here however, with netconf-tls, the question is what the scope should be, to include or exclude TLS1.0/1.1 and how far to delve into PSK and early data; I assume that TLS1.3 must be covered in at least as much detail as TLS1.2, which was the starting point for my comments, where I saw lots of references for 1.2, very few for 1.3.. 

Tom Petch

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 25 May 2021 18:29:21 +0200

> Well, I tend to forget that RFC5539 is obsolete, obsoleted by RFC7589 which is X.509 certificate only; no PSK, no naked public keys.  My concerns with TLS1.3 mostly relate to PSK which allows data…

So regarding a possible update of RFC 7589, what is needed?

+ Require TLS 1.3 (update section 8)

Which extensions should one think about? Do you mean RFC 8773 or
something else?

/js

---

From: Kent Watsen <[email-masked]>
Date: Tue, 25 May 2021 22:55:33 +0000

Hi Tom,

Pruning resolved items below.

> 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...

> wrong IMHO; look at the title of 8422 - "Versions 1.2 and earlier"

Okay, added.

> 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 i…

The previous git-commit has both.

> 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.

> 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 l…

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.

---

From: Kent Watsen <[email-masked]>
Date: Tue, 25 May 2021 22:55:47 +0000

Hi Tom,

> I would still drop 1.0 and 1.1 entirely but see that others disagree.  As things stand, I do think that you need to differentiate between 1.2/1.3 and 1.0/1.1, the former being comprehensively suppo…

Intro now says:

   Any version of TLS may be configured.  TLS 1.0 [RFC2246] and TLS 1.1
   [RFC4346] are historic and hence the YANG "feature" statements
   enabling them are marked "status obsolete".  TLS 1.2 [RFC5246] is
   obsoleted by TLS 1.3 [RFC8446] but still is common use, and hence its
   "feature" statement is marked "status obsolete".  All the "feature"
   statements for 1.0, 1.1, and 1.3 have "description" statements
   stating that it is NOT RECOMMENDED to enable obsolete protocol
   versions.

K.

PS: below are other comments from my previous reply.   Some are still open in my mind, but otherwise will be considered dropped.

---

From: Kent Watsen <[email-masked]>
Date: Tue, 25 May 2021 22:56:03 +0000

Hi Juergen,

> 1.2 may have status deprecated.

Done.

K.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 26 May 2021 08:39:20 +0200

>    "feature" statement is marked "status obsolete".  All the "feature"

I think it should say deprecated for TLS 1.2 since this is what the
YANG definitions say (I guess a typo, and change 'is common use' to
'in common use').

/js

---

From: tom petch <[email-masked]>
Date: Wed, 26 May 2021 09:23:17 +0000

Sent: 25 May 2021 17:29

<tp>
It is more a question of going through 8446 s.4.2 s.9.2 to see what we want by way of an Application Profile.  Thus I would like to prohibit PSK but that prohibits session resumption which is fine by me but I have limited exposure to what the world is doing so may be it is not that simple.

There is another problem which I see as larger and that is that the TAPS WG is revising RFC6125 and this leans heavily on that RFC and that might take a year or two to get revised.  I don't have a sense of where a 6125bis is going.

Tom Petch

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 26 May 2021 13:53:10 +0200

This sounds like 'lets wait and see what comes out of the RFC 6125
revision' is the best approach for now.

/js

---

From: Kent Watsen <[email-masked]>
Date: Wed, 26 May 2021 14:11:47 +0000

> YANG definitions say

Yes. It was only an issue in the Introduction section, as the YANG had/has 1.2 as “deprecated".

> (I guess a typo, and change 'is common use' to
> 'in common use').

Quite right, fixed.

K.

---

From: tom petch <[email-masked]>
Date: Wed, 26 May 2021 15:45:57 +0000

Sent: 26 May 2021 12:53

<tp>
WFM

I do have an element of FUD about this (as I have about TLS1.3) which hopefully will diminish with time.

Tom Petch

/js

---

From: tom petch <[email-masked]>
Date: Wed, 26 May 2021 16:12:14 +0000

From: netconf <[email-masked]> on behalf of tom petch <[email-masked]>
Sent: 26 May 2021 16:45

<tp>
Oh dear; I got the wrong WG.  The 6125 update I-D exists and is in the UTA WG (which I am not subscribed to but saw a cross post thereof). It is quite short and is very much an updates, requiring the use of SAN, prohibiting CN-ID.   It was published on April 1st, 2021:-)

Tom Petch

<tp>
WFM

Tom Petch

/js

---

From: tom petch <[email-masked]>
Date: Thu, 27 May 2021 11:09:52 +0000

From: Kent Watsen <[email-masked]>
Sent: 25 May 2021 23:55
Subject: Re: netconf-tls wasRe: [netconf] Summary of updates

<tp>

Top posting a new and different issue.

server case psk references ServerKeyExchange and psk-identity-hint neither of which exist in TLS1.3.  The client sends an extension PreSharedKeyExtension which contains a list of identities from which the server selects one as selected-identity for which the identifier is uint16 indexing into the client's list. RFC8446 s.4.2.11.

The client description also needs amending.

TLS1.2 was extended to use tickets in this area to aid session resumption; these have now gone and been replaced by this extension.  I would not suggest adding support for tickets.

As I may have said before, TLS 1.3 is different.

Tom Petch 

Hi Tom,

<snip>