1.2.  draft-05 Prohibit SSL negotiation for backwards compatibility. The higher-level protocol used to process the enclosed fragment. <del> The version of the protocol being employed.  This document describes TLS Version 1.3, which uses the version { 3, 4 }.  The version value 3.4 is historical, deriving from the use of {3, 1} for TLS 1.0.  (See record-layer-1.)  Note that a client that supports multiple versions of TLS may not know what version will be employed before it receives the ServerHello.  See backward- compatibility for discussion about what record layer version number should be employed for ClientHello. </del>  The length (in bytes) of the following TLSPlaintext.fragment.  The independent block to be dealt with by the higher-level protocol specified by the type field.  Implementations MUST NOT send zero-length fragments of Handshake or Alert types.  Zero-length fragments of Application data MAY be sent as they are potentially useful as a traffic analysis countermeasure. described in Section 2.1 of RFC5116.  The key is either the client_write_key or the server_write_key. <del> %%% Record Layer struct { ContentType type; ProtocolVersion version; uint16 length; opaque </del>  nonce_explicit[SecurityParameters.record_iv_length]; aead-ciphered struct { opaque content[TLSPlaintext.length]; } fragment; } TLSCiphertext; The type field is identical to TLSPlaintext.type. <del> The version field is identical to TLSPlaintext.version. </del>  The length (in bytes) of the following TLSCiphertext.fragment. The version of the TLS protocol by which the client wishes to communicate during this session.  This SHOULD be the latest (highest valued) version supported by the client.  For this <del> version of the specification, the version will be 3.4 (see backward-compatibility for details about backward compatibility). </del>  A client-generated random structure.

