PSK). The client MUST send a Certificate message if and only if the server <del> has requested client authentication via a CertificateRequest message (certificate-request).  If the server requests client authentication but no suitable certificate is available, the client MUST send a Certificate message containing no certificates (i.e., with the "certificate_list" field having length 0).  A Finished message MUST be sent regardless of whether the Certificate message is empty. </del>  Structure of this message: values, these two values are always the same. Note: Although the resumption main secret depends on the client's <del> second flight, a server which does not request client authentication MAY compute the remainder of the transcript independently and then send a NewSessionTicket immediately upon sending its Finished rather than waiting for the client Finished.  This might be appropriate in cases where the client is expected to open multiple TLS connections in parallel and would benefit from the reduced overhead of a resumption handshake, for example. </del>  %%% Ticket Establishment 4.6.2. When the client has sent the "post_handshake_auth" extension (see <del> post_handshake_auth), a server MAY request client authentication at any time after the handshake has completed by sending a CertificateRequest message.  The client MUST respond with the appropriate Authentication messages (see authentication-messages). If the client chooses to authenticate, it MUST send Certificate, CertificateVerify, and Finished.  If it declines, it MUST send a Certificate message containing no certificates followed by Finished. All of the client's messages for a given response MUST appear consecutively on the wire with no intervening messages of other types. </del>  A client that receives a CertificateRequest message without having sent the "post_handshake_auth" extension MUST send an "unexpected_message" fatal alert. <del> Note: Because client authentication could involve prompting the user, servers MUST be prepared for some delay, including receiving an arbitrary number of other messages between sending the CertificateRequest and receiving a response.  In addition, clients which receive multiple CertificateRequests in close succession MAY respond to them in a different order than they were received (the certificate_request_context value allows the server to disambiguate the responses). </del>  4.6.3.

Based on the PSK authentication was not included in the past. I think specification has some places where "Client Authentication" refer to only certificate-based client authentication and not client authentication is general. Not a big thing, but I think it might confuse some readers, and would be good to clarify.

PSK). The client MUST send a Certificate message if and only if the server  <ins> has requested certificate-based client authentication via a CertificateRequest message (certificate-request).  If the server requests certificate-based client authentication but no suitable certificate is available, the client MUST send a Certificate message containing no certificates (i.e., with the "certificate_list" field having length 0).  A Finished message MUST be sent regardless of whether the Certificate message is empty. </ins> Structure of this message: values, these two values are always the same. Note: Although the resumption main secret depends on the client's  <ins> second flight, a server which does not request certificate-based client authentication MAY compute the remainder of the transcript independently and then send a NewSessionTicket immediately upon sending its Finished rather than waiting for the client Finished. This might be appropriate in cases where the client is expected to open multiple TLS connections in parallel and would benefit from the reduced overhead of a resumption handshake, for example. </ins> %%% Ticket Establishment 4.6.2. When the client has sent the "post_handshake_auth" extension (see  <ins> post_handshake_auth), a server MAY request certificate-based client authentication at any time after the handshake has completed by sending a CertificateRequest message.  The client MUST respond with the appropriate Authentication messages (see authentication- messages).  If the client chooses to authenticate, it MUST send Certificate, CertificateVerify, and Finished.  If it declines, it MUST send a Certificate message containing no certificates followed by Finished.  All of the client's messages for a given response MUST appear consecutively on the wire with no intervening messages of other types. </ins> A client that receives a CertificateRequest message without having sent the "post_handshake_auth" extension MUST send an "unexpected_message" fatal alert.  <ins> Note: Because certificate-based client authentication could involve prompting the user, servers MUST be prepared for some delay, including receiving an arbitrary number of other messages between sending the CertificateRequest and receiving a response.  In addition, clients which receive multiple CertificateRequests in close succession MAY respond to them in a different order than they were received (the certificate_request_context value allows the server to disambiguate the responses). </ins> 4.6.3.


"extension_data" contains information specific to the particular extension type.  The list of extension types is maintained by IANA as described in iana-considerations.

