Subject: [TLS] Comments on draft-wood-tls-external-psk-importer-01

From: John Mattsson <[email-masked]>
Date: Mon, 1 Apr 2019 19:00:58 +0000

Hi,

Thanks for trying to solve this problem! Not having a way to use the same external PSK for different cipher suites is definitely a thing missing from TLS 1.3.

As I stated during the wg session, 3GPP have a few use cases that use PSK-ECDHE between phone and core network. Contrary to what IETF people sometimes believe, most 3GPP use of TLS (between phone and core network, between core nodes, and between different operators) use mutual authentication with certificates.

According to the current 3GPP specification, the phone and the core network would share an external PSK and an external identity. The hash function is undefined, i.e. SHA-256 is used for TLS 1.3. The phone and the network would then negotiate TLS 1.2 with any cipher suite or TLS 1.3 with SHA-256.

Some comments

- The draft should make clear if the External PSK and external identity can be used together with the imported identities. I assume the idea is that they can’t but I can’t see any text specifying this.

- ”Imported keys do not require negotiation for use, as a client and
server will not agree upon identities if not imported correctly.
Thus, importers induce no protocol changes with the exception of
expanding the set of PSK identities sent on the wire.”

While I see how the defined mechanism can be deployed in a new deployment, I do not see how to introduce it in an existing deployment. Assuming that the external PSK cannot be used together with the imported identities, the TLS client and server must introduce the mechanism at the same time, that is often not possible to control.

- “struct {
       opaque external_identity<1...2^16-1>;
       opaque label<0..2^8-1>;
       HashAlgorithm hash;
   } ImportedIdentity;
  ”

This scales poorly, A client has to send n*m identities where n is the number of supported versions and m is the number of supported hash algorithms...

- Would it not be possible to just use the version number as label? I.e. 0x0304 instead of “tls13”. In that way you do at least not have to define a new labels.

- “TLS 1.3 [RFC8446] supports pre-shared key (PSK) resumption, wherein
PSKs can be established via session tickets from prior connections or
externally via some out-of-band mechanism.”

This seems to indicate that all use of PSK is resumption which is not correct. I suggest changing to “TLS 1.3 [RFC8446] supports pre-shared key (PSK) authentication”

- “importing external PSK (Pre-Shared Key) into TLS.”

Not sure if “into” is the right word, I think “for” as in the title is better. The mechanism seems very much external to TLS itself. I see it as a mechanism to derive several external PSKs from a single external PSK.

- “Similarly, TLS 1.2 and all prior TLS versions should use "tls12" “

The versions prior to TLS 1.2 will soon be deprecated. And why spend time updating the TLS 1.2 code base instead of moving to TLS 1.3? 

Suggestion:

Instead of deriving a large set of new external PSKs, wouldn’t it be possible to just use different hash functions in different parts of the key hierarchy? I.e. if SHA-256 is associated with the external PSK and SHA-384 is the hash algorithms in the chosen cipher suite:

PSK ->  HKDF-Extract(SHA-256) = Early Secret
          |
          +-----> Derive-Secret(., "ext binder" | "res binder", "")
          |                     = binder_key
          |
          +-----> Derive-Secret(., "c e traffic", ClientHello)
          |                     = client_early_traffic_secret
          |
          +-----> Derive-Secret(., "e exp master", ClientHello)
          |                     = early_exporter_master_secret
          v
    Derive-Secret(., "derived", "")
          |
          v
(EC)DHE -> HKDF-Extract(SHA-384) = Handshake Secret

Support of this could be signalled with the tls_flags extension. If the server does not support the extension it must according to RFC 8446 chose a cipher suite with SHA-256.

Cheers,
John

---

From: Russ Housley <[email-masked]>
Date: Mon, 1 Apr 2019 16:47:14 -0400

John:
> 
> The draft should make clear if the External PSK and external identity can be used together with the imported identities.

I think that draft-ietf-tls-tls13-cert-with-extern-psk would be needed with TLS 1,3 for the certificate-based authentication to be used with an external PSK.