This does the following: 1) Reorganize the backwards compatibility section into subsections for easier readability 2) Freezes the ClientHello record layer version to TLS 1.0 (its effective compatible version) 3) Adds explicit requirement that all other record layer versions match the negotiated version This plus PR should be sufficient to close issue . The record layer requirements were proposed by Brian Smith on the list. URL (also mentioned by him in other discussions)
I don't generally use capitals and periods for sentence fragments in parentheticals. Full sentences generally shouldn't be in parentheticals. Other instances of "(see _)" prefer a lowercase 's' and no period, but it's not consistent throughout the whole document. I'd lean towards that, however upon inspection I don't think this cross reference is useful at all. I'll just remove it. I'll also correct the embarrassingly stupid typo. (spellchecker doesn't work in web interface) I'm going to refactor this slightly to move more info down to the end of the section rather than cramming everything in here.
Can you think of a good external reference to cite for the buggy server blurb? If it's a "complex topic beyond the scope of this document" then it ideally should reference more information elsewhere.
Re: other vendors' ClientHello version strategies: It occurs to me that we might prefer to make the ClientHello record version a SHOULD rather than a MUST to allow for some flexibility in implementation. If anyone is sending different versions in different instances to cope with specific server bugs, that may not need to be completely prohibited. (if not needed, then a MUST is probably appropriate)
RE: "This document URL SSL 3.0." I disagree that it is unnecessary. Whilst redundant, I think the reason why TLS uses weird version numbers needs to be stated somewhere in this document. Moving it to the backwards compatibility section is an option if you think it's in the way up here. RE: second section of record layer version text I have that set aside due to formatting concerns. The "version" section is indented in a list and putting lots of text in there risks cluttering things up a bit. I'd prefer to have the minimum definition and requirements under that heading and additional issues separately, in order to maximize readability.
Well crud. I rebased this and GitHub dropped the comments from NAME They haven't vanished entirely into the aether, just not shown above in the threading here. For reference, imagine there are proper "commented on an outdated diff" lines above and that I didn't confuse GitHub and am not talking to myself. I shall endeavor to be less of a GitHub noob in the future. URL URL URL URL URL URL
It might be simpler to just change to: TLS clients MUST set this version to { 3, 1 } for the initial ClientHello and all alert messages. For the ServerHello and all other TLS records this MUST be equal to the negotiated version. Additionally, dropping the version field from TLSCipherText entirely might be worth considering, but that's outside the scope of this here.
(I assume you mean s/clients/implementations/? Otherwise there's still an unspecified hole.) All alerts period, or just those before version negotiation? OpenSSL, after version negotiation, will currently reject any record (of whatever type) whose version does not match the negotiated version. Go's crypto/tls does the same thing. I haven't done a survey of other implementations yet. It can certainly change for TLS 1.3. But, as an implementer, I would prefer that field be hammered down in a way that can advise older versions, whether or not 1.3 additionally clamps it post-negotiation. If just those before version negotiation, I think a cleaner statement of that rule is: Prior to version negotiation, this version MUST by {3, 1}. This includes the initial ClientHello and any alerts sent during version negotiation. After version negotiation, this MUST be equal to the negotiated version. This includes the ServerHello and all following records. This is fairly straightforward and clean. The record-layer initializes in "proto TLS" which uses {3, 1}. Then it switches one to a concrete version. The one ambiguity left is a client's alert. That one is sent when one side has done negotiation, but not the other. Which is where the trickiness I mentioned comes up with existing servers[]. Whether the complexity is worth bothering with is another matter. (For context, I'm coming at this from having recently rewritten BoringSSL's version negotiation logic. 1.2's failure to clearly specify version negotiation was a huge pain point.) [] For completeness, OpenSSL client has its own quirks. If the client has a minimum version > TLS 1.0 AND the server sends some alert with record-layer {3, 1}, the client will fail to read it. OpenSSL client negotiates based on record-layer version, not ServerHello. But that implementation is sufficiently weird that I don't think it's worth bothering about. See links in .
I was proposing {3,1} for all alerts, yes. (even old versions should be able to parse new; an unknown error could just be generically acted on) However, if there are implementations that would find this inconsistent with current behavior, then I agree it's not worth it. I like the language you suggested. It deals with the error cases and is quite clear. (modulo the typo ;) To deal with the protocol_version case, this might cover everything: Prior to version negotiation, this value MUST be { 3, 1 }. This includes the ClientHello, records sent during negotiation, and errors aborting the negotiation. After version negotiation, this MUST be equal to the negotiated version. This includes the ServerHello and all following records.
"records sent during negotiation" would count EarlyDataExtension records as well. Arguably this should be { 3, 4 }, but I don't think it's worth the complexity.
Version negotiation is completed by the first packet that the server sends (ie typically ServerHello), and the client typically only sends one packet if it cares about compatibility with versions prior to TLS 1.3, so forcing the packet version to {3, 1} for the ClientHello should be sufficient.
Per proposed resolution at interim, we can now simplify things down to one frozen and deprecated value. This is the ideal solution, IMO. In addition to updates for this, I've also renamed the field to "record_version" instead of just "version" as people easily mix up the various version fields. It now has a different expected behavior, so a different name is appropriate.
I'm fine with freezing it going forward (it means that someday in the far far future perhaps we can forget about this craziness altogether). But note that implementations supporting TLS < 1.3 will still need to do a swap when negotiating older versions. Existing clients and servers (including anything derived from OpenSSL) will reject post-version-negotiation records that don't have the right record-layer version. I don't know if advice on that front belongs in this draft or elsewhere or nowhere, but it is a concern implementations will have for a while.
Good point. I've updated backwards compatibility section for that.
More fixes and rebasing.
Note that I expect a new version negotiation mechanism implemented via an extension will be desired in order to deal with TLS 1.3 intolerance, and thus parts of this will be changed again. ClientHello.client_version would most likely be frozen to {3,3} in such a mechanism. That, however, is outside the scope of this PR which is to revise the existing backwards compatibility and freeze the record layer version.
(Apologies if this is the wrong medium. I wasn't sure if issues here or emails to the list were preferred since these aren't huge changes.) How version negotiation interacts with session resumption isn't said explicitly. Two little things that probably should be fixed: On the server, clarify that you MUST NOT resume a session at a version other than the original one. Instead, ignore the offered session and do a full handshake. This is easy to justify: every client (I tested NSS, OpenSSL, SecureTransport, and SChannel) will fail the handshake if the server tries to mismatch. It's also weird. (Say a future TLS version changed the master secret size...) Still, OpenSSL happily did so until . On the client, RFC 5246, E.1 has this little paragraph that seems to have carried over into 1.3. This is terrible advice. The parenthetical bit is wrong, but I would push for dropping it completely. The server may have changed, there may be multiple differently-configured servers behind that host, the session may have been established under fallback conditions, etc. OpenSSL takes it to an and . (I ended up completely rewriting this bit for BoringSSL.) NSS in something less catastrophic but still has the second "sticky fallback" failure mode.
I support removing that text. See also earlier discussion: URL URL Note that when a client does not consistently use the same ClientHello.clientversion, it should probably avoid attempting to resume a session X if it used a different ClientHello.clientversion for the connection that created session X than it is attempting to use in the current ClientHello. The consequence of this is that these clients should store ClientHello.clientversion in the session cache entry. However, it is better for them to always consistently set ClientHello.clientversion to TLS 1.2.
Having generic text to take care when mixing session caches between contexts with different parameters is probably worthwhile yeah. Sharing a session cache between a pile of sockets that, say, turn off AEADs and a pile that don't is also iffy. The clientversion seems rather specific requirement to put in, and requiring TLS impls to store the entire ClientHello in the session cache seems a bit much. I actually don't see what doing just the clientversion buys for the extra state, at least in contexts where a browser does it. Are you thinking to do that to account for the NSS clientversion clamping behavior, the old OpenSSL server one when combined with fallbacks, or something else? If the NSS side, that would mean NSS never resumes sessions on any but the highest version. It should just remove that logic; neither SChannel nor Secure Transport did it when I tested. Chrome + BoringSSL doesn't either and we haven't had problems. (It's hit stable on Mac and beta on Windows.) If the old OpenSSL server behavior (and without FALLBACKSCSV) and you should have negotiated a stronger TLS-1.2-only cipher, an attacker could just trigger the fallback again anyway, so we're not gaining much. That seems best fixed on the server (and has been now). In fact, if the server wants to be extra fancy, it could simulate picking a new cipher and only accept the session if that matched. But probably expiring old sessions when changing server config works just as well there. (That may also be worth some text: servers should take care when considering old sessions across a server config change.)
I mean this (acting as the client): Decide what number (e.g. TLS 1.2) you are going to put in ClientHello.clientversion and what cipher suites you are going to send in the ClientHello. Search the session cache for a matching entry, where the session was established on a connection where ClientHello.clientversion matches the ClientHello.clientversion you picked in the previous step, and where the cipher suite for the cached session matches a cipher suite in the set of cipher suites you've enabled for the current ClientHello. Note that we're matching ClientHello.clientversion to ClientHello.clientversion, NOT to the version that was negotiated (ServerHello.serverversion). If the server attempts to resume the session with a different serverversion or a different cipher suite, then something's gone very wrong; bail! The idea here is to avoid cases where the server may do strange things like use a different ServerHello.serverversion or a different cipher suite than what was originally negotiated. As you mentioned, the logic I described isn't enough to prevent all silliness, but I think it would avoid most cases.
We removed resumption entirely as of draft-07 so I think this is OBE.
It's renegotiation that was removed. This might still be relevant.
Well, we removed explicit resumption as well, and at least technically you could do PSK-resumption with different cipher suites and/or versions. I agree. But, my conclusion is that the TLS specification is wrong, and that that advice should be dropped from it and ignored by clients, because it enables this scenerio. I also think that the spec should be changed to require servers to never resume a session for a version lower than min(ClientHello.version, ), for similar reasons. In fact, your draft would be a good place to tell clients that they SHOULD NOT follow that advice in the TLS specifications. The current logic in your draft says that if the client doesn't downgrade ClientHello.clientversion to equal the version in the resumed session, then it must send the TLSDOWNGRADESCSV if ClientHello.clientversion is less than the highest version that it supports. That is the correct logic. The way it is written has made people think that TLSDOWNGRADESCSV is never supposed to be sent during resumption handshakes, which is why it is good to clarify it. OK. Cheers, Brian
, Bodo Moeller wrote: Right. In general, a resumption ClientHello SHOULD be just like a non-resumption ClientHello, except for the presence of the session ID and/or session ticket, because a resumption ClientHello is potentially the start of a full handshake. The TLS specs (TLS 1.2, in this case) say: Whenever a client already knows the highest protocol version known to a server (for example, when resuming a session), it SHOULD initiate the connection in that native protocol. However, actually the client does not ever know the highest protocol version the server supports, because the server may have expanded its version support since the last time the client contacted it. But, the consequence of that sentence is that at least NSS sends the session version as clientversion instead of its actual max supported version. I think that is wrong. However, it isn't clear if there are compatibility issues with changing that. I had thought that NSS was changed to use the session version for ClientHello.clientversion during resumption for compatibility reasons. However, looking at the change history, it appears to be the case that that change was made coincidentally with a compatibility fix for renegotiation, not initial resumption handshakes. So, it may be the case that it is already safe to always send the max supported version as client_version in an initial resumption handshake, without any indication from the server, even in the non-secure fallback case. It would require some implementation to make that change and test the compatibility to know for sure. Cheers, Brian
Dave Garrett wrote: It would be best to have your change do exactly that, by shortening the remaining text to: Implementations MUST NOT send or accept an SSL version 2.0 compatible CLIENT-HELLO. Implementations MUST NOT send or accept TLS records with a version less than { 3, 0 }. Note the suggestion to use the term "records" instead of "messages". I think further changes can be made to tighten up the text regarding allowed record versions, but those changes are more open for debate. For example, we might say that the ClientHello's record version MUST be { 3, 1 } and that the version field in all other records MUST equal the negotiated version. But, again, this can be done on top of your changes. Cheers, Brian

1.2. <ins> draft-06 Prohibit RC4 negotiation for backwards compatibility. Freeze & deprecate record layer version field. </ins> draft-05 Prohibit SSL negotiation for backwards compatibility. The higher-level protocol used to process the enclosed fragment.  <ins> The protocol version the current record is compatible with.  This value MUST be set to { 3, 1 } for all records.  This field is deprecated and MUST be ignored for all purposes. </ins> The length (in bytes) of the following TLSPlaintext.fragment.  The independent block to be dealt with by the higher-level protocol specified by the type field. <ins> This document describes TLS Version 1.3, which uses the version { 3, 4 }.  The version value 3.4 is historical, deriving from the use of { 3, 1 } for TLS 1.0 and { 3, 0 } for SSL 3.0.  In order to maximize backwards compatibility, the record layer version identifies as simply TLS 1.0.  Endpoints supporting other versions negotiate the version to use by following the procedure and requirements in backward-compatibility. </ins> Implementations MUST NOT send zero-length fragments of Handshake or Alert types.  Zero-length fragments of Application data MAY be sent as they are potentially useful as a traffic analysis countermeasure. described in Section 2.1 of RFC5116.  The key is either the client_write_key or the server_write_key.  <ins> %%% Record Layer struct { ContentType type; ProtocolVersion record_version = { 3, 1 }; /* TLS v1.x */ uint16 length; opaque </ins> nonce_explicit[SecurityParameters.record_iv_length]; aead-ciphered struct { opaque content[TLSPlaintext.length]; } fragment; } TLSCiphertext; The type field is identical to TLSPlaintext.type.  <ins> The record_version field is identical to TLSPlaintext.record_version and is always { 3, 1 }. </ins> The length (in bytes) of the following TLSCiphertext.fragment. The version of the TLS protocol by which the client wishes to communicate during this session.  This SHOULD be the latest (highest valued) version supported by the client.  For this  <ins> version of the specification, the version will be 3.4.  (See backward-compatibility for details about backward compatibility.) </ins> A client-generated random structure.


For secp256r1, secp384r1 and secp521r1, the contents are the serialized value of the following struct:  X and Y respectively are the binary representations of the X and Y values in network byte order.  There are no internal length markers, so each number representation occupies as many octets as implied by

Fix the spacing in and add it to Appendix B.3.1. Add missing space in .

For secp256r1, secp384r1 and secp521r1, the contents are the serialized value of the following struct: <ins> %%% Key Exchange Messages </ins> X and Y respectively are the binary representations of the X and Y values in network byte order.  There are no internal length markers, so each number representation occupies as many octets as implied by


The "post_handshake_auth" extension is used to indicate that a client is willing to perform post-handshake authentication post-handshake- <del> authentication.  Servers MUST not send a post-handshake </del>  CertificateRequest to clients which do not offer this extension. Servers MUST NOT send this extension. connection with an "unexpected_message" alert. The presence of padding does not change the overall record size <del> limitations - the full encoded TLSInnerPlaintext MUST not exceed 2^14 octets.  If the maximum fragment length is reduced, as for example by the max_fragment_length extension from RFC6066, then the reduced limit applies to the full plaintext, including the padding. </del>  Selecting a padding policy that suggests when and how much to pad is a complex topic and is beyond the scope of this specification.  If

The TLSPlaintext size is at most 2^14, so the TLSInnerPlaintext must be at least one more to fit the content type. This matches with the end of the record payload protection section.
Nice catch! We also misread that and applied the check to the wrong end to begin with, but the +1 seems a good idea anyway. Just seems generally simpler if TLS 1.3 doesn't have a pesky version-specific -1 in figuring out how much data can fit in an outgoing record.
Would be nice to have a new test in bogo that checks for rejection of TLSPlaintext having a size of 2^14+2 (or 2^14+1 in case of TLS 1.2).
Yup, will certainly add a test when we fix it. (Though I'll wait for this PR to either go in or be rejected just to have a ruling on whether we should have a +1 in there.)
So, if we go with 2^14+1 for sizeof(TLSInnerPlaintext), that is fine. That means that you can (absent padding) expect to be able to send 2^14 octets in every record, across every TLS version. The issue that this causes is one for the record size limit draft. The valid maximum for that will be 2^14 in TLS 1.2 and earlier, but 2^14+1 in TLS 1.3. That's OK, but I'll need to change that draft to make that observation. We already need to allow for larger values in case an extension expands the record size, so this will be a good test for that code. It's also going to be lots more annoying to write the cross-checking in code, but that is just how things go.
I had been using the text in : But the text in the very last sentence of says: Which doesn't really make sense. TLSPlaintext includes the record header as well as the encrypted data. I suppose that this is accurate if it means , but I misread this as the entire length of the structure. That's a minor point. TLSInnerPlaintext can be at most 2^14 (as defined in Section 5.4), which leads to a different limit of 2^14-1 for URL Should we instead say that 2^14+256 is the limit and the AEAD expansion is 256 octets instead of 255? Leading me to think that something along these lines is what should go in Section 5.2: Or something like that.
See
Fixed
See URL And URL Section A.4.2 says: It should say: The definition in Section 7.4.4 (which includes the "supportedsignaturealgorithms" field) is the correct one (confirmed by Eric Rescorla on 2009-02-27) The supportedsignaturealgorithms field is a variable length array. As such ceiling and floor should be specified, and they should be multiple of the base type (which is two bytes long in this case).
This change conflates two things: an editorial fix for "MUST not" instances, and the +1 tweak. These are both OK though, and I think that this is the right answer to the problem.

The "post_handshake_auth" extension is used to indicate that a client is willing to perform post-handshake authentication post-handshake-  <ins> authentication.  Servers MUST NOT send a post-handshake </ins> CertificateRequest to clients which do not offer this extension. Servers MUST NOT send this extension. connection with an "unexpected_message" alert. The presence of padding does not change the overall record size  <ins> limitations - the full encoded TLSInnerPlaintext MUST NOT exceed 2^14 + 1 octets.  If the maximum fragment length is reduced, as for example by the max_fragment_length extension from RFC6066, then the reduced limit applies to the full plaintext, including the content type and padding. </ins> Selecting a padding policy that suggests when and how much to pad is a complex topic and is beyond the scope of this specification.  If


removing any PSKs which are incompatible with the server's indicated cipher suite.  Because TLS 1.3 forbids renegotiation, if a server has negotiated TLS 1.3 and receives a ClientHello at any other time, it MUST terminate the connection with an "unexpected_message" alert.

The padding extension is typically computed as part of serializing the ClientHello, in hopes of targetting a particular size. As specified right now, the second ClientHello must not use this same logic and instead must retain the previous extension sizethough this would likely not hit the same target size. The server's going to ignore it anyway, so allow it to be recalcuated. This avoids unnecessary state in clients and extra logic to serialize the first and second ClientHellos differently.
Good catch; +1

removing any PSKs which are incompatible with the server's indicated cipher suite. <ins> Optionally adding, removing, or changing the length of the "padding" extension RFC7685. </ins> Because TLS 1.3 forbids renegotiation, if a server has negotiated TLS 1.3 and receives a ClientHello at any other time, it MUST terminate the connection with an "unexpected_message" alert.


that conveyed the severity of the message in previous versions of TLS.  In TLS 1.3, the severity is implicit in the type of alert being sent, and the 'level' field can safely be ignored.  The <del> "close_notify" alert is used to indicate orderly closure of the connection.  Upon receiving such an alert, the TLS implementation SHOULD indicate end-of-data to the application. </del>  Error alerts indicate abortive closure of the connection (see error- alerts).  Upon receiving an error alert, the TLS implementation This alert notifies the recipient that the sender will not send any more messages on this connection.  Any data received after a <del> closure MUST be ignored. </del>  This alert notifies the recipient that the sender is canceling the handshake for some reason unrelated to a protocol failure.  If a appropriate.  This alert SHOULD be followed by a "close_notify". This alert is generally a warning. <del> Either party MAY initiate a close by sending a "close_notify" alert. Any data received after a closure alert MUST be ignored.  If a transport-level close is received prior to a "close_notify", the receiver cannot know that all the data that was sent has been received. Each party MUST send a "close_notify" alert before closing the write side of the connection, unless some other fatal alert has been transmitted.  The other party MUST respond with a "close_notify" alert of its own and close down the connection immediately, discarding any pending writes.  The initiator of the close need not wait for the responding "close_notify" alert before closing the read side of the connection. </del>  If the application protocol using TLS provides that any data may be carried over the underlying transport after the TLS connection is <del> closed, the TLS implementation MUST receive the responding "close_notify" alert before indicating to the application layer that the TLS connection has ended.  If the application protocol will not transfer any additional data but will only close the underlying transport connection, then the implementation MAY choose to close the transport without waiting for the responding "close_notify".  No part of this standard should be taken to dictate the manner in which a usage profile for TLS manages its data transport, including when </del>  connections are opened or closed. <del> Note: It is assumed that closing a connection reliably delivers pending data before destroying the transport. </del>  6.2.

Currently TLS 1.3 specifies closenotify in the same way that TLS 1.2 did. I believe that has issues and this might be the right time to fix them. The purpose of closenotify is to protect against data truncation attacks, each side is required to send closenotify before closing the write side of the transport connection so the other side knows that the data was not truncated. As such, closenotify only needs half-close semantics to prevent truncation. However, the specification contains the following text: > This means that an application-layer client can't send a query then close their write transport when they know that they're done, because the server would terminate the TLS session before sending the reply. On top of this, when the server receives the closenotify, it may have already sent part of the reply (or wrote it to the socket send buffer) so the responding closenotify would in effect be inflicting a truncation attack on the client. This doesn't make much difference for HTTP because clients already don't close their write transport after sending a reply, however having the option do do this could allow innovation in new protocols that can define the semantics of when they use closenotify. An example is DNS PUSH: URL A proposal to solve this problem would be to give closenotify half-close semantics: we keep the requirements that a closenotify be sent before closing the transport, and that any data received after a closenotify is ignored, but we simply remove the requirement to immediately reply with a close_notify. This has the advantage that current implementations are already compliant but future ones can leverage this improvement.

that conveyed the severity of the message in previous versions of TLS.  In TLS 1.3, the severity is implicit in the type of alert being sent, and the 'level' field can safely be ignored.  The  <ins> "close_notify" alert is used to indicate orderly closure of one direction of the connection.  Upon receiving such an alert, the TLS implementation SHOULD indicate end-of-data to the application. </ins> Error alerts indicate abortive closure of the connection (see error- alerts).  Upon receiving an error alert, the TLS implementation This alert notifies the recipient that the sender will not send any more messages on this connection.  Any data received after a  <ins> closure alert has been received MUST be ignored. </ins> This alert notifies the recipient that the sender is canceling the handshake for some reason unrelated to a protocol failure.  If a appropriate.  This alert SHOULD be followed by a "close_notify". This alert is generally a warning.  <ins> Either party MAY initiate a close of its write side of the connection by sending a "close_notify" alert.  Any data received after a closure alert has been received MUST be ignored.  If a transport-level close is received prior to a "close_notify", the receiver cannot know that all the data that was sent has been received. Each party MUST send a "close_notify" alert before closing its write side of the connection, unless it has already sent some other fatal alert.  This does not have any effect on its read side of the connection.  Note that this is a change from versions of TLS prior to TLS 1.3 in which implementations were required to react to a "close_notify" by discarding pending writes and sending an immediate "close_notify" alert of their own.  That previous requirement could cause truncation in the read side.  Both parties need not wait to receive a "close_notify" alert before closing their read side of the connection. </ins> If the application protocol using TLS provides that any data may be carried over the underlying transport after the TLS connection is  <ins> closed, the TLS implementation MUST receive a "close_notify" alert before indicating end-of-data to the application-layer.  No part of this standard should be taken to dictate the manner in which a usage profile for TLS manages its data transport, including when </ins> connections are opened or closed.  <ins> Note: It is assumed that closing the write side of a connection reliably delivers pending data before destroying the transport. </ins> 6.2.


single connection, either immediately after each other or after specific events.  For instance, the server might send a new ticket after post-handshake authentication in order to encapsulate the <del> additional client authentication state.  Clients SHOULD attempt to use each ticket no more than once, with more recent tickets being used first. </del>  Any ticket MUST only be resumed on connections where the following values match the values negotiated in the connection during which the

Currently, the draft says that servers MAY send multiple tickets to clients without further discussion. It might help to be concrete and provide an example for when more than one ticket is useful. This PR provides one example.

single connection, either immediately after each other or after specific events.  For instance, the server might send a new ticket after post-handshake authentication in order to encapsulate the  <ins> additional client authentication state.  Multiple tickets are useful for clients for a variety of purposes, including: Opening multiple parallel HTTP connections. Performing connection racing across interfaces and address families via, e.g., Happy Eyeballs RFC6555 or related techniques. Clients SHOULD attempt to use each ticket no more than once, with more recent tickets being used first. </ins> Any ticket MUST only be resumed on connections where the following values match the values negotiated in the connection during which the


validate each other's public value Y by ensuring that the point is a valid point on the elliptic curve.  The appropriate validation procedures are defined in Section 4.3.7 of X962 and alternatively in <del> Section 5.6.2.6 of KEYAGREEMENT.  This process consists of three </del>  steps: (1) verify that Y is not the point at infinity (O), (2) verify that for Y = (x, y) both integers are in the correct interval, (3) ensure that (x, y) is a correct solution to the elliptic curve

The RFC editor found a few errors in a draft that used the same references. This updates the draft to use the automatically generated DOI references from URL rather than manual references. This isn't perfect, but it should help the RFC editor when it comes time to publish.
This changes: to LGTM (Dang is the author according to URL)

validate each other's public value Y by ensuring that the point is a valid point on the elliptic curve.  The appropriate validation procedures are defined in Section 4.3.7 of X962 and alternatively in  <ins> Section 5.6.2.3 of KEYAGREEMENT.  This process consists of three </ins> steps: (1) verify that Y is not the point at infinity (O), (2) verify that for Y = (x, y) both integers are in the correct interval, (3) ensure that (x, y) is a correct solution to the elliptic curve


All implementations MUST send and use these extensions when offering applicable features: <del> "supported_versions" is REQUIRED for all ClientHello messages. </del>  "signature_algorithms" is REQUIRED for certificate authentication.

This is mentioned throughout the document, but not in the "Mandatory-to-Implement" section.
This is the same as , just without the extra new line additions, etc
In the section it states: In the section we have: However, this is not mentioned in the "Mandatory-to-Implement" extensions section.

All implementations MUST send and use these extensions when offering applicable features:  <ins> "supported_versions" is REQUIRED for all ClientHello, ServerHello and HelloRetryRequest messages. </ins> "signature_algorithms" is REQUIRED for certificate authentication.


determined by the specified group and its corresponding definition. <del> The "extension_data" field of this extension contains a "KeyShare" value: </del>  <del> %%% Key Exchange Messages </del>  A list of offered KeyShareEntry values in descending order of <del> client preference.  This vector MAY be empty if the client is requesting a HelloRetryRequest.  Each KeyShareEntry value MUST correspond to a group offered in the "supported_groups" extension and MUST appear in the same order.  However, the values MAY be a non-contiguous subset of the "supported_groups" extension and MAY omit the most preferred groups.  Such a situation could arise if the most preferred groups are new and unlikely to be supported in enough places to make pregenerating key shares for them efficient. The mutually supported group the server intends to negotiate and is requesting a retried ClientHello/KeyShare for. </del>  <del> A single KeyShareEntry value that is in the same group as one of the client's shares. </del>  Clients can offer an arbitrary number of KeyShareEntry values, each representing a single set of key exchange parameters.  For instance, these rules and abort the handshake with an "illegal_parameter" alert if one is violated.  Upon receipt of this extension in a HelloRetryRequest, the client MUST verify that (1) the selected_group field corresponds to a group which was provided in the "supported_groups" extension in the new KeyShareEntry for the group indicated in the selected_group field of the triggering HelloRetryRequest.  If using (EC)DHE key establishment, servers offer exactly one KeyShareEntry in the ServerHello.  This value MUST be in the same group as the KeyShareEntry value offered by the client that the TLS HandshakeType Registry: Future values are allocated via Standards Action RFC5226.  IANA [SHALL update/has updated] this registry to rename item 4 from "NewSessionTicket" to <del> "new_session_ticket" and to add the "hello_retry_request", "encrypted_extensions", "end_of_early_data", "key_update", and "message_hash" values. </del>  This document also uses the TLS ExtensionType Registry originally created in RFC4366.  IANA has updated it to reference this document.

I tend to narrow things from the right....
Programmer habits maybe, for me a "FooTest" is a specialization of "Test", so the current "KeyShareServerHello" looks like a specialization of "ServerHello" to me. It's a minor thing though.
Fair enough, but my habit is the opposite. :)
The text refers to helloretryrequest (e.g. in IANA considerations), but the HandshakeType enum refers to helloretryrequestRESERVED. Should something be said about Server Hello being able to modify ? Should something be said about rejecting handshake messages with ? (The current seems to suggest that the wire can really contain 6.)
My syntax validator also detects this error. We need to fix this.
I guess that it is hard to express a nested . So, it seems to me that a comment is reasonable:
That comment is not easy to parse for a machine :/ (btw, the comment is for the serverhello case, not clienthello). is only defined for enumerations, so we cannot do something like: (and even the above is not accurate since interpretation of random depends on the supportedextensions value.) Maybe something like: with the intention that ServerHelloParameters is populated while preparsing the SH message (prescan for supportedversions, detect HRR vs normal SH based on Random). This is inspired by the SecurityParameters type in RFC 5246.
LGTM. As a nitpick, maybe name it "ServerHelloKeyShare" instead of "KeyShareServerHello" (likewise for CH and HRR).

determined by the specified group and its corresponding definition.  <ins> In the ClientHello message, the "extension_data" field of this extension contains a "KeyShareClientHello" value: </ins>  <ins> %%% Key Exchange Messages struct { KeyShareEntry client_shares<0..2^16-1>; } KeyShareClientHello; </ins> A list of offered KeyShareEntry values in descending order of  <ins> client preference. </ins>  <ins> This vector MAY be empty if the client is requesting a HelloRetryRequest.  Each KeyShareEntry value MUST correspond to a group offered in the "supported_groups" extension and MUST appear in the same order.  However, the values MAY be a non-contiguous subset of the "supported_groups" extension and MAY omit the most preferred groups.  Such a situation could arise if the most preferred groups are new and unlikely to be supported in enough places to make pregenerating key shares for them efficient. </ins> Clients can offer an arbitrary number of KeyShareEntry values, each representing a single set of key exchange parameters.  For instance, these rules and abort the handshake with an "illegal_parameter" alert if one is violated. <ins> In a HelloRetryRequest message, the "extension_data" field of this extension contains a KeyShareHelloRetryRequest value: %%% Key Exchange Messages struct { NamedGroup selected_group; } KeyShareHelloRetryRequest; The mutually supported group the server intends to negotiate and is requesting a retried ClientHello/KeyShare for. </ins> Upon receipt of this extension in a HelloRetryRequest, the client MUST verify that (1) the selected_group field corresponds to a group which was provided in the "supported_groups" extension in the new KeyShareEntry for the group indicated in the selected_group field of the triggering HelloRetryRequest. <ins> In a ServerHello message, the "extension_data" field of this extension contains a KeyShareServerHello value: %%% Key Exchange Messages struct { KeyShareEntry server_share; } KeyShareServerHello; A single KeyShareEntry value that is in the same group as one of the client's shares. </ins> If using (EC)DHE key establishment, servers offer exactly one KeyShareEntry in the ServerHello.  This value MUST be in the same group as the KeyShareEntry value offered by the client that the TLS HandshakeType Registry: Future values are allocated via Standards Action RFC5226.  IANA [SHALL update/has updated] this registry to rename item 4 from "NewSessionTicket" to  <ins> "new_session_ticket" and to add the "hello_retry_request_RESERVED", "encrypted_extensions", "end_of_early_data", "key_update", and "message_hash" values. </ins> This document also uses the TLS ExtensionType Registry originally created in RFC4366.  IANA has updated it to reference this document.


containing a single certificate and set of extensions. A set of extension values for the CertificateEntry.  The <del> "Extension" format is defined in extensions.  Valid extensions include OCSP Status extension (RFC6066) and SignedCertificateTimestamps (RFC6962).  An extension MUST only be present in a Certificate message if the corresponding ClientHello extension was presented in the initial handshake.  If an extension applies to the entire chain, it SHOULD be included in the first CertificateEntry. </del>  If the corresponding certificate type extension ("server_certificate_type" or "client_certificate_type") was not

The peer must advertise extensions before they can be sent with a certificate message.
I fixed it with a period.
statusrequest and signedcertificatestatus timestamps are allowed in the CertificateRequest message according to URL Certificate extensions (URL) however say: Is this also the intended behavior for client certificates, or should it instead require extensions to be advertised in CertificateRequest? (This is relevant for future extensions.) No idea why a client would bother sending SCT or statusrequest extensions, but that is not forbidden by the TLS 1.3 spec. The status_request (RFC 6066) and extensions are written such that it seems unusable in client certs though.
I'd say it's both - for those extensions to be in client side Certificate message they need to be both in Client Hello and in Certificate Request. That's because any extensions in Certificate Request must have been first advertised in Client Hello
That's not correct. You can advertise stuff in CR that's not in CH (e.g., X.509 OIDs). Peter, good catch. PR welcome.
NAME that's rather ugly - to this point only the cookie extension was of a "you support it even if you don't advertise it", I don't like adding more exceptions to that rule...
It's been this way for some time. URL
It's much simpler this way. As in the text EKR pointed to, extensions come in request/response pairs, so there is only one kind of flow to worry about. In your version, client certificate extensions have this weird three-phase bit which ends up meaning extra logic in implementations. This additionally is more flexible. Suppose I am willing to send an SCT on my client certificate, but I don't have anything useful to do with the server one. (The inverse is more likely for SCTs but consider a future bit of certificate metadata.) In your version, there is no way to distinguish "I want an SCT" from "I won't explode if you request one of me".
That's what I meant - the Certificate Request ones are not described as "unsolicited". I don't think this is a useful distinction to make. But I digress. If we make all Certificate Request extensions unsolicited, that's fine by me. But I think that it's a significant change from TLS 1.2, and should be documented as such.
TLS 1.2 had no extension mechanism for CertificateRequest: URL
CertificateRequest extensions were intended to be unsolicited, yeah.

containing a single certificate and set of extensions. A set of extension values for the CertificateEntry.  The  <ins> "Extension" format is defined in extensions.  Valid extensions for server certificates include OCSP Status extension (RFC6066) and SignedCertificateTimestamps (RFC6962).  Extensions in the Certificate message from the server MUST correspond to one from the ClientHello message, extensions in the Certificate from the client MUST correspond with an extension in the CertificateRequest message from the server.  If an extension applies to the entire chain, it SHOULD be included in the first CertificateEntry. </ins> If the corresponding certificate type extension ("server_certificate_type" or "client_certificate_type") was not


If the corresponding certificate type extension ("server_certificate_type" or "client_certificate_type") was not negotiated in Encrypted Extensions, or the X.509 certificate type was <del> negotiated, then each CertificateEntry contains an X.509 certificate. The sender's certificate MUST come in the first CertificateEntry in the list.  Each following certificate SHOULD directly certify one preceding it.  Because certificate validation requires that trust anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates. </del>  Note: Prior to TLS 1.3, "certificate_list" ordering required each certificate to certify the one immediately preceding it; however,

Without specifying the encoding, I don't think it's actually defined how you transit the certificates. RFC 5280 only says that the TBSCertificate is DER-encoded for computing the signature, which still allows insanity like XER-encoded everything with the receiver re-encoding the TBSCertificate to DER before verifying the signature.

If the corresponding certificate type extension ("server_certificate_type" or "client_certificate_type") was not negotiated in Encrypted Extensions, or the X.509 certificate type was  <ins> negotiated, then each CertificateEntry contains a DER-encoded X.509 certificate.  The sender's certificate MUST come in the first CertificateEntry in the list.  Each following certificate SHOULD directly certify one preceding it.  Because certificate validation requires that trust anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates. </ins> Note: Prior to TLS 1.3, "certificate_list" ordering required each certificate to certify the one immediately preceding it; however,


4.2.3. <del> The client uses the "signature_algorithms" extension to indicate to the server which signature algorithms may be used in digital signatures.  Clients which desire the server to authenticate itself via a certificate MUST send this extension.  If a server is authenticating via a certificate and the client has not sent a "signature_algorithms" extension, then the server MUST abort the handshake with a "missing_extension" alert (see mti-extensions). The "extension_data" field of this extension in a ClientHello contains a SignatureSchemeList value: </del>  %%% Signature Algorithm Extension with the corresponding hash algorithm as defined in SHS.  These values refer solely to signatures which appear in certificates (see server-certificate-selection) and are not defined for use in <del> signed TLS handshake messages. </del>  Indicates a signature algorithm using ECDSA ECDSA, the corresponding curve as defined in ANSI X9.62 X962 and FIPS 186-4 Indicates a signature algorithm using RSASSA-PSS RFC8017 with mask generation function 1.  The digest used in the mask generation function and the digest being signed are both the corresponding <del> hash algorithm as defined in SHS.  When used in signed TLS handshake messages, the length of the salt MUST be equal to the length of the digest output.  This codepoint is new in this document and is also defined for use with TLS 1.2. </del>  Indicates a signature algorithm using EdDSA as defined in RFC8032 or its successors.  Note that these correspond to the "PureEdDSA" algorithms and not the "prehash" variants.  Indicates algorithms which are being deprecated because they use algorithms with known weaknesses, specifically SHA-1 which is used in this context with either with RSA using RSASSA-PKCS1-v1_5 or ECDSA.  These values refer solely to signatures which appear in certificates (see server-certificate-selection) and are not <del> defined for use in signed TLS handshake messages.  Endpoints SHOULD NOT negotiate these algorithms but are permitted to do so solely for backward compatibility.  Clients offering these values MUST list them as the lowest priority (listed after all other algorithms in SignatureSchemeList).  TLS 1.3 servers MUST NOT offer a SHA-1 signed certificate unless no valid certificate chain can be produced without it (see server-certificate-selection). </del>  The signatures on certificates that are self-signed or certificates that are trust anchors are not validated since they begin a cipher suites.  (see cipher-suites) A TLS-compliant application MUST support digital signatures with <del> rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for </del>  CertificateVerify and certificates), and ecdsa_secp256r1_sha256.  A TLS-compliant application MUST support key exchange with secp256r1 (NIST P-256) and SHOULD support key exchange with X25519 RFC7748. IANA [SHALL update/has updated] this registry to include the "key_share", "pre_shared_key", "psk_key_exchange_modes", "early_data", "cookie", "supported_versions", <del> "certificate_authorities", "oid_filters", and "post_handshake_auth" extensions with the values defined in this document and the Recommended value of "Yes". </del>  IANA [SHALL update/has updated] this registry to include a "TLS 1.3" column which lists the messages in which the extension may

The only thing that might need text (though I'm not certain) is that this doesn't describe what it means to have signaturealgorithmscert and not signaturealgorithms. I assume that it means that a signature isn't possible. However, in previous versions it would be interpreted to mean something else based on default values for signaturealgorithms.

4.2.3.  <ins> TLS 1.3 provides two extensions for indicating which signature algorithms may be used in digital signatures.  The "signature_algorithms_cert" extension applies to signatures in certificates and the "signature_algorithms" extension, which originally appeared in TLS 1.2, applies to signatures in CertificateVerify messages.  The keys found in certificates MUST also be of appropriate type for the signature algorithms they are used with.  This is a particular issue for RSA keys and PSS signatures, as described below.  If no "signature_algorithms_cert" extension is present, then the "signature_algorithms" extension also applies to signatures appearing in certificates.  Clients which desire the server to authenticate itself via a certificate MUST send "signature_algorithms".  If a server is authenticating via a certificate and the client has not sent a "signature_algorithms" extension, then the server MUST abort the handshake with a "missing_extension" alert (see mti-extensions). The "signature_algorithms_cert" extension was added to allow implementatations which supported different sets of algorithms for certificates and in TLS itself to clearly signal their capabilities. TLS 1.2 implementations SHOULD also process this extension. The "extension_data" field of these extension contains a SignatureSchemeList value: </ins> %%% Signature Algorithm Extension with the corresponding hash algorithm as defined in SHS.  These values refer solely to signatures which appear in certificates (see server-certificate-selection) and are not defined for use in  <ins> signed TLS handshake messages, although they MAY appear in "signature_algorithms" and "signature_algorithms_cert" for backward compatibility with TLS 1.2, </ins> Indicates a signature algorithm using ECDSA ECDSA, the corresponding curve as defined in ANSI X9.62 X962 and FIPS 186-4 Indicates a signature algorithm using RSASSA-PSS RFC8017 with mask generation function 1.  The digest used in the mask generation function and the digest being signed are both the corresponding  <ins> hash algorithm as defined in SHS.  The length of the salt MUST be equal to the length of the digest algorithm.  If the public key is carried in an X.509 certificate, it MUST use the rsaEncryption OID RFC5280. </ins> Indicates a signature algorithm using EdDSA as defined in RFC8032 or its successors.  Note that these correspond to the "PureEdDSA" algorithms and not the "prehash" variants. <ins> Indicates a signature algorithm using RSASSA-PSS RFC8017 with mask generation function 1.  The digest used in the mask generation function and the digest being signed are both the corresponding hash algorithm as defined in SHS.  The length of the salt MUST be equal to the length of the digest algorithm.  If the public key is carried in an X.509 certificate, it MUST use the RSASSA-PSS OID RFC5756.  When used in certificate signatures, the algorithm parameters MUST be DER encoded.  If the corresponding public key's parameters present, then the parameters in the signature MUST be identical to those in the public key. </ins> Indicates algorithms which are being deprecated because they use algorithms with known weaknesses, specifically SHA-1 which is used in this context with either with RSA using RSASSA-PKCS1-v1_5 or ECDSA.  These values refer solely to signatures which appear in certificates (see server-certificate-selection) and are not  <ins> defined for use in signed TLS handshake messages, even if they appear in the "signature_algorithms" list (this is necessary for backward compatibility with TLS 1.2).  Endpoints SHOULD NOT negotiate these algorithms but are permitted to do so solely for backward compatibility.  Clients offering these values MUST list them as the lowest priority (listed after all other algorithms in SignatureSchemeList).  TLS 1.3 servers MUST NOT offer a SHA-1 signed certificate unless no valid certificate chain can be produced without it (see server-certificate-selection). </ins> The signatures on certificates that are self-signed or certificates that are trust anchors are not validated since they begin a cipher suites.  (see cipher-suites) A TLS-compliant application MUST support digital signatures with  <ins> rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256_ (for </ins> CertificateVerify and certificates), and ecdsa_secp256r1_sha256.  A TLS-compliant application MUST support key exchange with secp256r1 (NIST P-256) and SHOULD support key exchange with X25519 RFC7748. IANA [SHALL update/has updated] this registry to include the "key_share", "pre_shared_key", "psk_key_exchange_modes", "early_data", "cookie", "supported_versions",  <ins> "certificate_authorities", "oid_filters", "post_handshake_auth", and "signature_algorithms_certs", extensions with the values defined in this document and the Recommended value of "Yes". </ins> IANA [SHALL update/has updated] this registry to include a "TLS 1.3" column which lists the messages in which the extension may


backward-compatibility for details about backward compatibility.) <del> This structure is generated by the server and MUST be independently generated from the ClientHello.random. </del>  This is the identity of the session corresponding to this

Server Hello is slightly confusing english. Must this be generated from the URL I'm pretty sure the opposite is the intent. A clearer form of words might be: or
Merged.

backward-compatibility for details about backward compatibility.)  <ins> This structure is generated by the server and MUST be generated independently of the ClientHello.random. </ins> This is the identity of the session corresponding to this


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in RFC 2119 RFC2119. </del>  The following terms are used:

RFC 8174 updates RFC 2119 so the boilerplate words have changed slightly according to s2 of RFC 8174. Just trying to save us another GENART comment.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and  <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> The following terms are used:


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 <del> 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). </del>  This is a list of the symmetric cipher options supported by the client, specifically the record protection algorithm (including 9.3. <del> 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. </del>  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 <del> provides downgrade protection: Intermediaries passing traffic between a newer client and newer server without terminating TLS should be </del>  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 1.3, a client receiving a CertificateRequest or NewSessionTicket MUST also ignore all unrecognized extensions. <del> An intermediary which terminates a TLS connection MUST behave as a </del>  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 understands, and it MUST generate a fresh ServerHello random value, rather than forwarding the endpoint's value. <del> In this scenario, the intermediary is a pair of TLS endpoints for purposes of protocol requirements and security analysis. </del>  <del> An intermediary which forwards ClientHello parameters it does not </del>  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. Forwarded ClientHellos may contain advertisements for features not <del> 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. </del>  The design of TLS 1.3 was constrained by widely-deployed non- <del> compliant TLS intermediaries (see middlebox), however it does not relax the invariants.  Those intermediaries continue to be non- compliant. </del>  10.

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 shouldn'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 don'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!

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  <ins> 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). </ins> This is a list of the symmetric cipher options supported by the client, specifically the record protection algorithm (including 9.3.  <ins> 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. </ins> 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  <ins> provides downgrade protection: Middleboxes passing traffic between a newer client and newer server without terminating TLS should be </ins> 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 1.3, a client receiving a CertificateRequest or NewSessionTicket MUST also ignore all unrecognized extensions.  <ins> A middlebox which terminates a TLS connection MUST behave as a </ins> 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 understands, and it MUST generate a fresh ServerHello random value, rather than forwarding the endpoint's value.  <ins> 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. </ins>  <ins> An middlebox which forwards ClientHello parameters it does not </ins> 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. Forwarded ClientHellos may contain advertisements for features not  <ins> 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. </ins> The design of TLS 1.3 was constrained by widely-deployed non-  <ins> compliant TLS middleboxes (see middlebox), however it does not relax the invariants.  Those middleboxes continue to be non-compliant. </ins> 10.


implementations which supported different sets of algorithms for certificates and in TLS itself to clearly signal their capabilities. TLS 1.2 implementations SHOULD also process this extension.  The "extension_data" field of these extension contains a SignatureSchemeList value: In prior versions of TLS, the CertificateRequest message carried a list of signature algorithms and certificate authorities which the server would accept.  In TLS 1.3 the former is expressed by sending <del> the "signature_algorithms" extension.  The latter is expressed by sending the "certificate_authorities" extension (see certificate- authorities). </del>  Servers which are authenticating with a PSK MUST NOT send the CertificateRequest message in the main handshake, though they MAY The certificate MUST allow the key to be used for signing (i.e., the digitalSignature bit MUST be set if the Key Usage extension is present) with a signature scheme indicated in the client's <del> "signature_algorithms" extension. </del>  The "server_name" RFC6066 and "certificate_authorities" extensions are used to guide certificate selection.  As servers MAY require this extension, when applicable. All certificates provided by the server MUST be signed by a signature <del> algorithm that appears in the "signature_algorithms" extension provided by the client, if they are able to provide such a chain (see signature-algorithms).  Certificates that are self-signed or certificates that are expected to be trust anchors are not validated as part of the chain and therefore MAY be signed with any algorithm. </del>  If the server cannot produce a certificate chain that is signed only via the indicated supported algorithms, then it SHOULD continue the handshake by sending the client a certificate chain of its choice that may include algorithms that are not known to be supported by the client.  This fallback chain SHOULD NOT use the deprecated SHA-1 hash <del> algorithm in general, but MAY do so if the "signature_algorithms" extension provided by the client permits it, and MUST NOT do so otherwise. </del>  If the client cannot construct an acceptable chain using the provided certificates and decides to abort the handshake, then it MUST abort Signature Algorithms ("signature_algorithms"; signature- algorithms)  Negotiated Groups ("supported_groups"; negotiated-groups) Key Share ("key_share"; key-share)

In your answer to my question on list you say: and chain validation. I don't see that covered by this PR. Shouldn't this be explicit?
then the "signature_algorithms" extension also applies to signatures appearing in certificates. is unaffected by this change
As NAME says, there is already text that implies that you need not send "signature_algorithms" cert, so I don't think new text is really needed here.
That sentence says nothing about under what circumstances it is ok to omit "signaturealgorithmscert". It only implies that you may not always get it. I think it would not hurt to be more explicit.

implementations which supported different sets of algorithms for certificates and in TLS itself to clearly signal their capabilities. TLS 1.2 implementations SHOULD also process this extension. <ins> Implementations which have the same policy in both cases MAY omit the "signature_algorithms_cert" extension. </ins> The "extension_data" field of these extension contains a SignatureSchemeList value: In prior versions of TLS, the CertificateRequest message carried a list of signature algorithms and certificate authorities which the server would accept.  In TLS 1.3 the former is expressed by sending  <ins> the "signature_algorithms" and "signature_algorithms_cert" extensions.  The latter is expressed by sending the "certificate_authorities" extension (see certificate-authorities). </ins> Servers which are authenticating with a PSK MUST NOT send the CertificateRequest message in the main handshake, though they MAY The certificate MUST allow the key to be used for signing (i.e., the digitalSignature bit MUST be set if the Key Usage extension is present) with a signature scheme indicated in the client's  <ins> "signature_algorithms"/"signature_algorithms_cert" extensions (see signature-algorithms). </ins> The "server_name" RFC6066 and "certificate_authorities" extensions are used to guide certificate selection.  As servers MAY require this extension, when applicable. All certificates provided by the server MUST be signed by a signature  <ins> algorithm advertised by the client, if they are able to provide such a chain (see signature-algorithms).  Certificates that are self- signed or certificates that are expected to be trust anchors are not validated as part of the chain and therefore MAY be signed with any algorithm. </ins> If the server cannot produce a certificate chain that is signed only via the indicated supported algorithms, then it SHOULD continue the handshake by sending the client a certificate chain of its choice that may include algorithms that are not known to be supported by the client.  This fallback chain SHOULD NOT use the deprecated SHA-1 hash  <ins> algorithm in general, but MAY do so if the client's advertisement permits it, and MUST NOT do so otherwise. </ins> If the client cannot construct an acceptable chain using the provided certificates and decides to abort the handshake, then it MUST abort Signature Algorithms ("signature_algorithms"; signature- algorithms) <ins> Signature Algorithms Certificate ("signature_algorithms_cert"; signature-algorithms) </ins> Negotiated Groups ("supported_groups"; negotiated-groups) Key Share ("key_share"; key-share)


A list of extensions.  The ServerHello MUST only include extensions which are required to establish the cryptographic <del> context.  Currently the only such extensions are "key_share" and "pre_shared_key".  All current TLS 1.3 ServerHello messages will contain one of these two extensions, or both when using a PSK with (EC)DHE key establishment.  The remaining extensions are sent separately in the EncryptedExtensions message. </del>  For backward compatibility reasons with middleboxes (see middlebox) the HelloRetryRequest message uses the same structure as the HelloRetryRequest and otherwise abort the handshake with an "illegal_parameter" alert.  4.2. A number of TLS messages contain tag-length-value encoded extensions

Issue 1: supportedversions is required in TLS 1.3 SH. Issue 2: supportedversions.selected_version must be identical in HRR and SH
NAME please submit a PR to add yourself to acknowledgements
Thanks for the fixup.

A list of extensions.  The ServerHello MUST only include extensions which are required to establish the cryptographic  <ins> context and negotiate the protocol version.  All TLS 1.3 ServerHello messages MUST contain the "supported_versions" extension.  Current ServerHello messages contain either the "pre_shared_key" or "key_share" extensions, or both when using a PSK with (EC)DHE key establishment.  The remaining extensions are sent separately in the EncryptedExtensions message. </ins> For backward compatibility reasons with middleboxes (see middlebox) the HelloRetryRequest message uses the same structure as the HelloRetryRequest and otherwise abort the handshake with an "illegal_parameter" alert. <ins> The value of selected_version in the HelloRetryRequest "supported_versions" extension MUST be retained in the ServerHello, and a client MUST abort the handshake with an "illegal_parameter" alert if the value changes. </ins> 4.2. A number of TLS messages contain tag-length-value encoded extensions


cipher suites.  (see cipher-suites) A TLS-compliant application MUST support digital signatures with <del> rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256_ (for </del>  CertificateVerify and certificates), and ecdsa_secp256r1_sha256.  A TLS-compliant application MUST support key exchange with secp256r1 (NIST P-256) and SHOULD support key exchange with X25519 RFC7748.

remove extra _ at the end of name -- the name in SignatureScheme enum lacks it

cipher suites.  (see cipher-suites) A TLS-compliant application MUST support digital signatures with  <ins> rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for </ins> CertificateVerify and certificates), and ecdsa_secp256r1_sha256.  A TLS-compliant application MUST support key exchange with secp256r1 (NIST P-256) and SHOULD support key exchange with X25519 RFC7748.


