Change:
Does it make sense to just have a tri-state column for TLS 1.3 on the extensions registry: "key" - key determining parameters "encrypted" - encrypted "forbidden" - not for use in TLS 1.3
"go" as in whether they are plaintext or go into the EncryptedExtensions block.

Discussion:
between the ServerHello and the EncryptedExtensions encrypted- extensions message.  The ServerHello MUST only include extensions which are required to establish the cryptographic context. <ins> Currently the only such extensions are "key_share" and "pre_shared_key".  Clients MUST check the ServerHello for the presence of any forbidden extensions and if any are found MUST terminate the handshake with a "illegal_parameter" alert. </ins> 6.3.1.3.

to provide enough information to allow the server to decrypt the traffic without negotiation.  This is accomplished by having the client indicate the "cryptographic determining parameters" in its <del> ClientHello, which are necessary to decrypt the client's packets. This includes the following values: </del> <ins> ClientHello, which are necessary to decrypt the client's packets (i.e., those present in the ServerHello).  This includes the following values: </ins> The cipher suite identifier. <del> If PSK is being used, the server's version of the PreSharedKey extension (indicating the PSK the client is using). </del> <ins> "key_share" if (EC)DHE is being used. </ins> <del> [[TODO: Are there other extensions we need?  I've gone over the list and I don't see any, but...]] [[TODO: This should be the same list as what you need for !EncryptedExtensions.  Consolidate this list.]] </del> <ins> If PSK is being used, the server's version of the "pre_shared_key" (indicating the PSK the client is using). </ins> 6.3.2.5.2.

establish the cryptographic context.  The same extension types MUST NOT appear in both the ServerHello and EncryptedExtensions. If the same extension appears in both locations, the client MUST <del> rely only on the value in the EncryptedExtensions block.  [[OPEN ISSUE: Should we just produce a canonical list of what goes where and have it be an error to have it in the wrong place?  That seems simpler.  Perhaps have a whitelist of which extensions can be unencrypted and everything else MUST be encrypted.]] </del> <ins> rely only on the value in the EncryptedExtensions block.  All server-sent extensions other than those explicitly listed in server-hello or designated in the IANA registry MUST only appear in EncryptedExtensions.  Extensions which are designated to appear in ServerHello MUST NOT appear in EncryptedExtensions.  Clients MUST check EncryptedExtensions for the presence of any forbidden extensions and if any are found MUST terminate the handshake with a "illegal_parameter" alert. </ins> Structure of this message:

allocation policy (unchanged from RFC4366) is listed below: TLS ExtensionType Registry: Future values are allocated via IETF <del> Consensus RFC2434.  IANA has updated this registry to include the "signature_algorithms" extension and its corresponding value (see hello-extensions). </del> <ins> Consensus RFC2434.  IANA [shall update/has updated] this registry to include the "key_share", "pre_shared_key", and "early_data" extensions as defined in this document.  IANA [shall update/has updated] this registry to include an "TLS 1.3" column with the following three values: "Clear", indicating that they shall be in the ServerHello "Encrypted", indicating that they shall be in the EncryptedExtensions block, and "Forbidden" indicating that they are not used in TLS 1.3.  This registry [shall be/has been] initially populated with the values in this document. </ins> This document also uses two registries originally created in RFC4492. IANA [should update/has updated] it to reference this document.  The