Russ

---

From: John Mattsson <[email-masked]>
Date: Mon, 1 Apr 2019 21:29:53 +0000

Hi Russ,

I was not talking about certificates at all. My comment was about using both external_identity and one of its derived ImportedIdentity in OfferedPsks

draft-wood-tls-external-psk-importer-01:

     struct {

RFC 8446:

      struct {
          PskIdentity identities<7..2^16-1>;
          PskBinderEntry binders<33..2^16-1>;
      } OfferedPsks;

      struct {
          opaque identity<1..2^16-1>;
          uint32 obfuscated_ticket_age;
      } PskIdentity;

John

From: Russ Housley <[email-masked]>
Date: Monday, 1 April 2019 at 22:47
To: John Mattsson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [TLS] Comments on draft-wood-tls-external-psk-importer-01

John:

Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 1 Apr 2019 18:03:59 -0400

John:

Okay, I misread the first note.  Sorry for the noise.

Russ

> On Apr 1, 2019, at 5:29 PM, John Mattsson <[email-masked]> wrote:
> 
> Hi Russ,
>  
> From: Russ Housley <[email-masked] <mailto:[email-masked]>>
> To: John Mattsson <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>

---

From: "Christopher Wood" <[email-masked]>
Date: Wed, 03 Apr 2019 07:25:17 -0700

Thanks for the feedback, John. I filed issues on the GitHub draft 
located at [1]. Please see inline below for comments.

On 1 Apr 2019, at 12:00, John Mattsson wrote:

>  Hi,
>
> Thanks for trying to solve this problem! Not having a way to use the 
> same external PSK for different cipher suites is definitely a thing 
> missing from TLS 1.3.
>
> As I stated during the wg session, 3GPP have a few use cases that use 
> PSK-ECDHE between phone and core network. Contrary to what IETF people 
> sometimes believe, most 3GPP use of TLS (between phone and core 
> network, between core nodes, and between different operators) use 
> mutual authentication with certificates.
>
> According to the current 3GPP specification, the phone and the core 
> network would share an external PSK and an external identity. The hash 
> function is undefined, i.e. SHA-256 is used for TLS 1.3. The phone and 
> the network would then negotiate TLS 1.2 with any cipher suite or TLS 
> 1.3 with SHA-256.
>
> Some comments
>
> - The draft should make clear if the External PSK and external 
> identity can be used together with the imported identities. I assume 
> the idea is that they can’t but I can’t see any text specifying 
> this.

Indeed, that was the intent.

> While I see how the defined mechanism can be deployed in a new 
> deployment, I do not see how to introduce it in an existing 
> deployment. Assuming that the external PSK cannot be used together 
> with the imported identities, the TLS client and server must introduce 
> the mechanism at the same time, that is often not possible to control.

You’re correct that this requires both endpoints to adopt the change 
simultaneously. However, that does not contradict the quoted text, which 
states that the protocol is not changed.

> This scales poorly, A client has to send n*m identities where n is the 
> number of supported versions and m is the number of supported hash 
> algorithms...

Yes, this is a tradeoff we made by opting to not modify the key 
schedule.

>
> - Would it not be possible to just use the version number as label? 
> I.e. 0x0304 instead of “tls13”. In that way you do at least not 
> have to define a new labels.

We probably could, though since the labels are subject to change (see 
the TODO about possibly including the HashAlgorithm in the label), we 
kept it as is.

> This seems to indicate that all use of PSK is resumption which is not 
> correct. I suggest changing to “TLS 1.3 [RFC8446] supports 
> pre-shared key (PSK) authentication”

Good suggestion! We’ll fix it.

> Not sure if “into” is the right word, I think “for” as in th e 
> title is better. The mechanism seems very much external to TLS itself. 
> I see it as a mechanism to derive several external PSKs from a single 
> external PSK.

Ditto.

> The versions prior to TLS 1.2 will soon be deprecated. And why spend 
> time updating the TLS 1.2 code base instead of moving to TLS 1.3?

We’re just covering our bases here. I tend to agree that the focus 
should be on updating to TLS 1.3 instead of “patching” TLS 1.2 
stacks.

>
>
> Suggestion:
>
> Instead of deriving a large set of new external PSKs, wouldn’t it be 
> possible to just use different hash functions in different parts of 
> the key hierarchy? I.e. if SHA-256 is associated with the external PSK 
> and SHA-384 is the hash algorithms in the chosen cipher suite:
>
> Support of this could be signalled with the tls_flags extension. If 
> the server does not support the extension it must according to RFC 
> 8446 chose a cipher suite with SHA-256.

Modifying the key schedule was discussed in the context of [2]. At the 
time, it seemed the desire to not touch the key schedule outweighed the 
desire to not inflate the ClientHello.

Best,
Chris

[1] https://github.com/chris-wood/draft-wood-tls-external-psk-importer
[2] https://tools.ietf.org/html/draft-davidben-tls-universal-psk-00

---

From: John Mattsson <[email-masked]>
Date: Thu, 4 Apr 2019 06:22:28 +0000

Hi Christopher,

Thanks for the clarifications.

>states that the protocol is not changed.

I think "this requires both endpoints to adopt the change simultaneously" is a problem as it makes it impossible to introduce this mechanism in many existing deployments. I would expect a solution that can be introduced gradually (some nodes at a time) in existing deployments supporting RFC 8446 and/or RFC 5246.

But, if you want to change the behaviour of the using the same external PSK in both TLS 1.2 and TLS 1.3 as allowed by RFC 8446, a solution not requiring "simultaneous change" is probably not possible.

The requirement that "this requires both endpoints to adopt the change simultaneously" should probably be highlighted in the document.

The current mechanism does not seem to be deployable for e.g. 3GPP until TLS 1.4 is introduced, and then only for TLS 1.4 and later...  on the other hand, being limited to SHA-256 for PSK may be ok for 3GPP. (and 3GPP could just derive a Separate SHA-384 PSK if needed).

Some more comment:

- Which label should be used by various versions of DTLS?

- "If a client or server wish to deprecate a hash function and no longer
use it for TLS 1.3, they may remove this hash function from the set
of hashes used during while importing keys.  This does not affect the
KDF operation used to derive concrete PSKs."

If someone deprecates the use of a hash function inside TLS 1.3 (used by Transcript-Hash and HKDF), does it then makes sense to keep deriving keys outside of TLS with that same deprecated hash function?

- "To mitigate these problems, external PSKs can be bound to a specific hash function when used in TLS 1.3"

I would change to "are bound to a specific". If the application does not specify anything, the keys are bound to SHA-256.

Cheers,
John

-----Original Message-----
From: Christopher Wood <[email-masked]>
Date: Wednesday, 3 April 2019 at 16:25
To: John Mattsson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [TLS] Comments on draft-wood-tls-external-psk-importer-01

    

    

    

    

    Ditto.

    

    Best,
    Chris

---

From: "Christopher Wood" <[email-masked]>
Date: Thu, 04 Apr 2019 09:00:45 -0400

> I think "this requires both endpoints to adopt the change simultaneously" is a problem as it makes it impossible to introduce this mechanism in many existing deployments. I would expect a solution…

I think perhaps my response was unclear. In your scenario, adding key import support is essentially the same as adding a new PSK to a node. Some nodes may offer (or accept) the PSK, while others do not. Successful use of an imported PSK will only occur if both endpoints have imported the same PSK. Gradual deployment is possible.

> - Which label should be used by various versions of DTLS?

Likely the same labels as the TLS counterparts, since the label more or less specifies the *handshake* variant.

> If someone deprecates the use of a hash function inside TLS 1.3 (used by Transcript-Hash and HKDF), does it then makes sense to keep deriving keys outside of TLS with that same deprecated hash func…

No. If this deprecation occurs, then they would follow the advisory text and not use the old hash when importing keys.

> I would change to "are bound to a specific". If the application does not specify anything, the keys are bound to SHA-256.

Works for me. I’ll file an issue to track the change.

Thanks,
Chris

---

From: "Christopher Wood" <[email-masked]>
Date: Thu, 04 Apr 2019 09:18:41 -0400

> I think perhaps my response was unclear. In your scenario, adding key import support is essentially the same as adding a new PSK to a node. Some nodes may offer (or accept) the PSK, while others do…

To clarify further since this too may be misleading: This assumes the imported PSKs are offered alongside the existing external PSKs. So, to your previous question regarding simultaneous use of imported keys and external PSKs, gradual deployment is only applicable with stacks supporting 1.3 and 1.2, where imported keys apply to 1.3. Nodes supporting 1.2 and 1.3 without the imported keys will offer 1.2 PSKs, whereas nodes with imported keys will offer 1.2 and imported 1.3 PSKs.

You’re right that it’s not possible to deploy gradually if one is currently using external PSKs for only 1.3 or 1.2, wants to adopt the importer API, and is prohibited from using both imported and external PSKs at the same time.

> > To: John Mattsson <[email-masked]>
> > Cc: "[email-masked]" <TLS@ietf..org>
> > Modifying the key schedule was discussed in the context of [2].. At the 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Bill Frantz <[email-masked]>
Date: Thu, 4 Apr 2019 09:42:29 -0700

On 4/4/19 at 11:22 PM, [email-masked] (John 
Mattsson) wrote:

>I think "this requires both endpoints to adopt the change 
>simultaneously" is a problem as it makes it impossible to 
>introduce this mechanism in many existing deployments. I would 
>expect a solution that can be introduced gradually (some nodes 
>at a time) in existing deployments supporting RFC 8446 and/or 
>RFC 5246.

Having seen a successful deployment and migration to a new 
incompatible version of a protocol, I think we too rapidly 
dismiss the possibility. In security protocols, we gain a lot of 
simplicity, and therefore security, by not having a 
compatibility mode. I wrote a short paper about this deployment 
for an amateur radio publication which I have included below.

Cheers - Bill

-----------------------------------------------------

Flag Day with FT8

Bill Frantz, AE6JV
West Valley Amateur Radio Association
Northern California DX Club
Northern California Contest Club

Abstract

Recently a community of over 20,000 users did a conversion 
between release 1 and release 2 of a amateur radio digital 
communications protocol called FT8. The old version of the 
protocol was not compatible with the new version, resulting in a 
"flag day" event for users. However, the conversion was rapid 
and proceeded smoothly. Lessons from this conversion should be 
useful for other software projects.

--------------------------------------------------

Introduction

The new FT8 digital transmission mode has taken the amateur 
radio world by storm. Adoption has been overwhelmingly rapid, 
going from nothing at its first release in July 2017 to the most 
popular mode for many uses in December 2018.

FT8 is the invention of Steven Franke, K9AN, and Joe Taylor, 
K1JT. (Joe won the Nobel Prize in Physics laureate for his 
discovery with Russell Hulse of a "new type of pulsar, a 
discovery that has opened up new possibilities for the study of 
gravitation."[1]) It is a "weak signal" mode using 50 Hz 
bandwidth for each signal, and can decode stations that are 24 
dB below the voice signal bandwidth noise level.

It is an evolving protocol and has recently been through a major 
change, from 75 bit messages to 77 bit messages. When you make a 
major change in a computer protocol, and indeed, FT8 is a 
computer protocol, there are two ways to introduce the change. 
(1) You can code the new protocol to inter-operate with the old 
protocol, or (2) you can have a "Flag Day" where everyone 
changes to the new protocol at the same time. (A "flag day" is 
when everyone has to adopt the new protocol at about the same 
time or lose connection with those who have adopted it.)

Historically, computer engineers have avoided flag days like the 
plague. Getting everyone to change at the same time is almost 
impossible, and it is easier to design inter-operation. The FT8 
implementors made the other choice; to have a flag day. It is 
interesting examine why they made that choice and how they 
succeeded with that choice.

Bill Somerville, G4WJS reported on January 16, 2019 [2]

   "The situation with the 75-bit to 77-bit update of the FT8 
protocol has
   several constraints that are uncommon elsewhere and particularly
   uncommon when they are all combined, including:

   "1) It is a communications protocol where every user wishes 
to be able
   to communicate with any other, 2) the old version will not understand
   the new protocol, at least without an upgrade, 3) WSJT-X is FOSS
   [Freee Open Source Software] with no charges for use or 