This document describes TLS 1.3, which uses the version 0x0304.  This version value is historical, deriving from the use of 0x0301 for TLS 1.0 and 0x0300 for SSL 3.0.  In order to maximize backwards <del> compatibility, records containing an initial ClientHello MUST have </del>  version 0x0301 and a record containing a second ClientHello or a ServerHello MUST have version 0x0303, reflecting TLS 1.0 and TLS 1.2 respectively.  When negotiating prior versions of TLS, endpoints

says: But the following text follows: MAY and MUST mismatch. Let's s/MUST/SHOULD/

This document describes TLS 1.3, which uses the version 0x0304.  This version value is historical, deriving from the use of 0x0301 for TLS 1.0 and 0x0300 for SSL 3.0.  In order to maximize backwards  <ins> compatibility, records containing an initial ClientHello SHOULD have </ins> version 0x0301 and a record containing a second ClientHello or a ServerHello MUST have version 0x0303, reflecting TLS 1.0 and TLS 1.2 respectively.  When negotiating prior versions of TLS, endpoints


(*) indicates changes to the wire protocol which may require implementations to update.  draft-24 Require that CH2 have version 0303 (*) The legacy_record_version field is always 0x0303.  TLS 1.3 TLSCiphertexts are not generated until after TLS 1.3 has been negotiated, so there are no historical compatibility concerns <del> where other values might be received.  Implementations MAY verify that the legacy_record_version field is 0x0303 and abort the connection if it is not.  Note that the handshake protocol including the ClientHello and ServerHello messages authenticates the protocol version, so this value is redundant. </del>  The length (in bytes) of the following TLSCiphertext.encrypted_record, which is the sum of the lengths of described in Section 2.1 of RFC5116.  The key is either the client_write_key or the server_write_key, the nonce is derived from the sequence number (see nonce) and the client_write_iv or <del> server_write_iv, and the additional data input is empty (zero length).  Derivation of traffic keys is defined in traffic-key- calculation. </del>  The plaintext input to the AEAD algorithm is the encoded <del> TLSInnerPlaintext structure. </del>  The AEAD output consists of the ciphertext output from the AEAD encryption operation.  The length of the plaintext is greater than Since the ciphers might incorporate padding, the amount of overhead could vary with different lengths of plaintext.  Symbolically,  In order to decrypt and verify, the cipher takes as input the key, <del> nonce, and the AEADEncrypted value.  The output is either the plaintext or an error indicating that the decryption failed.  There is no separate integrity check.  That is: </del>  If the decryption fails, the receiver MUST terminate the connection with a "bad_record_mac" alert.

