Draft: draft-ietf-tls-tls13

Commentary: 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 .
Paragraph (version A):
A list of extensions.  Note that only extensions offered by the
client can appear in the server's list.  In TLS 1.3 as opposed to
previous versions of TLS, the server's extensions are split
between the ServerHello and the EncryptedExtensions encrypted-
extensions message.  The ServerHello MUST only include extensions
which are required to establish the cryptographic context.
Paragraph (version B):
A list of extensions.  Note that only extensions offered by the
client can appear in the server's list.  In TLS 1.3 as opposed to
previous versions of TLS, the server's extensions are split
between the ServerHello and the EncryptedExtensions encrypted-
extensions message.  The ServerHello MUST only include extensions
which are required to establish the cryptographic context.
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.
Paragraph (version A):
If PSK is being used, the server's version of the PreSharedKey
extension (indicating the PSK the client is using).
Paragraph (version B):
"key_share" if (EC)DHE is being used.
Paragraph (version B):
If PSK is being used, the server's version of the "pre_shared_key"
(indicating the PSK the client is using).
Paragraph (version B):
The EncryptedExtensions message simply contains any extensions
which should be protected, i.e., any which are not needed to
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
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.
Paragraph (version A):
TLS ExtensionType Registry: Future values are allocated via IETF
Consensus RFC2434.  IANA has updated this registry to include the
"signature_algorithms" extension and its corresponding value (see
hello-extensions).
Paragraph (version B):
TLS ExtensionType Registry: Future values are allocated via IETF
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.