upgrade, 4)
   the core WSJT development team is tiny and has no wish to support
   multiple GA [General Availability] versions.

   "Given these constraints and a desire not to consume extra valuable
   digital modes bandwidth, any opportunity for old protocol 
users who do
   not wish to upgrade should be avoided. Having a new version 
that still
   talks the old protocol just exacerbates the potential schism 
of users
   since it allows those reluctant to upgrade to continue using 
the old
   protocol, at least until the number of indecipherable signals which
   are QRM [interference] to their decoder overwhelms them."

Joe Taylor reported on January 17, 2019 [2]:

   "1. We published a schedule, three months in advance, 
specifying target
   dates for intermediate candidate releases for beta testing.  We
   publicized this schedule as widely as possible, and we stuck 
to it.

   "2. The first three candidate releases included "bi-lingual" capability
   for the old and new protocols.  This helped to encourage beta testing
   and feedback from interested users, and helped to show users that
   upgrading was a simple drop-in replacement.

   "3. Candidate releases 4 and 5 were "new protocol only".  
They allowed
   us to eliminate large amounts of obsolete code and fix most 
of the
   bugs introduced by these wholesale changes."

Operations are usually a lot more pleasant when everyone is 
running the same version of a protocol. As Bill Somerville notes 
above, keeping the community of users together has a significant 
long-term value.