Previous PR plus some cleanup.
Looks good to me, for what it's worth :)
ekr: please merge this so we can get a new version out for the IESG.
NAME can you be more precise about the appendix D text? is the issue that we say "ignored" but then use it as additional_data?
NAME : PTAL

(*) indicates changes to the wire protocol which may require implementations to update. <ins> draft-25 - Add the header to additional data (*) Minor clarifications. IANA cleanup. </ins> draft-24 Require that CH2 have version 0303 (*) The legacy_record_version field is always 0x0303.  TLS 1.3 TLSCiphertexts are not generated until after TLS 1.3 has been negotiated, so there are no historical compatibility concerns  <ins> where other values might be received.  Note that the handshake protocol including the ClientHello and ServerHello messages authenticates the protocol version, so this value is redundant. </ins> The length (in bytes) of the following TLSCiphertext.encrypted_record, which is the sum of the lengths of described in Section 2.1 of RFC5116.  The key is either the client_write_key or the server_write_key, the nonce is derived from the sequence number (see nonce) and the client_write_iv or  <ins> server_write_iv, and the additional data input is the record header. I.e., </ins> The plaintext input to the AEAD algorithm is the encoded  <ins> TLSInnerPlaintext structure.  Derivation of traffic keys is defined in traffic-key-calculation. </ins> The AEAD output consists of the ciphertext output from the AEAD encryption operation.  The length of the plaintext is greater than Since the ciphers might incorporate padding, the amount of overhead could vary with different lengths of plaintext.  Symbolically, <ins> Then the encrypted_record field of TLSCiphertext is set to AEADEncrypted. </ins> In order to decrypt and verify, the cipher takes as input the key,  <ins> nonce, additional data, and the AEADEncrypted value.  The output is either the plaintext or an error indicating that the decryption failed.  There is no separate integrity check.  That is: </ins> If the decryption fails, the receiver MUST terminate the connection with a "bad_record_mac" alert.