This was already a compliance requirement, but spell it out more explicitly.
LGTM
AFAICT it isn't. URL also comes to mind
NAME Good catch.
It's already required. Length prefixes typically come from the syntax in the presentation language. Not only would a parser that allows trailing data be non-compliant, but it'd be totally incoherent. Vectors don't tell you the number of elements, so the only way to parse it is to loop until empty, peeling off s. That means, if there is any trailing data, it'll be immediately interpreted as another instance of , not trailing data. Whereas is a little different because it's an byte string whose contents happen to be another structure. TBH, I don't think this case needed a clarification either (it's pretty obvious, IMO), but a clarification doesn't hurt so whatever.
NAME I think that you are right when it comes to lists of things. I was thinking about structs in general. However, in QUIC, we have transport parameters, which would share the need for this exact treatment; that we decided to manage that within QUIC rather than use the TLS grammar means that we don't need to worry about it, but it suggests that nested extension points will hit this problem too. I was trying to find other such instances, but I can't find any offhand. I was looking at , and that uses a statement, which suggests that it is simply impossible to include a non-zero type value (another reason that server name extension is irredeemably busted; and of course, that's not how NSS implements it; from memory, we assume every type has a 1 byte length prefix...). I thought that handshake messages might need this, but the grammar seems to prevent that in the same way as servername. An unknown handshake message hits a switch statement and falls out, presumably into an error condition. So even though the format might allow an unknown handshake message to be ignored the grammar suggests that it is always an error (which, to be clear, is a good thing from a protocol perspective). The encapsulation of handshake messages in records is another place that is interesting. In TLS, that doesn't matter much because the extra bytes roll over and we are back in your "next instance of " case, but it is a problem in DTLS where each record needs to contain discrete fragments. So I do think that it would be better to have this be a general statement, even if it there is precisely one instance where we know it definitely applies.
the only place where trailing data is allowed is after ClientHello for implementations that don't support extensions
A receiver will not necessarily parse every entry in the vector, if it finds what it's looking for before it gets through the whole vector.
Hmm. Where were you envisioning putting this generally? The definition of various length prefixes are kind of scattered all over the place.
Section 3.9?
As far as I can tell, there is no requirement in RFC 8446 for receiving endpoints to verify that the self-encoded length on outer headers corresponds to the self-encoded lengths of component items. Mangled extensions that do this kind of thing are likely going to end up with decoding errors, but if the outer length is too long many implementations might survive, assuming they support the extension. If it's not too onerous on implementations, it would be good to require a fatal alert if receivers detect this condition, to make behavior more predictable and ease debugging.
Which lengths are you referring to? I can't think of any length prefixes in RFC8446 that receivers are allowed to ignore. Are you saying that, if the length prefix on is longer than the structure inside it, receivers are allowed to ignore trailing data? I'd consider any implementation that allowed this non-compliant. The spec often contains text like: It doesn't say the body has a prefix of a CertificateAuthoritiesExtension structure. (And, of course, if the length prefix is too short, you'll hit the end of before you finish parsing the inner structure at all.)
Obviously, bogus extension_data lengths are wrong, but there's no enforcement mechanism. If receivers MUST check that these match and abort if they don't, that would have the benefits described above. I think we're agreeing that ignoring trailing data would be wrong, but it's not actually written anywhere AFAICT. Equally obviously, this is not the end of the world and TLS has apparently operated fine like this for a long time. But it's also the kind of problem that QUIC has spent a fair amount of energy to avoid.
I think it is already the case that receivers MUST check this. Receivers that don't are non-compliant. It's written somewhat implicitly by way of saying the body "consists of" such-and-such structure, but I think the most reasonable interpretation of this would be that you don't allow trailing data. I'd support adding a sentence or two to the section 4.2 to clarify how extension definitions work in general. Though I've never heard of an implementation that misinterpreted this and did the wrong thing.
Agree and NAME I don't know of any implementation that allows extending a field with arbitrary data and then ignoring it. They all do "I have 'n' bytes and am expecting a CertificateList" and if they finish with data left over it's a parse error.
If the consensus is that this is a non-problem I am happy to have the editors close the issue.
It's entirely possible that I missed a MUST in 8446 somewhere, but I couldn't find it.
I don't think a sentence to make this clear would be harmful.
How's URL
Why is this specific to extension_data? Why not require this for every length-prefixed construct that contains fields that might not extend to the full length?

"extension_data" contains information specific to the particular extension type. <ins> The contents of the "extension_data" field are typically defined by an extension-specific structure defined in the TLS presentation language.  Unless otherwise specified, trailing data is forbidden. That is, senders MUST NOT include data after the structure in the "extension_data" field.  When processing an extension, receivers MUST abort the handshake with a "decode_error" alert if there is data left over after parsing the structure.  This does not apply if the receiver does not implement or is configured to ignore an extension. </ins> The list of extension types is maintained by IANA as described in iana-considerations.


over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. <del> This document updates RFCs 5705 and 6066 and obsoletes RFCs 5077, 5246, and 6961.  This document also specifies new requirements for TLS 1.2 implementations. </del>  1.

The paragraph "This document supersedes and obsoletes previous" in the introduction also needs to be updated...

over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.  <ins> This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, and 8446.  This document also specifies new requirements for TLS 1.2 implementations. </ins> 1.


contain all zero bits are stripped before it is used as the pre_master_secret. <del> Note: Diffie-Hellman parameters are specified by the server and may be either ephemeral or contained within the server's certificate. </del> 8.1.3. All ECDH calculations (including parameter and key generation as well

This applies to TLS 1.3 draft 4. The ffdhe groups in Section 7.3.2.5.2 aren't up-to-date with draft-ietf-tls-negotiated-ff-dhe-04: ffdhe2432(256) has been replaced with ffdhe2048(256). ffdhe6144(259) is no more. ffdhe8192(260) has been renumbered to ffdhe8192(259). The note in Section 8.1.3 has text that refers to the old TLS 1.2 and earlier key exchange method, where the server could select any DH-parameters it liked. NamedGroup and NamedGroupList should be added to somewhere in appendix A.
Thanks. WRT to the appendix, I am going to let it get out of date for a draft or two and then do a mass update.
I am now auto-generating the appendix, so it will hopefully get less out of sync
Grubba, PTAL at the Pull Request above.
Looks good to me.
The latest FFDHE-draft (06) has reintroduced FFDHE-6144, and replaced FFDHE-2048 with FFDHE-2432, so this issue should probably be reopened.

contain all zero bits are stripped before it is used as the pre_master_secret.  8.1.3. All ECDH calculations (including parameter and key generation as well


IMPORTANT NOTE: The security properties for 0-RTT data are weaker than those for other kinds of TLS data.  Specifically: <del> This data is not forward secret, as it is encrypted solely under keys derived using the offered PSK. </del>  There are no guarantees of non-replay between connections. Protection against replay for ordinary TLS 1.3 1-RTT data is If the tickets are not self-contained but rather are database keys, and the corresponding PSKs are deleted upon use, then connections <del> established using PSKs enjoy forward secrecy.  This improves security for all 0-RTT data and PSK usage when PSK is used without (EC)DHE. </del>  Because this mechanism requires sharing the session database between server nodes in environments with multiple distributed servers, it

This is following issue . 0-RTT data may sometimes be forward-secret, and sometimes not. This commit attempts to clarify that in Sections 2.3 and 8.1.
This is great. Thanks so much for writing this up!
"forward secret" as an adjective is wierd.
Presumably because it doesn't indicate in what circumstances it's forward secret (e.g. it could be completely random). Maybe it's more accurate to say "forward secret only under certain circumstances on the server side."
How about this: The protocol does not provide any forward secrecy guarantees for this data. The server's behavior determines what forward secrecy guarantees, if any, are applicable (see {{single-use-tickets}}). This behavior is not communicated to the client as part of the protocol. Therefore, absent out-of-band knowledge of the server's behavior, the client should assume that this data is not forward secret. Thanks Carrick :-) NAME NAME What do you think?
NAME Sounds good to me.
NAME please send me a PR to add your name to the acknowledgements.
Section 2.3 states that "This [0-RTT] data is not forward secret, as it is encrypted solely under keys derived using the offered PSK." However, Section 8.1 states "If the tickets are not self-contained but rather are database keys, and the corresponding PSKs are deleted upon use, then connections established using PSKs enjoy forward secrecy. This improves security for all 0-RTT data." What does "improves security" mean here? Does it mean that the 0-RTT data is forward secret in this case? If not, why not?
Forward secrecy is something of a relative property; a given connection X gains forward secrecy with respect to future compromise of entity Y when secret Z is discarded. There are further subtleties, such as if X is still active when Y is compromised then X might still actually be compromised even if Z has already been discarded, but considering all three of X, Y, and Z are necessary to make statements about forward secrecy with any precision. The thing that we typically mean these days when we talk about "forward secrecy" without further precision is that an ephemeral (e.g., (EC)DH) key exchange mechanism is used, and we're implicitly picking one endpoint X as the subject of discussion, so that Y is the communications peer and Z is the peer's ephemeral DH value. This requires some level of trust in the peer, since a malicious peer could fail to destroy Z or just retain the data in question in some other form. 0-RTT data is protected by a PSK associated with a session ticket, and when the server is using stateless session tickets, the PSK itself is encrypted to the server using the STEK. So the only forward secrecy available to such 0-RTT data is when the STEK is discarded, which we typically recommend to be on an hours to days timescale (but could in principle be much longer, and there are no doubt many sites that essentially never rotate their STEK); given the lack of knowledge of the peer/server behavior, clients should not assume that they have any forward secrecy guarantee for 0-RTT data they send in this case. When tickets are not stateless but rather are database keys, the server knowledge of the PSK used to protect the 0-RTT data is tied to the database entry for the ticket, and so the PSK can be discarded sooner than in the stateless-ticket case; in the single-use ticket case the server's copy of the PSK is expected to be destroyed when the resumed session is established, which would provide a similar timescale of forward secrecy for the client that a typical ECDH exchange would provide. But the client still has little visibility into what strategy the server is using, and might be ill-advised to place much confidence in the forward secrecy of its offered 0-RTT data, absent out-of-band knowledge of the server's behavior.
Thanks! It's much clearer to me now.
This seems okay. I don't get excited by having the initial statement be "not necessarily forward secret" but can't put my finger on exactly why, and I don't have an alternative suggestion, so I won't object to this.

IMPORTANT NOTE: The security properties for 0-RTT data are weaker than those for other kinds of TLS data.  Specifically:  <ins> The protocol does not provide any forward secrecy guarantees for this data.  The server's behavior determines what forward secrecy guarantees, if any, apply (see single-use-tickets).  This behavior is not communicated to the client as part of the protocol. Therefore, absent out-of-band knowledge of the server's behavior, the client should assume that this data is not forward secret. </ins> There are no guarantees of non-replay between connections. Protection against replay for ordinary TLS 1.3 1-RTT data is If the tickets are not self-contained but rather are database keys, and the corresponding PSKs are deleted upon use, then connections  <ins> established using PSKs enjoy not only anti-replay protection, but also forward secrecy once all copies of the PSK from the database entry have been deleted.  This mechanism also improves security for PSK usage when PSK is used without (EC)DHE. </ins> Because this mechanism requires sharing the session database between server nodes in environments with multiple distributed servers, it


The client MAY use this PSK for future handshakes by including the ticket value in the "pre_shared_key" extension in its ClientHello <del> (pre-shared-key-extension).  Servers MAY send multiple tickets on a single connection, either immediately after each other or after </del>  specific events (see client-tracking).  For instance, the server might send a new ticket after post-handshake authentication in order to encapsulate the additional client authentication state.  Multiple

Resumption before the initial connection is closed does not seem to be forbidden but RFC 8446 does not really give any answers. Oxford dictionary defines resumption as "the action of beginning something again after a pause or interruption." but I think "resumption" should just be seen as a slightly misleading name for the mechanism. RFC 8446 makes it clear that a connection can result in several tickets and that these tickets can be used in parallel with each other. My assumption would be that the tickets can also be used in parallel with the initial connection. If that is the case it would be good to state this. If not, it would be good to state that as well. The question came up in RFC6083bis where the suggestion is to set up parallel connections. I made a PR with the assumption that it’s allowed. I don’t see any reasons to forbid it, but I might miss something.
I concur that resumption should be permitted once the initial connection is established. I would prefer not to change the name, just because it's historically confusing not to.
Rich asked about SNI, but there are other values for extensions that might be included in a resumption handshake to cover the possibility that the session cannot be resumed. We should probably talk about that a little in the draft, maybe even throw a few "MUST" or "SHOULD" statements at it.
Resumption replaced by PSK so this is generally OBE.

The client MAY use this PSK for future handshakes by including the ticket value in the "pre_shared_key" extension in its ClientHello  <ins> (pre-shared-key-extension).  Resumption MAY be done while the original connection is still open.  Servers MAY send multiple tickets on a single connection, either immediately after each other or after </ins> specific events (see client-tracking).  For instance, the server might send a new ticket after post-handshake authentication in order to encapsulate the additional client authentication state.  Multiple


value using: [sender] denotes the sending side.  The value of Secret for each <del> record type is shown in the table below. </del>  <del> All the traffic keying material is recomputed whenever the underlying Secret changes (e.g., when changing from the handshake to Application Data keys or upon a key update). </del>  7.4.

I cannot find any specification in RFC8446 of which key is used to encrypt an alert or heartbeat sent before Finished (I assume it is the applicationtrafficsecret). It is definitly possible that this information is somewhere in the document and that I just do not find it. The document seems to treat "record type" and "content type" as synonyms. Are both terms needed? I would suggest updating table in section 7.3 to make it complete. Record type "Application Data" should probably be everything that is not a Handshake. It would be good to say something about post-handshake messages in section 7.3. Post-handshake messages have record type/content type Handshake but does not follow what the table in 7.3 says.
The key is not specified as some errors can make it impossible for the peer to send an alert under specific key, so the used key is implicit—the currently used one, whichever it happens to be, including plaintext.
True, thank for reminding me. That is quite simple. Given that, I think the table in Section 7.3 is confusing and and not even correct. It claims to give the secret for each record type, but only lists 2. "0-RTT Application" is not a record type..... It gives the idea that the secret follows from the record type, which is not correct. It claims that record type Handshake is protected with [sender]handshaketraffic_secret, but record type handshake is protected with all three secrets depending on the state. I think it would probably be better to remove the table in 7.3 than to keep the current version. Even better would be to replace 7.3 with a more correct description.

value using: [sender] denotes the sending side.  The value of Secret for each  <ins> category of data is shown in the table below. </ins>  <ins> Alerts are sent with the then current sending key (or as plaintext if no such key has been established.)  All the traffic keying material is recomputed whenever the underlying Secret changes (e.g., when changing from the handshake to Application Data keys or upon a key update). </ins> 7.4.


with the new key.  Failure to do so may allow message truncation attacks.  5. The TLS record protocol takes messages to be transmitted, fragments

Note that this is precisely the language that appears in 9147.
I made some updates, and am just merging in anticipation of the draft deadline. Feel free to file a PR if you think changes are indicated. NAME
In URL we added some text to DTLS about how rekeying too many times (2^64 is allowed with the 64-bit DTLS 1.3 epoch) risks key reuse within a connection, and accompanied it with a MUST NOT guidance to rekey more than 2^48 times (but receivers MUST NOT enforce the rule); this overrides the usual MUST-level requirement to match an "update_requested" KeyUpdate with another KeyUpdate before sending more data. It seems that some similar considerations apply for non-D TLS as well.

with the new key.  Failure to do so may allow message truncation attacks. <ins> With a 128-bit key as in AES-128, rekeying 2^64 times has a high probability of key reuse within a given connection.  Note that even if the key repeats, the IV is also independently generated, so the chance of a joint key/IV collision is much lower.  In order to provide an extra margin of security, sending implementations MUST NOT allow the epoch - and hence the number of key updates - to exceed 2^48-1.  In order to allow this value to be changed later - for instance for ciphers with more than 128-bit keys - receiving implementations MUST NOT enforce this rule.  If a sending implementation receives a KeyUpdate with request_update set to "update_requested", it MUST NOT send its own KeyUpdate if that would cause it to exceed these limits and SHOULD instead ignore the "update_requested" flag.  This may result in an eventual need to terminate the connection when the limits in limits-on-key-usage are reached. </ins> 5. The TLS record protocol takes messages to be transmitted, fragments


along with the new ClientHello.  For instance, if the client sends ClientHello1, its binder will be computed over: <del> Where Truncate() removes the binders list from the ClientHello. </del>  If the server responds with a HelloRetryRequest and the client then sends ClientHello2, its binder will be computed over: hash computations.  Note that in the first flight, Truncate(ClientHello1) is hashed directly, but in the second flight, ClientHello1 is hashed and then reinjected as a "message_hash" <del> message, as described in the-transcript-hash. </del>  4.2.11.3.

The function is defined using a function . URL This is presumably the KDF hash of the cipher suite, but this doesn't seem to be written down anywhere. The Key Schedule section says: URL I can't find corresponding text in the various other calls. We could define this globally in the Transcript Hash section, and indeed that fits with the claim that "In general, implementations can implement the transcript by keeping a running transcript hash value based on the negotiated hash." But then we have another problem... The PSK binder is also defined in terms of Transcript-Hash. Like the other text, it does not define what Hash is. URL But the default definition doesn't work for the client, in two different ways: At the first ClientHello, the cipher suite hash algorithm isn't even known yet, so we cannot possibly use that one. At the second ClientHello, we have a cipher suite hash algorithm, but it may not necessarily match the PSK's one. To keep all everything injective, both need to be the PSK hash. Though this results in another subtlety which, while not ambiguous, maybe we should change: At the second ClientHello, there are two uses of Hash. There's the overall hash, which is stuck being the PSK one, and there's the funny . That one being the PSK's hash breaks the whole notion of the transcript being this append-only thing and is a huge pain. To compensate, we allowed the second ClientHello to . That works, but it's a pretty weird edge case and easily a source of bugs. What if we changed it to be the negotiated hash? It won't affect interop, since this PSK is guaranteed not to be negotiated. The client may as well fill in all zeros for the binder. It's also still injective, as long as everyone agrees that's the one we use. The transcript includes an unhashed HelloRetryRequest immediately after messagehash, so that fixes the choice of hash. (Plus we only have two hashes right now and they're different sizes...)

along with the new ClientHello.  For instance, if the client sends ClientHello1, its binder will be computed over:  <ins> Where Truncate() removes the binders list from the ClientHello.  Note that this hash will be computed using the hash associated with the PSK, as the client does not know which cipher suite the server will select. </ins> If the server responds with a HelloRetryRequest and the client then sends ClientHello2, its binder will be computed over: hash computations.  Note that in the first flight, Truncate(ClientHello1) is hashed directly, but in the second flight, ClientHello1 is hashed and then reinjected as a "message_hash"  <ins> message, as described in the-transcript-hash.  Note that the "message_hash" will be hashed with the negotiated function, which may or may match the hash associated with the PSK.  This is consistent with how the transcript is calculated for the rest of the handshake. </ins> 4.2.11.3.


handshake for some reason unrelated to a protocol failure.  If a user cancels an operation after the handshake is complete, just closing the connection by sending a "close_notify" is more <del> appropriate.  This alert SHOULD be followed by a "close_notify". This alert generally has AlertLevel=warning. </del>  Either party MAY initiate a close of its write side of the connection <del> 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. </del>  Each party MUST send a "close_notify" alert before closing its write side of the connection, unless it has already sent some error alert.

The new CFRG curves will probably have different point formats.
This was decided and will be handled as part of import

handshake for some reason unrelated to a protocol failure.  If a user cancels an operation after the handshake is complete, just closing the connection by sending a "close_notify" is more  <ins> appropriate.  This alert MUST be followed by a "close_notify". This alert generally has AlertLevel=warning.  Receiving implementations should continue to read data from the peer until a "close_notify" is received, though they MAY log or otherwise record them. </ins> Either party MAY initiate a close of its write side of the connection  <ins> by sending a "close_notify" alert.  Any data received after a "close_notify" 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. </ins> Each party MUST send a "close_notify" alert before closing its write side of the connection, unless it has already sent some error alert.


result.  Received data is decrypted and verified, reassembled, and then delivered to higher-level clients. <del> Four protocols that use the record protocol are described in this </del>  document: the handshake protocol, the alert protocol, and the application data protocol.  In order to allow extension of the TLS protocol, additional record content types can be supported by the

Four instead of three ? (hs, alert, app_data) Allusion to CCS ... ? Cheers, B.

result.  Received data is decrypted and verified, reassembled, and then delivered to higher-level clients.  <ins> Three protocols that use the record protocol are described in this </ins> document: the handshake protocol, the alert protocol, and the application data protocol.  In order to allow extension of the TLS protocol, additional record content types can be supported by the


ticket age formed by taking the age in milliseconds and adding the "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 ticket lifetimes are restricted to a week, 32 bits is enough to represent any plausible age, even in milliseconds. </del>  4.2.11.2.

The document has a section on Client Tracking Prevention which is what is relevant for the Web. For IoT the TLS server is often a device. That device might be something that a person takes with them. Motivation for changes is given by the charter.
This seems to be an easy fix. Just chaning the heading from "client tracking prevention" to "client and server tracking prevention" seems to do the job
Fixed
I cannot find anything in the document regarding this which is surprising as reusing key shares enables tracking I cannot find anything in the document that states that reuse of keys are allowed or forbidden but my understanding from earlier discussions in the TLS WG is that this is allowed as summarized in draft-ietf-tls-hybrid-design TLS 1.3 does not require that ephemeral public keys be used only in a single key exchange session; some implementations may reuse them Key shares should probably have similar text as Tickets Clients SHOULD NOT reuse a ticket for multiple connections. Reuse of a ticket allows passive observers to correlate different connections. But the requirement for key share applies to both clients and servers. The sentence "This addition prevents passive observers from correlating connections unless tickets are reused." is not correct unless both tickets and key shares are not reused.
Found that Illari raised this on the TLS list in October but Illari's comment did not seem to get any response which is also surprising. You can probably get a paper published by investigating how reuse of key shares enables tracking. URL
For clients the considerations seems very similar to reuse of tickets. The client is in charge of its own privacy. The server side seems more worrying. A server reusing key shares between two clients can be used by an attacker to correlate connections between two different clients and use that to figure out the server even when ECH is used.
Motivation for normative SHOULD NOT (or MUST NOT) change can be found in charter-ietf-tls-06 Security and privacy goals will place emphasis on the following: Identify and mitigate other (long-term) user tracking or fingerprinting vectors enabled by TLS deployments and implementations. Should there be "SHOULD NOT reuse key shares between client hellos"? I did't find such requirement (or maybe it is there but I just missed it), which I think is odd, given that there is similar requirement for tickets, and reusing key shares has similar impact as reusing tickets. Such reuse is especially bad if SNI differs, or if the group is not actually safe for key reuse. (In case of hybrid key exchanges, implementations might reuse shares within the same client hello. E.g., reusing the same X25519 key both for x25519 and x25519+kyber768.) And then section 5.5 contains "SHOULD not". I presume that should be "SHOULD NOT". -Ilari

ticket age formed by taking the age in milliseconds and adding the "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 or key shares are reused. Note that the "ticket_lifetime" field in the NewSessionTicket message is in seconds but the "obfuscated_ticket_age" is in milliseconds. Because ticket lifetimes are restricted to a week, 32 bits is enough to represent any plausible age, even in milliseconds. </ins> 4.2.11.2.


Reception of a handshake_failure alert message indicates that the sender was unable to negotiate an acceptable set of security <del> parameters given the options available.  This is a fatal error. </del>  This alert was used in SSLv3 but not any version of TLS.  It MUST

I have seen multiple implementations with messages marked as warning instead of fatal.. It might be more explicit this way ? B.
I like this because some folks never read the text they just look at the code.

Reception of a handshake_failure alert message indicates that the sender was unable to negotiate an acceptable set of security  <ins> parameters given the options available.  This message is always fatal. </ins> This alert was used in SSLv3 but not any version of TLS.  It MUST


Authentication: The server side of the channel is always authenticated; the client side is optionally authenticated. Authentication can happen via asymmetric cryptography (e.g., RSA <del> RSA, the Elliptic Curve Digital Signature Algorithm (ECDSA) ECDSA, </del>  or the Edwards-Curve Digital Signature Algorithm (EdDSA) RFC8032) or a symmetric pre-shared key (PSK). "signature_algorithms" and "signature_algorithms_cert" for backward compatibility with TLS 1.2. <del> Indicates a signature algorithm using ECDSA ECDSA, the corresponding curve as defined in ANSI X9.62 ECDSA and FIPS 186-4 DSS, and the corresponding hash algorithm as defined in SHS.  The signature is represented as a DER-encoded X690 ECDSA-Sig-Value structure as defined in RFC4492. </del>  Indicates a signature algorithm using RSASSA-PSS with a mask generation function of MGF1, as defined in RFC8017.  The digest %%% Supported Groups Extension Indicates support for the corresponding named curve, defined in <del> either FIPS 186-4 DSS or in RFC7748.  Values 0xFE00 through 0xFEFF are reserved for Private Use RFC8126. </del>  Indicates support for the corresponding finite field group, defined in RFC7919.  Values 0x01FC through 0x01FF are reserved for For the curves secp256r1, secp384r1, and secp521r1, peers MUST validate each other's public value Q by ensuring that the point is a valid point on the elliptic curve.  The appropriate validation <del> procedures are defined in Section 4.3.7 of ECDSA and alternatively in </del>  Section 5.6.2.3 of KEYAGREEMENT.  This process consists of three 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

FIPS 186-4 is obsolete Curve definitions have moved to the new NIST SP 800-186 ANSI X9.62 is behind a paywall and should be avoided if possible. References behind paywall can not be accessed by most readers. This makes it harder to implement and to evaluate the security of the protocol. FIPS 186-5 removed the dependency on ANSI X9.62 and defines ECDSA itself. Point validation is defined in the new NIST SP 800-186.

Authentication: The server side of the channel is always authenticated; the client side is optionally authenticated. Authentication can happen via asymmetric cryptography (e.g., RSA  <ins> RSA, the Elliptic Curve Digital Signature Algorithm (ECDSA) DSS, </ins> or the Edwards-Curve Digital Signature Algorithm (EdDSA) RFC8032) or a symmetric pre-shared key (PSK). "signature_algorithms" and "signature_algorithms_cert" for backward compatibility with TLS 1.2.  <ins> Indicates a signature algorithm using ECDSA DSS, the corresponding curve as defined in NIST SP 800-186 ECDP, and the corresponding hash algorithm as defined in SHS.  The signature is represented as a DER-encoded X690 ECDSA-Sig-Value structure as defined in RFC4492. </ins> Indicates a signature algorithm using RSASSA-PSS with a mask generation function of MGF1, as defined in RFC8017.  The digest %%% Supported Groups Extension Indicates support for the corresponding named curve, defined in  <ins> either NIST SP 800-186 ECDP or in RFC7748.  Values 0xFE00 through 0xFEFF are reserved for Private Use RFC8126. </ins> Indicates support for the corresponding finite field group, defined in RFC7919.  Values 0x01FC through 0x01FF are reserved for For the curves secp256r1, secp384r1, and secp521r1, peers MUST validate each other's public value Q by ensuring that the point is a valid point on the elliptic curve.  The appropriate validation  <ins> procedures are defined in Appendix D.1 of ECDP and alternatively in </ins> Section 5.6.2.3 of KEYAGREEMENT.  This process consists of three 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


There are cryptographic limits on the amount of plaintext which can be safely encrypted under a given set of keys.  AEAD-LIMITS provides an analysis of these limits under the assumption that the underlying <del> primitive (AES or ChaCha20) has no weaknesses.  Implementations SHOULD do a key update as described in key-update prior to reaching these limits.  Note that it is not possible to perform a KeyUpdate for early data and therefore implementations SHOULD not exceed the limits when sending early data. </del>  For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be encrypted on a given connection while keeping a safety margin of

but tell receiving implementations not to enforce them. This addresses . NAME PTAL.
Limits on Key Usage (Section 5.5): Since key updates are necessary for security, I think MUST (rather than SHOULD) is appropriate. (And similarly in the sentence that follows: "Note that it is not possible to perform a KeyUpdate for early data and therefore implementations SHOULD not exceed the limits when sending early data.")
IIRC there was a disagreement on when the rekeying should happen, and more specifically, the limits for Chacha20-Poly1305 are higher than the limit imposed by TLS sequence numbers, so there's no need to rekey if all you support is Chacha20...
NAME That seems compatible with MUST: Section 5.5 also notes: It follows that implementations might not do a key update.
I don't necessarily object to a MUST but I think as with the limit on KeyUpdate it would need to be paired with a MUST NOT enforce on the receiver. As I understand it, these bounds aren't necessarily tight, so we might have some results that allowed fewer rekeys in the future.

There are cryptographic limits on the amount of plaintext which can be safely encrypted under a given set of keys.  AEAD-LIMITS provides an analysis of these limits under the assumption that the underlying  <ins> primitive (AES or ChaCha20) has no weaknesses.  Implementations MUST either close the connection or do a key update as described in key- update prior to reaching these limits.  Note that it is not possible to perform a KeyUpdate for early data and therefore implementations MUST not exceed the limits when sending early data.  Receiving implementations SHOULD NOT enforce these limits, as future analyses may result in updated values. </ins> For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be encrypted on a given connection while keeping a safety margin of


MUST specify how TLS works with their application protocol, including how and when handshaking occurs, and how to do identity verification. I-D.ietf-uta-rfc6125bis provides useful guidance on integrating TLS <del> with applicaiton protocols. </del>  This document defines TLS version 1.3.  While TLS 1.3 is not directly compatible with previous versions, all versions of TLS incorporate a 1.2. <del> TLS 1.3 was originally specified in RFC8446.  This document is solely an editorial update.  It contains updated text in areas which were found to be unclear as well as other editorial improvements.  In addition, it removes the use of the term "master" as applied to secrets in favor of the term "main" or shorter names where no term was neccessary. </del>  1.3. the CertificateRequest message in the main handshake, though they MAY send it in post-handshake authentication (see post-handshake- authentication) provided that the client has sent the <del> "post_handshake_auth" extension (see post_handshake_auth).  Servers which are authenticating with an external PSK MUST NOT send the </del>  CertificateRequest message either in the main handshake or request <del> post-handshake authentication.  Future specifications MAY provide an extension to permit this. </del>  4.4. closing the connection by sending a "close_notify" is more appropriate.  This alert MUST be followed by a "close_notify". This alert generally has AlertLevel=warning.  Receiving <del> implementations should continue to read data from the peer until a </del>  "close_notify" is received, though they MAY log or otherwise record them. the values are referred to as "main" secrets.  This mismatch is a result of renaming the values while retaining compatibility. <del> [[OPEN ISSUE: Replace the strings with hex value?]] </del> The general pattern here is that the secrets shown down the left side of the diagram are just raw entropy without context, whereas the secrets down the right side include Handshake Context and therefore

Change "should" -> "SHOULD" around user_canceled Replicate the 8773 language to another place where external PSKs is discussed. Remove an OPEN ISSUE marker

MUST specify how TLS works with their application protocol, including how and when handshaking occurs, and how to do identity verification. I-D.ietf-uta-rfc6125bis provides useful guidance on integrating TLS  <ins> with application protocols. </ins> This document defines TLS version 1.3.  While TLS 1.3 is not directly compatible with previous versions, all versions of TLS incorporate a 1.2.  <ins> TLS 1.3 was originally specified in RFC8446.  This document is a minor update to TLS 1.3 that retains the same version number and is backward compatible.  It tightens some requirements and contains updated text in areas which were found to be unclear as well as other editorial improvements.  In addition, it removes the use of the term "master" as applied to secrets in favor of the term "main" or shorter names where no term was necessary.  This document makes the following specific technical changes: Forbid negotiating TLS 1.0 and 1.1 as they are now deprecated by RFC8996. Removes ambiguity around which hash is used with PreSharedKeys and HelloRetryRequest. Require that clients ignore NewSessionTicket if they do not support resumption. Upgrade the requirement to initiate key update before exceeding key usage limits to MUST. Limit the number of permitted KeyUpdate messages. Restore text defining the level of "close_notify" to "warning". Clarify behavior around "user_canceled", requiring that "close_notify" be sent and that "user_canceled" should be ignored. Add a "general_error" generic alert. In addition, there have been some improvements to the security considerations, especially around privacy. </ins> 1.3. the CertificateRequest message in the main handshake, though they MAY send it in post-handshake authentication (see post-handshake- authentication) provided that the client has sent the  <ins> "post_handshake_auth" extension (see post_handshake_auth).  In the absence of some other specification to the contrary, servers which are authenticating with an external PSK MUST NOT send the </ins> CertificateRequest message either in the main handshake or request  <ins> post-handshake authentication.  RFC8773 provides an extension to permit this, but has not received the level of analysis as this specification. </ins> 4.4. closing the connection by sending a "close_notify" is more appropriate.  This alert MUST be followed by a "close_notify". This alert generally has AlertLevel=warning.  Receiving  <ins> implementations SHOULD continue to read data from the peer until a </ins> "close_notify" is received, though they MAY log or otherwise record them. the values are referred to as "main" secrets.  This mismatch is a result of renaming the values while retaining compatibility.  The general pattern here is that the secrets shown down the left side of the diagram are just raw entropy without context, whereas the secrets down the right side include Handshake Context and therefore


11. <del> [[OPEN ISSUE: Should we remove this?  I am reluctant to create a situation where one needs to read 8446 to process this document.]] [[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.]] </del> This document uses several registries that were originally created in <del> RFC4346 and updated in RFC8447.  IANA has updated these to reference this document.  The registries and their allocation policies are below: </del>  TLS Cipher Suites registry: values with the first byte in the range 0-254 (decimal) are assigned via Specification Required value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126. IESG Approval is REQUIRED for a Y->N transition.

To keep the text in 8446bis and to avoid having people to read 8446 (and address the OPEN issues) in the IANA Considerations section - from IANA: If you want to keep the old actions in the document, we’d like to see those actions preceded by an introduction or sub-section (or more than one sub-section; however it’s appropriate to structure it) that tells us what the new actions are for this document.
The diffs are informative here - I think there's only adding general_error to TLS Alerts and updating the references to RFC 8446bis vice RFC 8446.
Apologies for any confusion - already address via .

11.  This document uses several registries that were originally created in  <ins> RFC4346 and updated in RFC8446 and RFC8447.  The changes between RFC8446 and RFC8447 this document are described in bis-changes.  IANA has updated these to reference this document. The registries and their allocation policies are below: </ins> TLS Cipher Suites registry: values with the first byte in the range 0-254 (decimal) are assigned via Specification Required value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126. IESG Approval is REQUIRED for a Y->N transition. <ins> 11.1. IANA [shall rename/has renamed] the "extended_master_secret" value in the TLS ExtensionType Values registry to "extended_main_secret". IANA [shall create/has created] a value for the "general_error" alert in the TLS Alerts Registry with the value given in alert-protocol. </ins>


session not be resumed.  This is a change from TLS 1.0 to conform with widespread implementation practice. <del> Either party may initiate a close by sending a close_notify alert. </del>  Any data received after a closure alert is ignored. Unless some other fatal alert has been transmitted, each party is

It refers to potentially sending a message so I would say its caps, though I am not sure about this one ...

session not be resumed.  This is a change from TLS 1.0 to conform with widespread implementation practice.  <ins> Either party MAY initiate a close by sending a close_notify alert. </ins> Any data received after a closure alert is ignored. Unless some other fatal alert has been transmitted, each party is


"extension_data" contains information specific to the particular extension type. <del> The initial set of extensions is defined in a companion document TLSEXT.  The list of extension types is maintained by IANA as described in iana-considerations. </del>  An extension type MUST NOT appear in the ServerHello unless the same extension type appeared in the corresponding ClientHello.  If a Note: this extension is not meaningful for TLS versions prior to 1.2. Clients MUST NOT offer it if they are offering prior versions. <del> However, even if clients do offer it, the rules specified in TLSEXT </del>  require servers to ignore extensions they do not understand. Servers MUST NOT send this extension.  TLS servers MUST support restrictions) MUST be compatible with the selected key exchange algorithm. <del> The "server_name" and "trusted_ca_keys" extensions TLSEXT are used to guide certificate selection. </del>  If the client provided a "signature_algorithms" extension, then all certificates provided by the server MUST be signed by a hash/

The TLS 1.2 RFC cited WIP extension definitions at time of publish. Update current draft to point the final RFC 6066.
URL Fix merged. This should be closable now.

"extension_data" contains information specific to the particular extension type.  <ins> The initial set of extensions is defined in RFC6066.  The list of extension types is maintained by IANA as described in iana- considerations. </ins> An extension type MUST NOT appear in the ServerHello unless the same extension type appeared in the corresponding ClientHello.  If a Note: this extension is not meaningful for TLS versions prior to 1.2. Clients MUST NOT offer it if they are offering prior versions.  <ins> However, even if clients do offer it, the rules specified in RFC6066 </ins> require servers to ignore extensions they do not understand. Servers MUST NOT send this extension.  TLS servers MUST support restrictions) MUST be compatible with the selected key exchange algorithm.  <ins> The "server_name" and "trusted_ca_keys" extensions RFC6066 are used to guide certificate selection. </ins> If the client provided a "signature_algorithms" extension, then all certificates provided by the server MUST be signed by a hash/