Inter-operation logic tends to be buggy as noted by Joe Taylor 
above, and those problems "just go away" with a flag day. A flag 
day also allows a development team to concentrate on more 
valuable tasks.

Also, with only 77 bits in a message, spending a bit or several 
on a message format ID is very expensive. Considering that it 
takes 15 seconds to send each of these messages, and another 15 
seconds to receive the reply, every bit is precious.

Another consideration is that the old and new formats can 
coexist operating on different frequencies. They just can't talk 
to each other. People who haven't converted can still 
communicate with others who haven't converted, somewhat easing 
the need for everyone to change "at once". However seeing a lot 
of strong signals that can't be decoded is a significant 
incentive to find out what the problem is and fix it.

--------------------------------------------------

Changeover Time Line

So what was the result when the team announced they would have 
Release 2.0 available on December 10, 2018 and expected everyone 
to convert by January 1, 2019? In a word, success! From the 
wsjt-x developer email list:

Joe Tailor reported [3]:

   "Monitoring 20 meters just 3 hours after WSJT-X 2.0 had been released,
   I found that nearly half of the active stations were already 
using it.
   I made 18 QSOs [contacts] in about half an hour.

   "According to PSK Reporter* statistics, at least 1620 
callsigns have
   been making QSOs with the new version.  This is now ~7.5 