(*) indicates changes to the wire protocol which may require implementations to update.  draft-25 - Add the header to additional data (*) Minor clarifications. ClientHellos that include this extension but do not include 0x0304 in the list of versions. <del> A server which negotiates TLS 1.3 MUST respond by sending a "supported_versions" extension containing the selected version value (0x0304).  It MUST set the ServerHello.legacy_version field to 0x0303 (TLS 1.2).  Clients MUST check for this extension prior to processing the rest of the ServerHello (although they will have to parse the ServerHello in order to read the extension).  If this extension is present, clients MUST ignore the ServerHello.legacy_version value and MUST use only the "supported_versions" extension to determine the selected version.  If the "supported_versions" extension contains a version not offered by the client, the client MUST abort the handshake with an "illegal_parameter" alert. </del>  4.2.1.1.

LGTM!
This is natural, since if you negotiate prior to 1.3 you must use the ServerHello rules for the negotiated URL

(*) indicates changes to the wire protocol which may require implementations to update. <ins> draft-26 - Clarify that you can't negotiate pre-TLS 1.3 with supported_versions. </ins> draft-25 - Add the header to additional data (*) Minor clarifications. ClientHellos that include this extension but do not include 0x0304 in the list of versions.  <ins> A server which negotiates a version of TLS prior to TLS 1.3 MUST set ServerHello.version and MUST NOT send the "supported_versions" extension.  A server which negotiates TLS 1.3 MUST respond by sending a "supported_versions" extension containing the selected version value (0x0304).  It MUST set the ServerHello.legacy_version field to 0x0303 (TLS 1.2).  Clients MUST check for this extension prior to processing the rest of the ServerHello (although they will have to parse the ServerHello in order to read the extension).  If this extension is present, clients MUST ignore the ServerHello.legacy_version value and MUST use only the "supported_versions" extension to determine the selected version.  If the "supported_versions" extension contains a version not offered by the client or contains a version prior to TLS 1.3, the client MUST abort the handshake with an "illegal_parameter" alert. </ins> 4.2.1.1.


