Draft: draft-ietf-tls-tls13

Commentary: Some fixes for things I did n't catch when I checked for typos in the big patch last time . Of note , you 're missing a closing brace for the select in " PreSharedKeyExtension " and a semicolon after " KnownConfigurationExtension " . I also corrected things to match the existing ( admittedly unusual ) indentation style of the document and put quotes around the extension IDs you missed . ( some had them ; some did n't ) 
 Ok , spaces between cases reverted . I also a similar bit of whitespace in another new extension .
Paragraph (version A):
When the client and server mutually agree upon a known configuration
via this mechanism, then the Static Secret (SS) is computed based on
the server's (EC)DHE key from the identified configuration and the
client's key found in the ClientKeyShare.  If no key from an
acceptable group is in the ClientKeyShare, the server MUST ignore the
known_configuration extension.  When this mechanism is used, the
server MUST NOT send a Certificate/CertificateVerify message unless
the ServerConfiguration message is also sent.
Paragraph (version A):
When the known_configuration data extension is in use, the handshake
hash is extended to include the server's configuration data and
certificate (see the-handshake-hash) so as to tightly bind them
together.
Paragraph (version A):
The pre_shared_key extension is used to indicate the identity of the
pre-shared key to be used with a given handshake in association with
a PSK or (EC)DHE-PSK cipher suite (see RFC4279 for background).
Paragraph (version B):
When the client and server mutually agree upon a known configuration
via this mechanism, then the Static Secret (SS) is computed based on
the server's (EC)DHE key from the identified configuration and the
client's key found in the ClientKeyShare.  If no key from an
acceptable group is in the ClientKeyShare, the server MUST ignore the
"known_configuration" extension.  When this mechanism is used, the
server MUST NOT send a Certificate/CertificateVerify message unless
the ServerConfiguration message is also sent.
Paragraph (version B):
When the "known_configuration" data extension is in use, the
handshake hash is extended to include the server's configuration data
and certificate (see the-handshake-hash) so as to tightly bind them
together.
Paragraph (version B):
The "pre_shared_key" extension is used to indicate the identity of
the pre-shared key to be used with a given handshake in association
with a PSK or (EC)DHE-PSK cipher suite (see RFC4279 for background).
Paragraph (version A):
After the server has received the client Finished message, it MAY
send a NewSessionTicket message.  This message MUST be sent before
the server sends any application data traffic, and is encrypted under
the application traffic key.  This message creates a pre-shared key
(PSK) binding between the resumption master secret and the ticket
label.  The client MAY use this PSK for future handshakes by
including it in the pre_shared_key extension in its ClientHello (pre-
shared-key-extension) and supplying a suitable PSK cipher suite.
Paragraph (version B):
After the server has received the client Finished message, it MAY
send a NewSessionTicket message.  This message MUST be sent before
the server sends any application data traffic, and is encrypted under
the application traffic key.  This message creates a pre-shared key
(PSK) binding between the resumption master secret and the ticket
label.  The client MAY use this PSK for future handshakes by
including it in the "pre_shared_key" extension in its ClientHello
(pre-shared-key-extension) and supplying a suitable PSK cipher suite.