hours after
   the v2.0 GA release."

Dwight NS9I reported [4]: 70 q's [contacts] and all is well ... 
amazed at the activity, including DX [foreign stations] on all 
the bands.

On December 12, Tom OH6VDA reported [5]: And right now 
aproximately 8000 V2.0 users of a total of 21 000 WSJT-X users, 
according to Pskreporter.info#. :)

On December 12, Richard KF5OIM reported [6]: wjstx 2.0.0 has 
landed in the Fedora testing repositories for Fedora 28, 29, 
Rawhide and Fedora EPEL 7 (CentOS,SL,etc)

On December 12, Ted K9IMM reported [7]:

   I have a multi-band FT8 skimmer. It skims 7 bands from 160M-15M
   (excluding 60M).

   I converted the skimmer to V2.0.0 yesterday about this time.
   Ordinarily, my V1.9.1 spot rate was about 10,000-12,000 spots 
per day.
   In the last 24 hours my V2.0.0 spot rate is 7700/day.

   So...Either there are a huge amount of new FT8 users running V2.0.0,
   or users are converting to the new version at a very satisfyingly
   rapid rate.

   Pretty amazing for a release 2 days old.

On December 14, Joe Taylor reported [8]:
   This morning I ran an instance of WSJT-X v1.9.1 in parallel with
   WSJT-X 2.0.  An informal count of decodes in the old and new protocols
   shows far more activity using the new 77-bit messages.  Here 