mechanism defined in RFC5077 and replaces it with the mechanism defined in resumption-and-psk. negotiated-groups updates RFC4492 by modifying the protocol attributes used to negotiate Elliptic Curves. <del> Because TLS 1.3 changes the way keys are derived it updates RFC5705 as described in exporters it also changes how OCSP messages are </del>  carried and therefore updates RFC6066 and obsoletes RFC6961 as described in section ocsp-and-sct. be more consistent and to remove superfluous messages such as ChangeCipherSpec. <del> Elliptic curve algorithms are now in the base spec and includes new signature algorithms, such as ed25519 and ed448.  TLS 1.3 removed point format negotiation in favor of a single point format for each curve. </del>  Other cryptographic improvements including the removal of compression and custom DHE groups, changing the RSA padding to use concatenated as described in basic-block-size and are also unsigned. The following numeric types are predefined. <del> All values, here and elsewhere in the specification, are stored in network byte (big-endian) order; the uint32 represented by the hex </del>  bytes 01 02 03 04 is equivalent to the decimal value 16909060. 3.5. extension.  Note that this mechanism makes it possible to negotiate a version prior to TLS 1.2 if one side supports a sparse range. Implementations of TLS 1.3 which choose to support prior versions of <del> TLS SHOULD support TLS 1.2.  Servers should be prepared to receive </del>  ClientHellos that include this extension but do not include 0x0304 in the list of versions. carried in an X.509 certificate, it MUST use the RSASSA-PSS OID RFC5756.  When used in certificate signatures, the algorithm parameters MUST be DER encoded.  If the corresponding public key's <del> parameters present, then the parameters in the signature MUST be identical to those in the public key. </del>  Indicates algorithms which are being deprecated because they use algorithms with known weaknesses, specifically SHA-1 which is used 4.2.6. The "post_handshake_auth" extension is used to indicate that a client <del> is willing to perform post-handshake authentication post-handshake- authentication.  Servers MUST NOT send a post-handshake </del>  CertificateRequest to clients which do not offer this extension. Servers MUST NOT send this extension. which was provided with the ticket.  The "obfuscated_ticket_age" field of each PskIdentity contains an obfuscated version of the ticket age formed by taking the age in milliseconds and adding the <del> "ticket_age_add" value that was included with the ticket, see NSTMessage modulo 2^32.  This addition prevents passive observers </del>  from correlating connections unless tickets are reused.  Note that the "ticket_lifetime" field in the NewSessionTicket message is in seconds but the "obfuscated_ticket_age" is in milliseconds.  Because (ClientHello.random).  The initial 64-byte pad clears that prefix along with the server-controlled ServerHello.random. <del> The context string for a server signature is "TLS 1.3, server CertificateVerify" and for a client signature is "TLS 1.3, client CertificateVerify".  It is used to provide separation between signatures made in different contexts, helping against potential cross-protocol attacks. </del>  For example, if the transcript hash was 32 bytes of 01 (this length would make sense for SHA-256), the content covered by the digital For finite field groups, a conventional Diffie-Hellman computation is performed.  The negotiated key (Z) is converted to a byte string by <del> encoding in big-endian and padded with zeros up to the size of the prime.  This byte string is used as the shared secret in the key </del>  schedule as specified above. Note that this construction differs from previous versions of TLS

