Draft: draft-ietf-tls-tls13

Commentary: There are many sorts of TLS middleboxes ( CDN , decrypting proxy , local antivirus , actual attack , etc ) , with acceptabilities ranging from reasonable to extremely questionable to a terrible idea . ( Categorization is left as an exercise to the reader . ) They also have very different security considerations . Fundamentally , TLS secures a connection between two endpoints . As such , we have something to say about the endpoint - to - endpoint connections that make up such a system , but we should n't imply this section is sufficient , merely necessary . Adjust the text accordingly . I wrote " intermediary " in the original PR , predictively based on PR . Since the spec seems to have settled on " middlebox " , align the terminology . ( I do n't really care what is used , just that it is consistent . ) 
 Ah yeah . Fixed . I used " implementations " for this one because there is an " ( also known as ossification ) " parenthetical and , in the general case , endpoints can cause ossification too . Even here , I dunno , maybe a sufficiently confused endpoint will do something silly there . :-) 
 Should the legacysessionid description , which also mentions intermediaries , also be tweaked?Thanks !
Paragraph (version A):
Versions of TLS before TLS 1.3 supported a "session resumption"
feature which has been merged with Pre-Shared Keys in this version
(see resumption-and-psk).  A client which has a cached session ID
set by a pre-TLS 1.3 server SHOULD set this field to that value.
In compatibility mode (see middlebox) this field MUST be non-
empty, so a client not offering a pre-TLS 1.3 session MUST
generate a new 32-byte value.  This value need not be random but
SHOULD be unpredictable to avoid but SHOULD be unpredictable to
avoid intermediaries fixating on a specific value (also known as
ossification).  Otherwise, it MUST be set as a zero length vector
(i.e., a single zero byte length field).
Paragraph (version B):
Versions of TLS before TLS 1.3 supported a "session resumption"
feature which has been merged with Pre-Shared Keys in this version
(see resumption-and-psk).  A client which has a cached session ID
set by a pre-TLS 1.3 server SHOULD set this field to that value.
In compatibility mode (see middlebox) this field MUST be non-
empty, so a client not offering a pre-TLS 1.3 session MUST
generate a new 32-byte value.  This value need not be random but
SHOULD be unpredictable to avoid implementations fixating on a
specific value (also known as ossification).  Otherwise, it MUST
be set as a zero length vector (i.e., a single zero byte length
field).
Paragraph (version A):
This section describes invariants that TLS endpoints and
intermediaries MUST follow.  It also applies to earlier versions,
which assumed these rules but did not document them.
Paragraph (version A):
TLS is designed to be securely and compatibly extensible.  Newer
clients or servers, when communicating with newer peers, SHOULD
negotiate the most preferred common parameters.  The TLS handshake
provides downgrade protection: Intermediaries passing traffic between
a newer client and newer server without terminating TLS should be
unable to influence the handshake (see security-handshake).  At the
same time, deployments update at different rates, so a newer client
or server MAY continue to support older parameters, which would allow
it to interoperate with older endpoints.
Paragraph (version B):
This section describes invariants that TLS endpoints and middleboxes
MUST follow.  It also applies to earlier versions, which assumed
these rules but did not document them.
Paragraph (version B):
TLS is designed to be securely and compatibly extensible.  Newer
clients or servers, when communicating with newer peers, SHOULD
negotiate the most preferred common parameters.  The TLS handshake
provides downgrade protection: Middleboxes passing traffic between a
newer client and newer server without terminating TLS should be
unable to influence the handshake (see security-handshake).  At the
same time, deployments update at different rates, so a newer client
or server MAY continue to support older parameters, which would allow
it to interoperate with older endpoints.
Paragraph (version A):
An intermediary which terminates a TLS connection MUST behave as a
compliant TLS server (to the original client), including having a
certificate which the client is willing to accept, and as a
compliant TLS client (to the original server), including verifying
the original server's certificate.  In particular, it MUST
generate its own ClientHello containing only parameters it
understands, and it MUST generate a fresh ServerHello random
value, rather than forwarding the endpoint's value.
Paragraph (version B):
A middlebox which terminates a TLS connection MUST behave as a
compliant TLS server (to the original client), including having a
certificate which the client is willing to accept, and as a
compliant TLS client (to the original server), including verifying
the original server's certificate.  In particular, it MUST
generate its own ClientHello containing only parameters it
understands, and it MUST generate a fresh ServerHello random
value, rather than forwarding the endpoint's value.
Paragraph (version A):
In this scenario, the intermediary is a pair of TLS endpoints for
purposes of protocol requirements and security analysis.
Paragraph (version A):
An intermediary which forwards ClientHello parameters it does not
understand MUST NOT process any messages beyond that ClientHello.
It MUST forward all subsequent traffic unmodified.  Otherwise, it
may fail to interoperate with newer clients and servers.
Paragraph (version A):
Forwarded ClientHellos may contain advertisements for features not
supported by the intermediary, so the response may include future
TLS additions the intermediary does not recognize.  These
additions MAY change any message beyond the ClientHello
arbitrarily.  In particular, the values sent in the ServerHello
might change, the ServerHello format might change, and the
TLSCiphertext format might change.
Paragraph (version A):
The design of TLS 1.3 was constrained by widely-deployed non-
compliant TLS intermediaries (see middlebox), however it does not
relax the invariants.  Those intermediaries continue to be non-
compliant.
Paragraph (version B):
Note that TLS's protocol requirements and security analysis only
apply to the two connections separately.  Safely deploying a TLS
terminator requires additional security considerations which are
beyond the scope of this document.
Paragraph (version B):
An middlebox which forwards ClientHello parameters it does not
understand MUST NOT process any messages beyond that ClientHello.
It MUST forward all subsequent traffic unmodified.  Otherwise, it
may fail to interoperate with newer clients and servers.
Paragraph (version B):
Forwarded ClientHellos may contain advertisements for features not
supported by the middlebox, so the response may include future TLS
additions the middlebox does not recognize.  These additions MAY
change any message beyond the ClientHello arbitrarily.  In
particular, the values sent in the ServerHello might change, the
ServerHello format might change, and the TLSCiphertext format
might change.
Paragraph (version B):
The design of TLS 1.3 was constrained by widely-deployed non-
compliant TLS middleboxes (see middlebox), however it does not relax
the invariants.  Those middleboxes continue to be non-compliant.