are the
   rough statistics, given as the ratio of new- to old-style decodes:

   For FT8:
   -----------
   17m:  10:1
   20m:   3:1
   30m:   6:1
   40m   20:1

On December, 14, Charlie WD5BJT reported [9]: I mostly operate 
on the 6 meter band using FT-8. Of the many operators on the 
band last night, I decoded only two users of the old protocol.

On January 2, 2019, a late adopter reported [10]: My version of 
WSJT-X is 1.8.0  I don't decode anything, WF [Waterfall, a way 
of seeing all the signals on a band] clearly has big signals on 
it that come and go every 15 sec.  Do I need to upgrade?

--------------------------------------------------

Conclusions

This change was a very successful flag day. There is almost no 
one using the old version after the end of the cut-over period. 
There are almost no complaints about the need to change.

Things that made this success possible:

   Most of the usage of FT8 is concentrated in a small 
percentage of the users. This small percentage of users were 
early adopters. As a result, nearly half to the signals on one 
band were in the new format only 3 hours after the release of 
the new version.

   There were a number of features in the new version of the 
software that would attract users to convert. These included 
better classification of a received station's location (for 
people interested in long distance communication) and support 
for more kinds of on-the-air ham radio activities.

   Conversion was a simple drop-in replacement without a lot of 
effort required from the user.

   File data formats did not change except for the details of 
some debugging information. Information about contacts made with 
the old version were available to the new version.

   A use could easily switch back and forth between the old and 
new version, easing concerns of early adopters.

Software developers with similar advantages should give more 
consideration to having a flag day instead of including 
inter-operation code in their applications. A flag day might be 
particularly attractive if there is a strong desire to keep from 
splitting the user community, or if the development team is small.

--------------------------------------------------

* PSK Reporter is a world-wide amateur radio service which 
listens for digital signals and reports which ones it hears via 
the Internet. See: <https://pskreporter.info/> and <https://pskreporter.info/cgi-bin/pskstats.pl>

# PSK Reporter can take up to a week to notice that a station is 
using the new version.

--------------------------------------------------

Acknowledgements

Thanks to Joe Taylor K1JT and Bill Somerville G4WJS for their 
comments. Their insite into the development process was very 
valuable in developing this paper.

Thanks to Wolfgang Meister OE1MWW for information about PSK 
Reporter and other software supporting FT8.

Thanks to Gary Hinson ZL2iFB's "FT8 Operating Guide" 
<http://www.g4ifb.com/FT8_Hinson_tips_for_HF_DXers.pdf> for some 
of the early history of FT8

--------------------------------------------------

References