If the negotiated key exchange algorithm is ECDHE_ECDSA, behave as if the client had sent value {sha1,ecdsa}. <del> Note: this is a change from TLS 1.1 where there are no explicit rules, but as a practical matter one can assume that the peer supports MD5 and SHA-1. </del> Note: this extension is not meaningful for TLS versions prior to 1.2. Clients MUST NOT offer it if they are offering prior versions. However, even if clients do offer it, the rules specified in RFC6066 signature algorithm pair that appears in that extension.  Note that this implies that a certificate containing a key for one signature algorithm MAY be signed using a different signature algorithm (for <del> instance, an RSA key signed with a DSA key).  This is a departure from TLS 1.1, which required that the algorithms be the same. </del>  If the server has multiple certificates, it chooses one of them based on the above-mentioned criteria (in addition to other criteria, such

These two notes are leftover from TLS 1.2 and not needed anymore in TLS 1.3. The first may not even be valid anymore.

If the negotiated key exchange algorithm is ECDHE_ECDSA, behave as if the client had sent value {sha1,ecdsa}.  Note: this extension is not meaningful for TLS versions prior to 1.2. Clients MUST NOT offer it if they are offering prior versions. However, even if clients do offer it, the rules specified in RFC6066 signature algorithm pair that appears in that extension.  Note that this implies that a certificate containing a key for one signature algorithm MAY be signed using a different signature algorithm (for  <ins> instance, an RSA key signed with a DSA key). </ins> If the server has multiple certificates, it chooses one of them based on the above-mentioned criteria (in addition to other criteria, such


close_notify is more appropriate.  This alert should be followed by a close_notify.  This message is generally a warning. <del> no_renegotiation Sent by the client in response to a ServerHello or </del>  by the server in response to a ClientHello after initial handshaking. Versions of TLS prior to TLS 1.3 supported renegotiation of a previously established connection; TLS 1.3 removes this feature.

Sorry 'bout all that me re-learning git again.
Assuming I've learned git properly, fixing the above should just be: git reset --hard HEAD~2 git push -f (done on this branch, of course; check branch log before pushing!)
Whenever you do a , always, ALWAYS specify a destination. You can be screwed by your config if you don't. The alternative is to do this: and open a new pull request. No force pushes that way (just a dead branch somewhere).

close_notify is more appropriate.  This alert should be followed by a close_notify.  This message is generally a warning.  <ins> no_renegotiation Sent by the client in response to a HelloRequest or </ins> by the server in response to a ClientHello after initial handshaking. Versions of TLS prior to TLS 1.3 supported renegotiation of a previously established connection; TLS 1.3 removes this feature.


This alert was used in some earlier versions of TLS, and may have permitted certain attacks against the CBC mode CBCATT.  It MUST <del> NOT be sent by compliant implementations. </del>  A TLSCiphertext record was received that had a length more than This alert was used in previous versions of TLS.  TLS 1.3 does not include compression and TLS 1.3 implementations MUST NOT send this <del> alert when in TLS 1.3 mode. </del>  Reception of a "handshake_failure" alert message indicates that This alert was used in SSLv3 but not any version of TLS.  It MUST <del> NOT be sent by compliant implementations. </del>  A certificate was corrupt, contained signatures that did not This alert was used in some earlier versions of TLS.  It MUST NOT <del> be sent by compliant implementations. </del>  The protocol version the peer has attempted to negotiate is

Expands on NAME improvements. The obsolete alerts were previously fatal and still are. Mark them as such. Also fix one of their names which is missing the "_RESERVED" in the descriptions list.

This alert was used in some earlier versions of TLS, and may have permitted certain attacks against the CBC mode CBCATT.  It MUST  <ins> NOT be sent by compliant implementations.  This message is always fatal. </ins> A TLSCiphertext record was received that had a length more than This alert was used in previous versions of TLS.  TLS 1.3 does not include compression and TLS 1.3 implementations MUST NOT send this  <ins> alert when in TLS 1.3 mode.  This message is always fatal. </ins> Reception of a "handshake_failure" alert message indicates that This alert was used in SSLv3 but not any version of TLS.  It MUST  <ins> NOT be sent by compliant implementations.  This message is always fatal. </ins> A certificate was corrupt, contained signatures that did not This alert was used in some earlier versions of TLS.  It MUST NOT  <ins> be sent by compliant implementations.  This message is always fatal. </ins> The protocol version the peer has attempted to negotiate is


The record protection functions translate a TLSPlaintext structure into a TLSCiphertext.  The deprotection functions reverse the process.  In TLS 1.3 as opposed to previous versions of TLS, all <del> ciphers are modelled as "Authenticated Encryption with Additional </del>  Data" (AEAD) RFC5116.  AEAD functions provide a unified encryption and authentication operation which turns plaintext into authenticated ciphertext and back again. ClientHello. Servers MUST NOT send the EarlyData extension.  Negotiating TLS 1.3 <del> serves as acknowledgement that it was processed as described above. </del>  [[OPEN ISSUE: This is a fairly general mechanism which is possibly overkill in the 1-RTT case, where it would potentially be more

(includes )
I'll let native speakers fix the typos next time xD
Your intuition on how to treat that last one was not wrong, but you need to know the specifics of the terminology to handle it properly. If that weren't a specific term, you'd have been correct, though usage of the word "compatible" there would've been strange. As to hyphenation, tech terminology turns hyphenated words into compound words way faster than natural language evolution. In other words, we tend to make up new words frequently and write them shorter each time. ;)
In my experience, native speakers are usually far from the best :)
Native speakers can muddle through free-form usage easily, so they don't notice how bad things might be to others. Non-native speakers can't intuitively piece together words as easily, and thus follow the rules more, which can be problematic because no verbal language actually follows its own rules fully, especially ones with lots of borrowed words. We all screw up language in different and interesting ways. :p I think a rebase is needed, as the whitespace changes were merged via your other PR. A squash of these commits into one to drop the reverted bits is probably a good idea, while you're at it.
Done, ready for merge... =)

The record protection functions translate a TLSPlaintext structure into a TLSCiphertext.  The deprotection functions reverse the process.  In TLS 1.3 as opposed to previous versions of TLS, all  <ins> ciphers are modeled as "Authenticated Encryption with Additional </ins> Data" (AEAD) RFC5116.  AEAD functions provide a unified encryption and authentication operation which turns plaintext into authenticated ciphertext and back again. ClientHello. Servers MUST NOT send the EarlyData extension.  Negotiating TLS 1.3  <ins> serves as acknowledgment that it was processed as described above. </ins> [[OPEN ISSUE: This is a fairly general mechanism which is possibly overkill in the 1-RTT case, where it would potentially be more


peers.  There are a number of ways in which a man-in-the-middle attacker can attempt to make two entities drop down to the least secure method they support.  The protocol has been designed to <del> minimize this risk, but there are still attacks available: for </del>  example, an attacker could block access to the port a secure service <del> runs on, or attempt to get the peers to negotiate an unauthenticated </del>  connection.  The fundamental rule is that higher levels must be cognizant of what their security requirements are and never transmit information over a channel less secure than what they require.  The TLS protocol is secure in that any cipher suite offers its promised <del> level of security: if you negotiate AES-GCM GCM with a 1024-bit DHE key exchange with a host whose certificate you have verified, you can expect to be that secure. </del>  These goals are achieved by the handshake protocol, which can be summarized as follows: The client sends a ClientHello message which

A newer recommendation could be put in as a replacement, however I don't think the sentence adds anything to the explanation, nor do I expect whatever could be recommended to hold up forever. Also fix some punctuation in the same paragraph.
Ok, I've added a new security recommendation. I'm listing a TODO with it, though, as Curve25519 is probably what we're going with as MTI for a reasonable expectation of security and there's nothing to cite yet. I don't think we'd want P256 cited in there for the baseline recommendation. This is fine until the MTIs are updated, I think. People would probably say 2048 DHE is fine, which for now it is, but I went with 3072 to match the same security level for the curve. Might need to discuss on list.
I actually expect P256 to be the MTI based on the discussion in person and on-list. Given that RSA 2048 seems to be what browsers are pushing, I suspect that that's what's needed here.
I essentially have no problem with that currently, but this spec will be around for quite a while. I'd rather have the new general purpose expectations in the new spec so that this will age better. (you could argue I'm overthinking this, though) I could also just drop the DHE and list only ECDHE.
I'm fine with changing this to 256-bit EC keys, but note that you'll want to refer to that for signatures as well.
Ok. I've switched it to just 255 bit ECDHE and added 224 bit ECDSA as the minimum signature. (arguably the latter could be higher, but we went with 112 bit symmetric in the backwards compatibility restrictions) I'm specifically going with 255 instead of 256 so Curve25519 isn't ruled out by a bit.
TLS 1.2 currently supports a number of ciphersuites and mechanisms that are little-used or outdated. In particular SHA-1, MD5, RC4, DSA with any modulus size, RSA with small moduli. Some of these will get chopped out as a result of other issues, but others will not.
Dependencies: SHA1: PR MD5: PR RC4: PR DSA: PR weak RSA: PR Statuses: the pending PR drops SHA1 to SHOULD NOT MD5 is currently MUST NOT & PR also adds a MUST always error if seeing it RC4 is currently a MUST NOT DSA is pending decision & discussion on-list (issue ; PR ) weak RSA is currently considered "not appropriate" with the following text: Merging the pending PRs listed as dependencies above should be sufficient to close this issue.
This is done

peers.  There are a number of ways in which a man-in-the-middle attacker can attempt to make two entities drop down to the least secure method they support.  The protocol has been designed to  <ins> minimize this risk, but there are still attacks available.  For </ins> example, an attacker could block access to the port a secure service  <ins> runs on or attempt to get the peers to negotiate an unauthenticated </ins> connection.  The fundamental rule is that higher levels must be cognizant of what their security requirements are and never transmit information over a channel less secure than what they require.  The TLS protocol is secure in that any cipher suite offers its promised  <ins> level of security: if you negotiate AES-GCM GCM with a 255-bit ECDHE key exchange with a host whose certificate chain you have verified, you can expect that to be reasonably secure. </ins> These goals are achieved by the handshake protocol, which can be summarized as follows: The client sends a ClientHello message which


Reduce maximum permitted record expansion for AEAD from 2048 to 256 octets.  draft-07 Integration of semi-ephemeral DH proposal. %%% Authentication Messages opaque ASN1Cert<1..2^24-1>; <del> This is a sequence (chain) of certificates.  The server's </del>  certificate MUST come first in the list.  Each following <del> certificate MUST directly certify the one preceding it.  Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certification authority (CA) MAY be omitted from the chain, under the assumption that the client must already possess it in order to validate it in any case. </del>  The same message type and structure will be used for the client's response to a certificate request message.  Note that a client MAY

Current client implementations allow more flexible certificate ordering than the spec allows and some server implementations send certificates in orders that the spec says "MUST" not be done. Relaxing the language here to a "SHOULD" is appropriate so implementers following this spec know that such situations need to be handled. Enforcing this more strictly would cause interop problems for no practical gain. The modified language here is based on the mailing list discussion.
This seems like a really bad idea, since it will reduce interoperability even further.
If you'd like to explain how formally documenting existing behavior (that we are not otherwise proposing be changed) will somehow reduce interoperability further, then please do so on the mailing list. This proposal is only to properly document existing capabilities such that all readers of the spec actually know what to expect here. Not doing this requires either intentionally having a part of the spec we know to be wrong in practice, or changing this to require more strict error enforcement that would break interop.
Ryan Sleevi posted to the list an in-depth argument as to why the prior requirement can be considered harmful. I'll cite it here for reference, as the threads on this topic got long and winding: URL
Rebased. NAME Last discussion of this on-list ended with lots of agreement and one strong dissenter. Are you able to declare a rough consensus to merge this, or is more discussion needed? Note that this is already in "running code", as this merely documents existing practice in some implementations.
NAME can this be merged?
NAME Ok, revised and rebased. Please take a look.
Rebased. FTR in this PR, question from NAME answered on-list: URL URL (GitHub's logic is that if you comment on a commit directly, as apposed to the changeset in the PR, then rebasing ditches your comment from the PR; old comments on the PR get collapsed above, but are still here) NAME I don't know the WG policy here. Is NAME approval sufficient sign-off for you to merge, or do we need NAME Quoting from the list: On Wed, Aug 26, 2015 at 02:11:01PM -0700, Joseph Salowey wrote: [question asked and satisfactorily answered by Viktor Dukhovni; link above] On Wed, Aug 26, 2015 at 10:25:07PM -0700, Joseph Salowey wrote: So, is this finally ready to land now? Thanks Viktor, I missed this part of the discussion. The text looks fine to me as is. Joe , Viktor Dukhovni wrote: >
That's not true. I've explicitly stated it's a BAD requirement, and tried to give concrete examples. I'll be explicit: 1) I think clients, such as Martin's, that implement normative checking of ordering and are used for the Internet at large (e.g. between servers and clients that are not controlled by a single entity) are bad for Internet security. 2) I think clients, such as Martin's and Geoff's, that do not implement RFC 4158 path discovery are bad for Internet security. 3) I think language that encourages or requires clients to normatively enforce such ordering are bad for Internet security. So to be clear, I disagree with my colleague, Ben Laurie, rather substantially here. The context is that: 1) I'm involved in maintaining one of the largest client web browsers' PKI stack. Thus, I deal with brokenness on a daily basis. 2) I'm involved in dealing with the PKI stacks of a variety of platforms, some open-source, some closed-source, and with a variety of versions. 3) I'm involved in the CA/Browser Forum and have spent the past several years trying to work in deprecation of insecure cryptography (in the case of certificates, SHA-1, RSA signatures <= 1024-bits, and in general, RSA signatures vs ECC) I say all this to say "I've seen things", and when it comes to gross hacks, few people are as more affected and have more visibility to them than those doing things similar to me. All of that to say I think the current language encourages bad practice. In my original email, I tried to establish why: 1) Clients have disparate trust-stores. Absent the X.500 directory, this is a fact of life. The set of trust anchors recognized by Microsoft will and is different than those recognized by Mozilla, for a variety of legitimate reasons that will not change, no matter what the IETF does. 2) As such, there is no single trusted path. RFC 4158 spells this out in abundant detail, and the figures contained should be "required skimming" for any of this discussion. 3) Implementing path discovery is hard. RFC 4158 spells out why. It's also necessary, as the first two points here spell out. Clients that don't support RFC 4158 "break" if a trusted path cannot be found. In order to handle deprecations of SHA-1, for example, certificate paths need to be replaced with their SHA-256 equivalent. To handle the deprecation of RSA-1024 bit, alternative paths must be supplied. To handle the deprecation of RSA in favour of ECC, alternative paths must be supplied. If you fail to supply those, clients break. When clients break, servers have to choose between breaking clients and doing the right thing or keeping clients working. For obvious and understandable business reasons, "keeping clients working" is always going to be the preferable case. "Keeping clients working" is equivalent to "holding security back" So servers do the sensible thing. They try to find a way to keep clients working WHILE doing the right thing. This takes many forms. The most obvious and understandable being supply all the paths the server knows about to the client. Clients that don't do "insecure AIA fetching" (as Martin likes to pejoratively phrase it, as I disagree with him on this point substantially), but that thankfully don't implement Martin's strict checking (which luckily, few do), this works as a viable means of providing acceptable paths to them. At the cost of violating the TLS RFC in a part of language that enforcing requires more work and introduces more security issues to clients. If every client had RFC 4158 capable path discovery, would I still advocate relaxing the language? Honestly, yes, because it should be up to the server to balance the tradeoffs between client interoperability. If every client enforced the TLS requirements, as Martin advocates, it would directly and concretely harm the ability to push for reform in the PKI system used by the most prominent deployment of TLS (the HTTPS Web), because clients that lack "insecure AIA fetching" would simply break when the Web PKI changes. There are many ways to mitigate this, and luckily, modern cryptographic libraries are starting to see the wisdom that Microsoft saw nearly 10 years ago, when they made CryptoAPI automatically update the trust store and handle trust migrations. However, in an IoT world, where things are using libraries like OpenSSL, and which lack RFC 4158 path discovery, I'm increasingly concerned that we will see greater ossification and calcification of the PKI stores, preventing much needed security reform. So yes, I do see this current language as objectively and quantifiably BAD for security. I think implementing it in a TLS client library (since it is NOT required of PKI libraries or implementations, and RFC 4158 rightly dissuades it) introduces more attack surface and more complexity for negative gains on security and maintainability.

Reduce maximum permitted record expansion for AEAD from 2048 to 256 octets. <ins> Relax certificate_list ordering requirement to match current practice. </ins> draft-07 Integration of semi-ephemeral DH proposal. %%% Authentication Messages opaque ASN1Cert<1..2^24-1>;  <ins> This is a sequence (chain) of certificates.  The sender's </ins> certificate MUST come first in the list.  Each following  <ins> certificate SHOULD directly certify one preceding it.  Because certificate validation requires that trust anchors be distributed independently, a self-signed certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates they may require. Note: Prior to TLS 1.3, "certificate_list" ordering was required to be strict, however some implementations already allowed for some flexibility.  For maximum compatibility, all implementations SHOULD be prepared to handle potentially extraneous certificates and arbitrary orderings from any TLS version (with the exception of the sender's certificate).  Some servers are configured to send both a current and deprecated intermediate for transitional purposes, and others are simply configured incorrectly, but these cases can nonetheless be validated properly by clients capable of doing so. Whilst the chain MAY be ordered in a variety of ways, the peer's end- entity certificate MUST be the first element in the vector, and implementations MUST abort with a fatal "bad_certificate" alert in the event that this is not the case. </ins> The same message type and structure will be used for the client's response to a certificate request message.  Note that a client MAY


11. Security issues are discussed throughout this memo, especially in <del> Appendices D, E, and F. </del>  12.

Removal of the glossary re-assigned the appendix letters, so the ones referenced here are all one earlier.

11. Security issues are discussed throughout this memo, especially in  <ins> Appendices C, D, and E. </ins> 12.


fatal. <del> This alert was used in SSLv3 but not any version of TLS.  It MUST NOT be sent by compliant implementations.  This message is always fatal. </del>  A certificate was corrupt, contained signatures that did not The interaction of the certificate_types and supported_signature_algorithms fields is somewhat complicated. <del> certificate_types has been present in TLS since SSLv3, but was </del>  somewhat underspecified.  Much of its functionality is superseded by supported_signature_algorithms.  The following rules apply: iana-considerations. Note: Values listed as RESERVED MUST NOT be used.  They were used in <del> SSLv3. </del>  Note: It is a fatal "handshake_failure" alert for an anonymous server to request client authentication.

Small editorial change: The document currently goes back and forth between "SSLv3" & "SSL 3.0". Stick with the latter for consistency and clarity.

fatal.  <ins> This alert was used in SSL 3.0 but not any version of TLS.  It MUST NOT be sent by compliant implementations.  This message is always fatal. </ins> A certificate was corrupt, contained signatures that did not The interaction of the certificate_types and supported_signature_algorithms fields is somewhat complicated.  <ins> certificate_types has been present in TLS since SSL 3.0, but was </ins> somewhat underspecified.  Much of its functionality is superseded by supported_signature_algorithms.  The following rules apply: iana-considerations. Note: Values listed as RESERVED MUST NOT be used.  They were used in  <ins> SSL 3.0. </ins> Note: It is a fatal "handshake_failure" alert for an anonymous server to request client authentication.


Remove support for MD5 and SHA-224 hashes with signatures.  draft-07 Integration of semi-ephemeral DH proposal. This is a list of the cryptographic options supported by the client, with the client's first preference first.  Values are <del> defined in the-cipher-suite. </del>  Versions of TLS before 1.3 supported compression and the list of In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the cipher <del> suite TODO:Needs to be selected [1].  (See the-cipher-suite for the </del>  definition.) 9. 10. Security issues are discussed throughout this memo, especially in <del> Appendices C, D, and E. </del>  11.

This revises "The Cipher Suites" section to simplify redundant language, actually explain the de facto naming convention, and add all currently available AEAD cipher suites. It also drops the appendix table that has already had its section whittled down quite a bit, in favor of the explanation and new table in the main section. Note that this is all of the AEAD ciphers available in the current IANA registry [0], plus ChaChaPoly (which has to be a normative reference [1], so must reach RFC status before this does). Issue just said "standards track AEAD ciphers", but as the registry lists them all, adding them wasn't difficult. If we'd rather not cite them here then they can of course be cut out (ARIA, Camellia, & ECDHE AES-CCM are informational; the rest are standards track, including DHE AES-CCM). Alternatively, the table could be annotated to note which are on what track or split in two. This has no changes to any requirements. [0] URL [1] URL
NAME I addressed your comments in this new commit. I switched to a table to make things easier to read and explicitly clarified the constant string bits so as to be more clear. I also dropped the confusing sentence fragment.
looks good.
AES-OCB will also be addable to this list, but its codepoints are all completely TBD still. URL
Rebased, squashed, & updated for recent changes to draft.
Ok, all comments addressed with that last commit. I've split the table into standards and non-standards and simplified the note to just mention ECDHE AES GCM being widely deployed.
Rebased.
Ok, reworded that bit too.
I only added the GCM AEAD ciphers. We should add all the standards track AEAD ciphers.
NAME This was dealt with in PR and can be closed.

Remove support for MD5 and SHA-224 hashes with signatures. <ins> Revise list of currently available AEAD cipher suites. </ins> draft-07 Integration of semi-ephemeral DH proposal. This is a list of the cryptographic options supported by the client, with the client's first preference first.  Values are  <ins> defined in cipher-suites. </ins> Versions of TLS before 1.3 supported compression and the list of In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the cipher  <ins> suite TODO:Needs to be selected [1].  (See cipher-suites for the </ins> definition.) 9. 10. Security issues are discussed throughout this memo, especially in  <ins> Appendices B, C, and D. </ins> 11.


HMAC(finished_secret, finished_label + '0' + handshake_hash) <del> where HMAC uses the Hash algorithm for the handshake.  See the- handshake-hash for the definition of handshake_hash. </del>  For Finished messages sent by the client, the string "client shown below. The derivation process is as follows, where L denotes the length of <del> the underlying hash function for HKDF. </del>  The traffic keys are computed from xSS, xES, and the master_secret as described in traffic-key-calculation below.

Use refs for HKDF & HMAC in the document and drop the unused AES CBC RFC ref in favor of the AES GCM RFCs (refs already in use). Caught via Travis warnings that they were all unused. It also notes that RFC 2246 (TLS 1.0) isn't referenced directly and RFC 5705 isn't used, either. NAME You probably wanted to reference RFC 5705 somewhere in your recent work, but it's not currently used. Travis also complains about I-D.ietf-tls-session-hash, though that is referenced in the credits. It probably should be referenced somewhere too.
I've also added an update to the "obsoletes" line. We don't need to list TLS 1.1 (TLS 1.2 & 1.3 don't list 1.0), its extensions RFC, or AES CBC, as they've already been obsoleted by TLS 1.2 (also obsoleted old AES RFC) and the newer extensions RFC.

HMAC(finished_secret, finished_label + '0' + handshake_hash)  <ins> where HMAC RFC2104 uses the Hash algorithm for the handshake.  See the-handshake-hash for the definition of handshake_hash. </ins> For Finished messages sent by the client, the string "client shown below. The derivation process is as follows, where L denotes the length of  <ins> the underlying hash function for HKDF RFC5869. </ins> The traffic keys are computed from xSS, xES, and the master_secret as described in traffic-key-calculation below.


6.3.1.5.3. <del> The known_configuration extension allows the client to indicate that it wishes to reuse the server's known configuration and semi-static (EC)DHE key (see server-configuration for how to establish these configurations.  This extension allows the omission of the server certificate and signature, with three potential benefits: </del>  Shortening the handshake because the certificate may be large. the server's (EC)DHE key from the identified configuration and the client's key found in the ClientKeyShare.  If no key from an acceptable group is in the ClientKeyShare, the server MUST ignore the <del> known_configuration extension.  When this mechanism is used, the </del>  server MUST NOT send a Certificate/CertificateVerify message unless the ServerConfiguration message is also sent. <del> When the known_configuration data extension is in use, the handshake hash is extended to include the server's configuration data and certificate (see the-handshake-hash) so as to tightly bind them </del>  together. 6.3.1.5.4. <del> The pre_shared_key extension is used to indicate the identity of the pre-shared key to be used with a given handshake in association with a PSK or (EC)DHE-PSK cipher suite (see RFC4279 for background). </del>  %%% Hello Messages the application traffic key.  This message creates a pre-shared key (PSK) binding between the resumption master secret and the ticket label.  The client MAY use this PSK for future handshakes by <del> including it in the pre_shared_key extension in its ClientHello (pre- shared-key-extension) and supplying a suitable PSK cipher suite. </del>  %%% Ticket Establishment struct { uint32 ticket_lifetime_hint; opaque ticket<0..2^16-1>; } NewSessionTicket;

Some fixes for things I didn't catch when I checked for typos in the big patch last time. Of note, you're missing a closing brace for the select in "PreSharedKeyExtension" and a semicolon after "KnownConfigurationExtension". I also corrected things to match the existing (admittedly unusual) indentation style of the document and put quotes around the extension IDs you missed. (some had them; some didn't)
Ok, spaces between cases reverted. I also added a similar bit of whitespace in another new extension.

6.3.1.5.3.  <ins> The "known_configuration" extension allows the client to indicate that it wishes to reuse the server's known configuration and semi- static (EC)DHE key (see server-configuration for how to establish these configurations.  This extension allows the omission of the server certificate and signature, with three potential benefits: </ins> Shortening the handshake because the certificate may be large. the server's (EC)DHE key from the identified configuration and the client's key found in the ClientKeyShare.  If no key from an acceptable group is in the ClientKeyShare, the server MUST ignore the  <ins> "known_configuration" extension.  When this mechanism is used, the </ins> server MUST NOT send a Certificate/CertificateVerify message unless the ServerConfiguration message is also sent.  <ins> When the "known_configuration" data extension is in use, the handshake hash is extended to include the server's configuration data and certificate (see the-handshake-hash) so as to tightly bind them </ins> together. 6.3.1.5.4.  <ins> The "pre_shared_key" extension is used to indicate the identity of the pre-shared key to be used with a given handshake in association with a PSK or (EC)DHE-PSK cipher suite (see RFC4279 for background). </ins> %%% Hello Messages the application traffic key.  This message creates a pre-shared key (PSK) binding between the resumption master secret and the ticket label.  The client MAY use this PSK for future handshakes by  <ins> including it in the "pre_shared_key" extension in its ClientHello (pre-shared-key-extension) and supplying a suitable PSK cipher suite. </ins> %%% Ticket Establishment struct { uint32 ticket_lifetime_hint; opaque ticket<0..2^16-1>; } NewSessionTicket;


"NamedGroupList" value: %%% Named Group Extension enum { // Elliptic Curve Groups. <del> obsolete_RESERVED (1..13), sect571r1 (14), obsolete_RESERVED (15..22), secp256r1 (23), secp384r1 (24), secp521r1 (25), </del>  Indicates support of the corresponding named curve.  Note that

It appears to be the consensus that sect571r1 should be dropped. This drops it and adds placeholders for the CFRG curves. There are likely to be more than these two values in the final version to indicate ECDHE & certificate usage separately.
NAME shall we remove sect571r1 Let's let the CFRG draft get a little further along before we add the placeholders.
On Wednesday, July 15, 2015 06:23:48 pm ekr wrote: Ok. I dropped that bit and pushed a new commit here.
Rob Stradling just posted to the list that he suspects that most users of this curve are just due to implementations blindly picking the biggest number, not because it was actually chosen. OpenSSL seems to do this by default and doesn't really provide an obvious way to change that.

"NamedGroupList" value: %%% Named Group Extension enum { // Elliptic Curve Groups.  <ins> obsolete_RESERVED (1..22), secp256r1 (23), secp384r1 (24), secp521r1 (25), </ins> Indicates support of the corresponding named curve.  Note that