NAME I did not: 1) add the "Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS " reference because it's already in the [JSS15] reference that's later in the sentence. 2) I also didn't made [AEAD-LIMITS] normative.

mechanism defined in RFC5077 and replaces it with the mechanism defined in resumption-and-psk. negotiated-groups updates RFC4492 by modifying the protocol attributes used to negotiate Elliptic Curves.  <ins> Because TLS 1.3 changes the way keys are derived, it updates RFC5705 as described in exporters.  It also changes how OCSP messages are </ins> carried and therefore updates RFC6066 and obsoletes RFC6961 as described in section ocsp-and-sct. be more consistent and to remove superfluous messages such as ChangeCipherSpec.  <ins> Elliptic curve algorithms are now in the base spec and new signature algorithms, such as ed25519 and ed448, are included. TLS 1.3 removed point format negotiation in favor of a single point format for each curve. </ins> Other cryptographic improvements including the removal of compression and custom DHE groups, changing the RSA padding to use concatenated as described in basic-block-size and are also unsigned. The following numeric types are predefined.  <ins> All values, here and elsewhere in the specification, are transmitted in network byte (big-endian) order; the uint32 represented by the hex </ins> bytes 01 02 03 04 is equivalent to the decimal value 16909060. 3.5. extension.  Note that this mechanism makes it possible to negotiate a version prior to TLS 1.2 if one side supports a sparse range. Implementations of TLS 1.3 which choose to support prior versions of  <ins> TLS SHOULD support TLS 1.2.  Servers MUST be prepared to receive </ins> ClientHellos that include this extension but do not include 0x0304 in the list of versions. carried in an X.509 certificate, it MUST use the RSASSA-PSS OID RFC5756.  When used in certificate signatures, the algorithm parameters MUST be DER encoded.  If the corresponding public key's  <ins> parameters are present, then the parameters in the signature MUST be identical to those in the public key. </ins> Indicates algorithms which are being deprecated because they use algorithms with known weaknesses, specifically SHA-1 which is used 4.2.6. The "post_handshake_auth" extension is used to indicate that a client  <ins> is willing to perform post-handshake authentication (post-handshake- authentication).  Servers MUST NOT send a post-handshake </ins> CertificateRequest to clients which do not offer this extension. Servers MUST NOT send this extension. which was provided with the ticket.  The "obfuscated_ticket_age" field of each PskIdentity contains an obfuscated version of the ticket age formed by taking the age in milliseconds and adding the  <ins> "ticket_age_add" value that was included with the ticket (see NSTMessage), modulo 2^32.  This addition prevents passive observers </ins> from correlating connections unless tickets are reused.  Note that the "ticket_lifetime" field in the NewSessionTicket message is in seconds but the "obfuscated_ticket_age" is in milliseconds.  Because (ClientHello.random).  The initial 64-byte pad clears that prefix along with the server-controlled ServerHello.random.  <ins> The context string for a server signature is: "TLS 1.3, server CertificateVerify" The context string for a client signature is: "TLS 1.3, client CertificateVerify" It is used to provide separation between signatures made in different contexts, helping against potential cross-protocol attacks. </ins> For example, if the transcript hash was 32 bytes of 01 (this length would make sense for SHA-256), the content covered by the digital For finite field groups, a conventional Diffie-Hellman computation is performed.  The negotiated key (Z) is converted to a byte string by  <ins> encoding in big-endian and left padded with zeros up to the size of the prime.  This byte string is used as the shared secret in the key </ins> schedule as specified above. Note that this construction differs from previous versions of TLS