[1] <https://en.wikipedia.org/wiki/Joseph_Hooton_Taylor_Jr.>
[2] <https://sourceforge.net/p/wsjt/mailman/message/36519613/>
[3] <https://sourceforge.net/p/wsjt/mailman/message/36490442/>
[4] <https://sourceforge.net/p/wsjt/mailman/wsjt-devel/thread/35619a06-08ca-a82e-2b96-5784c5aa9285%40bayland.net/#msg36490399>
[5] <https://sourceforge.net/p/wsjt/mailman/wsjt-devel/thread/1419952134.2738348.1544608313582%40mail.yahoo.com/#msg36491719>
[6] <https://sourceforge.net/p/wsjt/mailman/wsjt-devel/thread/CAN3TeO2DJFcNO_XeK9jZSZtJJDNk0u_E3VkHqc2byg58PddjKA%40mail.gmail.com/#msg36492022>
[7] <https://sourceforge.net/p/wsjt/mailman/wsjt-devel/thread/003901d49258%24139b4ff0%243ad1efd0%24%40offex.com/#msg36492293>
[8] <https://sourceforge.net/p/wsjt/mailman/wsjt-devel/thread/49fe71f4-bf4c-4c9c-33ee-7d73c6620046%40princeton.edu/#msg36494001>
[9] <https://sourceforge.net/p/wsjt/mailman/wsjt-devel/thread/2015959274.4026.1544810692848%40wamui-dingo.atl.sa.earthlink.net/#msg36494040>
[10] Post to the Northern California Contest Club reflector on 
January 2, 2019 at 1533 PDT.

-----------------------------------------------------

---------------------------------------------------------------------------
Bill Frantz        |"After all, if the conventional wisdom was 
working, the
408-356-8506       | rate of systems being compromised would be 
going down,
www.pwpconsult.com | wouldn't it?" -- Marcus Ranum

---

From: John Mattsson <[email-masked]>
Date: Tue, 9 Apr 2019 18:53:09 +0000

Hi Chris,

Thanks for the discussion. Would be good if a future version:

- Made clear if the imported PSKs MUST NOT / SHOULD NOT / MAY / SHOULD / MUST be offered alongside the existing external PSKs. While offering both would make a migration path possible I don’t think it is the way to go.
- If MUST NOT, the document should maybe also state what the client do if it receives a unknown_psk_identity alert, is it allowed to try again with the external (non-imported identity) or is it forbidden to do so?

- Made clear if use of draft-wood-tls-external-psk-importer is a property of the TLS implementation (i.e. used on all PSK) or a property of the external PSK (i.e. only used on keys with this property).

- State that "tls12" is used for DTLS 1.2 and "tls13" is used for DTLS 1.3.

Cheers,
John

From: TLS <[email-masked]> on behalf of Christopher Wood <[email-masked]>
Date: Thursday, 4 April 2019 at 15:19
To: "[email-masked]" <[email-masked]>
Subject: Re: [TLS] Comments on draft-wood-tls-external-psk-importer-01

To clarify further since this too may be misleading: This assumes the imported PSKs are offered alongside the existing external PSKs. So, to your previous question regarding simultaneous use of imported keys and external PSKs, gradual deployment is only applicable with stacks supporting 1.3 and 1.2, where imported keys apply to 1.3. Nodes supporting 1.2 and 1.3 without the imported keys will offer 1.2 PSKs, whereas nodes with imported keys will offer 1.2 and imported 1.3 PSKs..

Thanks,
Chris

>  > missing from TLS 1.3..
>  > external PSK..

---

From: "Christopher Wood" <[email-masked]>
Date: Tue, 09 Apr 2019 21:36:04 -0400

Hi John,

> Thanks for the discussion. Would be good if a future version:

Likewise -- thank you for the comments!

> - Made clear if the imported PSKs MUST NOT / SHOULD NOT / MAY / SHOULD 
> / MUST be offered alongside the existing external PSKs. While offering 
> both would make a migration path possible I don’t think it is the way 
> to go.

Yep, we'll clear this up. (I'm currently leaning towards *not* allowing it.)

> - If MUST NOT, the document should maybe also state what the client do 
> if it receives a unknown_psk_identity alert, is it allowed to try again 
> with the external (non-imported identity) or is it forbidden to do so?

Good question! I'll file an issue to track and resolve this. 

> - Made clear if use of draft-wood-tls-external-psk-importer is a 
> property of the TLS implementation (i.e. used on all PSK) or a property 
> of the external PSK (i.e. only used on keys with this property).

It's the former, for all external PSKs. We'll try to clarify this.

> - State that "tls12" is used for DTLS 1.2 and "tls13" is used for DTLS 1.3.

+1 

Thanks again for the comments and review.

Best,
Chris