"OPTIONAL" in this document are to be interpreted as described in RFC 2119 RFC2119.  1.2. draft-06

PR for suggestion for issue .
Is this helping?
Glossaries are usually a good thing, but pretty much everything in there is either in need of pruning out or is better explained in its relevant section. The HTTP/2 spec just includes a really short glossary of basic terms up top: URL This seems like a better way to do this.
Not sure if this is the best route, but creating a PR for it was quick to do.
I'm in favor of removing the glossary. I don't think there's any need to explain what AES, DSA, etc. is in this document. Maybe it was needed when it first came out but it's not needed now. The only definition I thought might be needed is application layer/application layer protocol, but if you read s1 (right before where these terms will go) the concepts of layering on top of TLS is explained well enough in my mind. I could see adding a definition for "resumption" though.
Define resumption in-line with the text when it is first used, maybe. But I like Dave's change.
I can live with that too. Having it defined will hopefully stop these kind of things: URL
Merged.

"OPTIONAL" in this document are to be interpreted as described in RFC 2119 RFC2119. <ins> The following terms are used: client: The endpoint initiating the TLS connection. connection: A transport-layer connection between two endpoints. endpoint: Either the client or server of the connection. handshake: An initial negotiation between client and server that establishes the parameters of their transactions. peer: An endpoint.  When discussing a particular endpoint, "peer" refers to the endpoint that is remote to the primary subject of discussion. receiver: An endpoint that is receiving records. sender: An endpoint that is transmitting records. session: An association between a client and a server resulting from a handshake. server: The endpoint which did not initiate the TLS connection. </ins> 1.2. draft-06


exporter_master_secret unless explicitly specified by the application.  The early_exporter_master_secret is defined for use in settings where an exporter is needed for 0-RTT data.  A separate <del> interface for the early exporter is RECOMMENDED. </del>  If no context is provided, the context_value is zero-length. Consequently, providing no context computes the same value as

We currently have which is a little confusing, since it doesn't note that the server has the non-early exporter available once it has generated its first flight, and doubly so since the actual motivation for separate interfaces is for security reasons of not accidentally using the early exporter when the main one is needed. (Split out from )

exporter_master_secret unless explicitly specified by the application.  The early_exporter_master_secret is defined for use in settings where an exporter is needed for 0-RTT data.  A separate  <ins> interface for the early exporter is RECOMMENDED; this avoids the exporter user accidentally using an early exporter when a regular one is desired or vice versa. </ins> If no context is provided, the context_value is zero-length. Consequently, providing no context computes the same value as


%%% Key Exchange Messages <del> X and Y respectively are the binary representations of the X and Y </del>  values in network byte order.  There are no internal length markers, so each number representation occupies as many octets as implied by the curve parameters.  For P-256 this means that each of X and Y use take 48 octets each, and for P-521 they take 66 octets each. For the curves secp256r1, secp384r1 and secp521r1, peers MUST <del> validate each other's public value Y by ensuring that the point is a </del>  valid point on the elliptic curve.  The appropriate validation procedures are defined in Section 4.3.7 of X962 and alternatively in Section 5.6.2.3 of KEYAGREEMENT.  This process consists of three <del> steps: (1) verify that the point (X, Y) is not the point at infinity (O), (2) verify that both X and Y are integers in the correct interval, (3) ensure that (X, Y) is a correct solution to the elliptic curve equation.  For these curves, implementors do not need </del>  to verify membership in the correct subgroup. For X25519 and X448, the contents of the public value are the byte

I might do "both integers x and y" but I can see how it would be okay as-is.

%%% Key Exchange Messages  <ins> X and Y respectively are the binary representations of the x and y </ins> values in network byte order.  There are no internal length markers, so each number representation occupies as many octets as implied by the curve parameters.  For P-256 this means that each of X and Y use take 48 octets each, and for P-521 they take 66 octets each. For the curves secp256r1, secp384r1 and secp521r1, peers MUST  <ins> validate each other's public value Q by ensuring that the point is a </ins> valid point on the elliptic curve.  The appropriate validation procedures are defined in Section 4.3.7 of X962 and alternatively in Section 5.6.2.3 of KEYAGREEMENT.  This process consists of three  <ins> steps: (1) verify that Q is not the point at infinity (O), (2) verify that for Q = (x, y) both integers x and y are in the correct interval, (3) ensure that (x, y) is a correct solution to the elliptic curve equation.  For these curves, implementers do not need </ins> to verify membership in the correct subgroup. For X25519 and X448, the contents of the public value are the byte


9.3. This section describes invariants that TLS endpoints and middleboxes <del> MUST follow.  It also applies to earlier versions, which assumed these rules but did not document them. </del>  TLS is designed to be securely and compatibly extensible.  Newer clients or servers, when communicating with newer peers, should

ClientHello, etc., processing rules are in earlier versions too. We're just calling out some corollaries of it all.

9.3. This section describes invariants that TLS endpoints and middleboxes  <ins> MUST follow.  It also applies to earlier versions of TLS. </ins> TLS is designed to be securely and compatibly extensible.  Newer clients or servers, when communicating with newer peers, should


OIDs and supplied a certificate that does not satisfy the request, the server MAY at its discretion either continue the connection without client authentication, or abort the handshake with an <del> "unsupported_certificate" alert. </del>  PKIX RFCs define a variety of certificate extension OIDs and their corresponding value types.  Depending on the type, matching

We should say something about whether the same OID is allowed to appear multiple times in the oid_filters extension (and if it is, what the semantics are). Extracted from
As noted in my comments, there is a natural semantic for multiple, but it seems a bit silly. I think it would be fine to forbid them, though.
I think it's OK to limit to one appearance of a given OID in the oid_filters. (It probably does not matter much in terms of code complexity either way.)
I'm inclined to limit to one appearance of a given OID in oid_filters.
I guess it's implicit that there is no meaning to the order in which oid/values appear, and we don't need to say anything about that.

OIDs and supplied a certificate that does not satisfy the request, the server MAY at its discretion either continue the connection without client authentication, or abort the handshake with an  <ins> "unsupported_certificate" alert.  Any given OID MUST NOT appear more than once in the filters list. </ins> PKIX RFCs define a variety of certificate extension OIDs and their corresponding value types.  Depending on the type, matching


%%% Record Layer <del> The TLSPLaintext.fragment value, containing the byte encoding of a </del>  handshake or an alert message, or the raw bytes of the application's data to send.

I believe the markdown has not yet been sent to the RFC Editor, so we can save them the trouble by getting this in.

%%% Record Layer  <ins> The TLSPlaintext.fragment value, containing the byte encoding of a </ins> handshake or an alert message, or the raw bytes of the application's data to send.


indicate which signature algorithms it can validate in X.509 certificates.  Additionally, this document clarifies some compliance requirements for earlier versions of TLS; see protocol-invariants. [[OPEN ISSUE: Should we remove this?  I am reluctant to create a situation where one needs to read 8446 to process this document.]]  This document uses several registries that were originally created in RFC4346 and updated in RFC8447.  IANA has updated these to reference this document.  The registries and their allocation policies are

I wasn't sure where to put this text. There was an Appendix talking about TLS 1.2, so I figured it could go nearby. And then it probably wanted to go before that Appendix so there isn't ambiguity about how to refer to EMS.
Implementations of TLS 1.2 will remain for some time. The document renames "master secret" to "main secret", but TLS 1.2 has some naming variations that aren't in TLS 1.3. Perhaps a section in the document somewhere (maybe under Backward Compatibility since that talks about older versions) that describes some additional deltas: "master secret" => "main secret", to align this this document "premaster secret" => "preliminary secret" ("pre-main secret" sounds weird to me) "extended master secret" => "extended main secret" (probably move rfc7627 from informative to normative and then also add to the updates line) Also cover the variations like "EncryptedPreMasterSecret" and "mastersecret", but not the KDF labels since those can't change. And then IANA considerations to rename extendedmastersecret to extendedmain_secret in the registries.

indicate which signature algorithms it can validate in X.509 certificates. <ins> The term "master" as applied to secrets has been removed, and the "extended_master_secret" extension RFC7627 has been renamed to "extended_main_secret". </ins> Additionally, this document clarifies some compliance requirements for earlier versions of TLS; see protocol-invariants. [[OPEN ISSUE: Should we remove this?  I am reluctant to create a situation where one needs to read 8446 to process this document.]] <ins> [[OPEN ISSUE: Add some text to rename the extended_master_secret entry in the extensions registry to extended_main_secret, after the above is resolved.]] </ins> This document uses several registries that were originally created in RFC4346 and updated in RFC8447.  IANA has updated these to reference this document.  The registries and their allocation policies are