The actual content type of the record is found in fragment.type after decryption. <del> The record_version field is identical to TLSPlaintext.record_version and is always { 3, 1 }.  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.fragment, which is the sum of the lengths of the content and the padding,

From the past three times we've bumped the version, reality has unequivocally told us that the TLS version negotiation, as described in previous specifications, has been a collossal failure. The working group decided not to replace the mechanism with a more sustainable one, so do the next best thing in trying to save TLS from itself. If the fields are renamed to what they actually are ('serverversion' is the true version and 'clientversion' is a maximum), then perhaps we'll have some hope of future implementors getting it right, if we ever clear through the prior iterations of the bug. While I'm here, remove the mention of 'The protocol version the current record is compatible with' for recordversion. recordversion is purely vestigial.
+1
This sounds like a good idea, however for the server version I'd go with "negotiatedversion" to be more precise. For "recordversion", we could also extend the "legacy" prefix convention we've started using and change it to "legacyrecordversion" to remind that it's a deprecated field.
Hrm. We don't name other fields like ServerHello.negotiatedciphersuite and such. Though if we wanted to be consistent with those fields, it should be ClientHello.maxversion rather than ClientHello.maxsupportedversion. Dunno, maybe that would be better... maxsupported_version is a bit wordy. (Though I do think breaking pattern on the ClientHello version is justified because that field is already inconsistent with everything else in TLS. The version is the only place where the client doesn't offer a list, so everything else already self-describes as a "pick one of these" type of field.) Done.

The actual content type of the record is found in fragment.type after decryption.  <ins> The legacy_record_version field is identical to TLSPlaintext.legacy_record_version and is always { 3, 1 }.  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.fragment, which is the sum of the lengths of the content and the padding,


These messages use a handshake content type and are encrypted under the application traffic key.  4.4.1. At any time after the server has received the client Finished

No sender could possibly need to send half of a message interleaved with application data in TLS, so forbid this. This cuts down on the state-space a receiver needs to worry about. This also means one cannot force the peer to buffer all but one byte of a giant post-handshake message, and then never complete it for the lifetime of the connection. (Although it does not remove all steady state buffering DoS-type concerns.)

These messages use a handshake content type and are encrypted under the application traffic key. <ins> Handshake messages sent after the handshake MUST NOT be interleaved with other record types.  That is, if a message is split over two or more handshake records, there MUST NOT be any other records between them. </ins> 4.4.1. At any time after the server has received the client Finished


A small allowance for errors in clocks and variations in measurements is advisable.  However, any allowance also increases the opportunity <del> for replay.  In this case, it is better to reject early data than to risk greater exposure to replay attacks. </del>  4.2.7.

Just saying "small allowance" is not very clear, so supply some concrete text with an arbitrarily selected value for discussion. Some (but not much) previous discussion in the vicinity of URL
See also issue
Not sure that tens of seconds is good advice. It's certainly larger than I had imagined for a general purpose server. If we accept that clock drift is in the order of seconds per day, then single-digit seconds is probably OK. You don't need to have a high rate of 0-RTT success toward the end of the ticket validity period (1 week), you only need to ensure that most users get 0-RTT if they come back a short time (measured in hours) after the initial session.
The reference point was the 15 seconds that Ilari had used (but still seemed large to me). It is still unclear to me what metric we actually want to use to bound the replay window (i.e., whether it is guided by clock rate skew, RTT, absolute time, or something else), so this text is mostly just a discussion starter. Is one second too small?
I updated the text some (and rebased); hopefully it is an improvement.
Copying here so they don't get lost. On Mon, Jul 11, 2016 at 12:08:00PM -0700, Eric Rescorla wrote: Did a readthrough, here's a bunch of comments (didn't check the issues list): One should note that it is not clear what sort of continuity properties should be provoded: Certificate valid for hostname The same key as in last time The same certificate as in last time The last choice obviously limits lifetime of derived PSK to the parent certificate. Also, extension matching is quite different between those three (and the last two are rather different from the current rules, tuned for 0-RTT only being used with PSK. Well, I think the DH parameters are gone, but DH public keys are still there, and those AFAIK are padded with zeroes. Should the "ServerHello" be "HelloRetryRequest"? Also, adding cookie extension if that was present in HRR? BTW, with the earlydata context and cross-connection cookies gone, I have figured out how to delta-compress the first clienthello and its rejection against to-be-sent second client hello plus connection parameters server selected into 6 bytes(!) of space (not including return-reachability check or MAC). Isn't this the true ciphersuite used on this connection, "resumption" or not? Otherwise you can get into all sorts of crazy situations that WILL be sources of implementation bugs. The idea that it isn't true ciphersuite brings me bad flashbacks about TLS 1.2 ticket "maybe resume" craziness (except this would be even worse). Hasn't earlydata just moved to EncryptedExtensions? What is written into this field if server selects pure-PSK ciphersuite and then decides to reject the ClientHello? Or connections that use pure-PSK just plain can't be rejected for any reason (including IP address verification in DTLS?) Currently assuming pure-PSK rejections are possible, ciphersuite is needed to tell if the next group field contains anything sane or not... What about cookie? IIRC, it is allowed to be in HRR even without being in CH... Again, rejections with cookie aren't spurious, and the cookie needs to be added. Cookie in HRR might not follow that.... I would say that it is a bad idea for any extension to do anything special with "resumption" without very good reasons. In fact, the only non-connection-control extension that is relevant for PSK I know is servername. Now, ALPN (connection-control by definition!) behaves specially with earlydata for darn good reasons (the ALP is locked). This is made worse by the fact that what consistutes "resumption" is not clearly defined (the ALPN rules are related to earlydata, not choosing PSK !). Also, for interoperability, any legal TLS 1.3 meaning of these algorithms must be extended to apply to TLS 1.2, even for TLS 1.2 ClientHello. Anything else would be pointless trap. This impiles that RSA PSS and EdDSA work in TLS 1.2 and also how those work. Also, even if meaning of the ECDSA codepoints changed, those would not break that rule, since new definition is strict subset of old. Are those supposed to be filtered to be subset of ones client advertised or not? E.g. if client didn't indicate support for x448, can the server still send x448? Doesn't seem to consistent with the other descriptions of this and presharedkey (those are just "MUST NOT select covered ciphersuite if missing"). Of course, in practice, it might be more this (at least that's how I would implement it)... Bit crazy algorithm: If you haven't heard of this server before, pick smallest you support, if you have, pick the one it selected the last time. The temporal ordering in messages is actually selecting different PSK and then rejecting 0-RTT. And the addition also prevents correlating session with its parent, even in case of reuse (this was the reason for switching to addition from XOR). Good luck with that... Also, requirement that the server MUST proceed with the handshake and reject 0-RTT if that validation fails would be good here... This does not talk about if endofearlydata alert is encrypted or not (obviously encrypted one won't work if server rejected 0-RTT, unless server trial-decrypts). Oh, still trial decryption... Got it. I think there was some proposal to dump the Finished. Would simplify implementation. In TLS, there is at least one appdata record with its MAC to be deprotected. That's not true in DTLS. However, even in DTLS, any wrong keys almost certainly cause handshake to immediately blow up as handshake keys won't match up... I don't think variations in clocks are minimal... I wonder what 95% timeskew interval per day is... (Oh, and have fun with leap seconds!) This seems inconsistent. In implementation, I would write explicit disjoint whitelists of extensions for both (and non-whitelisted one is a fatal error). Explicit whitelisting is safe even on client side, since the extensions are bounded by client-supported ones. How are multiple OIDs represented? Multiple EKU OID/value pairs? I think the certificate should be REQUIRED to match (as in, not be inconsistent with it) servername, even if not ACK'd. The exception on not having valid value can not work at all. With certificates, even if the EE cert is signed with unknown algorithm, there is a small chance things will work. In contrast, there is absolutely no chance of success if either endpoint tries ot use this fallback. Does this apply to in-handshake or post-handshake auth? I thought in-handshake auth with PSK is not possible. If it is intended to be possible, that's certainly going to be surprising to implementers, and there are probably going to be multiple implementations that outright choke if one tries to send CertificateRequest in (DHE-)PSK mode Later the document seems to imply that the limit for for content+type+ padding is in fact 16385 bytes. Maybe add requirement that record with sequence number of 2^64-1 MUST be either fatal alert or KeyUpdate. I would expand that 2^24.5 to some rough number ("about 24 million"?). And also "will wrap" -> "would wrap". Because such wrapping can't happen (even if endpoint delays KeyUpdate to RSN 2^64-1). This might cause fun with future key exchange types... I think this needs to be in ServerHello on server-side, given how low- level it is. These darn things use Supplemental Data messages, would need to define where the data goes. And one can't stick it to extension for usermapping and client_authz, because those are sent by the client, not the server. Isn't that "Client/HelloRetryRequest"? I don't think EncryptedExtensions can have Cookie... Should the two registeries shadowed by this closed? Isn't the RFC already published, so the codepoints are stable? This seems really obsolete. The timers have not been 18.2Hz for years, and applications running on operating systems damn better use OS services for random numbers, given that anything else is fraught with peril. Better to just nuke the code entierely for all versions. "Disabled" code has nasty tendency of coming back to life. The extensions field can't be omitted in TLS 1.3. And I would consider TLS 1.2 client implementations that send such messages as quite pathological. Also, ECDSA signing operations do have problems with timing attacks. Also, the lengths need to be correct (not verifying this leads to an attack). Best just to treat first length bytes >0x82 or >0x83 as malformed. There is no way to send legimate message with first length byte >0x83 in TLS. I think properties of the exporter should be covered as well: Is it intended to generate secret data (yes) Is it intended to generate connection-unique data (yes) Are values for different labels/contexts intended to be computationally independent (yes) (The TLS 1.2 exporter without EMS failed the middle requirement, creating security issues in applications that assumed the data was connection-unique. -Ilari Dave Garrett 10:52 PM (6 hours ago) to tls, Ilari, me Just replying to a few points. On Tuesday, July 12, 2016 12:16:24 am Ilari Liusvaara wrote: The HelloRetryRequest message is not applicable to pure-PSK, which does not use the KeyShare extension at all. PSK has its own separate extension. ((EC)DHE-PSK uses both together) The purpose of HelloRetryRequest is to allow for clients to not send full keys for every single algorithm they support, yet allow the server to still pick from that entire list if it needs to. PSK has no equivalent system; pre-shared keys are first-flight or bust. If an (EC)DHE-PSK suite is selected, and a valid PSK identity is selected, the server can use HelloRetryRequest to reject a group in favor of another supported by the client, but it can't reject the suite or identity in this manner. The response to no acceptable PSK identity is either to negotiate another suite or to abort with a fatal alert. See draft 14 section 4.2.5: URL xiaoyinl fixed the second one of those notes, but that was merged after the checkpoint for draft 14. I'll fix this one to just note for ECDHE PSK AES. Emphatically agreed, however I worded it this way to be slightly more general. If I said that all that code should be universally gutted, I'd risk more people ignoring it due to the severe status quo bias that is very common. In lieu of modernizing fully and dropping it completely, having these old features disabled via the same compile-time option that enables building of TLS 1.3 would be acceptable, IMO (though, more trouble than it should be worth, and still not ideal at all). Bikeshedding better wordings in this section would not be unwelcome, if you think anything here can be made better. Implementations should be expected to handle pathological cases gracefully, even if only to recognize and reject. ;) Ilari Liusvaara 2:00 AM (3 hours ago) to Dave, tls, me On Tue, Jul 12, 2016 at 01:52:57AM -0400, Dave Garrett wrote: Yes, rejection because of group mismatch can't occur. However, I don't see any requirement not to reject pure-PSK for cookie check (might be feasible, if the computational and network load is determined "small enough"). IIRC, there was merged patch that changed the reference, but not the text. Just checked, seems to still be there in Editor's Copy.
NAME I think I have dealt with most of these. You should raise the topic of the CertificateRequest.extensions on list. You say "Later the document seems to imply that the limit for for content+type+ padding is in fact 16385 bytes." If you point out where I will fix it. I don't think maxfragmentlength should go in ServerHello because the client doesn't need it to interpret messages from the server. If you want to provide a PR about RSA in S 8.5 that would be useful.
On Sat, Sep 03, 2016 at 12:49:39PM -0700, ekr wrote: Probably just me misreading the 255 byte limit for expansion from protection and the 16384+1+255 formula for the 16384+256 byte limit. Also, what's the protected limit if maxfragmentlength is in effect? 256 bytes above the plaintext limit (so e.g. 768 bytes for 512 byte plaintext limit)? Actually, probably OK to keep it until EE if included at all because the strictest limit one can apply is 512 octets, and the maximum size of ServerHello is (there is protection change afterwards, so one can't combine the mesage): 4 bytes for message header 2 bytes for version 32 bytes for random 2 bytes for protection/prf 2 bytes for extension length 6 bytes for PSK ACK (might be reduced to 4) 8 bytes for KeyShare header + dhf id + share len ? bytes for key share data This is 56 bytes, plus key share data, leaving at least 456 bytes for the key share. Now, the only DHFs that exceed that are FFDH4k, FFDH6k and FFDH8k (and possible PQ exchanges). And any device that is puny enough to want 512-byte fragments is very unlikely to support any of those. The first length byte thing? Actually, that's a special case of doing RSA PKCS v1.5 (CA certs) verification by doing RSA op and then decoding the result, instead of the proper way, which is to do RSA op, encode the expected result and then compare. -Ilari
Closing this as Ilari did a new review. NAME please let me know if there's anything that got missed. On Tue, Jul 12, 2016 at 03:31:21PM -0500, Benjamin Kaduk wrote: If the field is allowed to contain some ciphersuite with wrong key exchange type, it takes sniffing extensions from ServerHello and EncryptedExtensions to figure out what the actual ciphersuite is. And knowing the key exchange type is rather important in not getting hit by SMACK. AFAIK, the ciphersuite with the same protection and PRF, but some PSK or GDHE-PSK key exchange type. There is well-defined function from (kextype,protection,prfhash) into ciphersuite (or that no such ciphersuite exists). What would the client do with unknown groups anyway? Dump a message to log? Well, what client accepts is separate question to its speculative guesses for performance improvement. And for the first, there is supportedgroups. keyshare is not meant to be xmas tree! In one piece of code I wrote, I pulled +-15s maximum (config can have tighter limits) out of thin air... And, actually, since failing 0-RTT time check is just 1-RTT delay (since in proper implementations it is not a fatal error). I thought they had switched to something else, but apparently not... Correct. I should check the computers I have for what the tickrate approximately is (one curious observation: rebooting computer changes the tickrate(!)). I think I estimated 140ms/day drift for one of those (the others can be way worse). However, the rate of change of the rate (2nd derivate of time reported relative to "true time" (one can for all practical purposes ignore SR and GR here)) should be small. IIRC, maximum ticket validity is 7 days (but for some crappier clocks, that can be lots of drift). But likely TCP delays and such can cause bigger errors than slightly- bad clocks. The opposite way: I would have client choke if server sends it extension outside those lists (TLS 1.3 clients are already supposed to choke if server sends them extension they don't know about, this is only extending it to per-messages lists). I think "SHOULD" would be suitable. Oh, and stick that it stays constant for the duration of the connection as well... -Ilari

A small allowance for errors in clocks and variations in measurements is advisable.  However, any allowance also increases the opportunity  <ins> for replay.  In this case, it is better to reject early data and fall back to a full 1-RTT handshake than to risk greater exposure to replay attacks.  In common network topologies for browser clients, small allowances on the order of ten seconds are reasonable.  Clock skew distributions are not symmetric, so the optimal tradeoff may involve an asymmetric replay window. </ins> 4.2.7.


not correspond to a group which was provided in the "key_share" extension in the original ClientHello.  If either of these checks fails, then the client MUST abort the handshake with a fatal <del> "handshake_failure" alert.  Clients SHOULD also abort with "handshake_failure" in response to any second HelloRetryRequest which was sent in the same connection (i.e., where the ClientHello was itself in response to a HelloRetryRequest). </del>  Otherwise, the client MUST send a ClientHello with an updated KeyShare extension to the server.  The client MUST append a new ServerHello/KeyShare, the client MUST verify that the selected CipherSuite and NamedGroup match that supplied in the HelloRetryRequest.  If either of these values differ, the client MUST <del> abort the connection with a fatal "handshake_failure" alert. </del>  4.2. Separate specifications may define matching rules for other certificate extensions. <del> Note: It is a fatal "handshake_failure" alert for an anonymous server to request client authentication. </del>  4.3.

Noticed these while reviewing the negotiation PR: handshakefailure means "the sender was unable to negotiate an acceptable set of security parameters given the options available", but these are all protocol errors that should only occur with a buggy server. Switch them to more appropriate ones: If the HelloRetryRequest makes no sense, it is an illegalparameter. If we get a second HelloRetryRequest, it's an unexpectedmessage (the client is in a state where it expects a ServerHello and will likely just fall through to the generic message-mismatch codepath). If HelloRetryRequest and ServerHello are inconsistent, it is an illegalparameter. If an anonymous server sends a CertificateRequest, it's an unexpected_message (this too will likely use the generic message-mismatch codepath).

not correspond to a group which was provided in the "key_share" extension in the original ClientHello.  If either of these checks fails, then the client MUST abort the handshake with a fatal  <ins> "illegal_parameter" alert.  Clients SHOULD also abort with "unexpected_message" in response to any second HelloRetryRequest which was sent in the same connection (i.e., where the ClientHello was itself in response to a HelloRetryRequest). </ins> Otherwise, the client MUST send a ClientHello with an updated KeyShare extension to the server.  The client MUST append a new ServerHello/KeyShare, the client MUST verify that the selected CipherSuite and NamedGroup match that supplied in the HelloRetryRequest.  If either of these values differ, the client MUST  <ins> abort the connection with a fatal "illegal_parameter" alert. </ins> 4.2. Separate specifications may define matching rules for other certificate extensions.  <ins> Note: It is a fatal "unexpected_message" alert for an anonymous server to request client authentication. </ins> 4.3.


Note: In versions of TLS prior to TLS 1.3, this extension was named "elliptic_curves" and only contained elliptic curve groups.  See <del> RFC4492 and I-D.ietf-tls-negotiated-ff-dhe.  This extension was also used to negotiate ECDSA curves.  Signature algorithms are now negotiated independently (see signature-algorithms). </del>  The "extension_data" field of this extension contains a "NamedGroupList" value: 0xFEFF are reserved for private use. Indicates support of the corresponding finite field group, defined <del> in I-D.ietf-tls-negotiated-ff-dhe.  Values 0x01FC through 0x01FF are reserved for private use. </del>  Items in named_group_list are ordered according to the client's preferences (most preferred choice first).

draft-ietf-tls-negotiated-ff-dhe is now RFC 7919. draft-mattsson-tls-ecdhe-psk-aead is now draft-ietf-tls-ecdhe-psk-aead.
Do we even need a reference to draft-ietf-tls-ecdhe-psk-aead with the new negotiation syntax?
NAME I removed it from the reference section. It was used in previous versions. But it is no longer referenced to by any text in the spec since version 15.

Note: In versions of TLS prior to TLS 1.3, this extension was named "elliptic_curves" and only contained elliptic curve groups.  See  <ins> RFC4492 and RFC7919.  This extension was also used to negotiate ECDSA curves.  Signature algorithms are now negotiated independently (see signature-algorithms). </ins> The "extension_data" field of this extension contains a "NamedGroupList" value: 0xFEFF are reserved for private use. Indicates support of the corresponding finite field group, defined  <ins> in RFC7919.  Values 0x01FC through 0x01FF are reserved for private use. </ins> Items in named_group_list are ordered according to the client's preferences (most preferred choice first).


Including a new KeyShareEntry as the lowest priority share (i.e., appended to the list of shares in the "key_share" extension). <del> Removing the EarlyDataIndication early-data-indication extension if one was present.  Early data is not permitted after HelloRetryRequest. </del>  If a server receives a ClientHello at any other time, it MUST send a fatal "unexpected_message" alert and close the connection. the early data.  It is not possible for the server to accept only a subset of the early data messages.  In order to accept early data, the server server MUST have accepted a PSK cipher suite and selected the the first key offered in the client's "pre_shared_key" extension.  In addition, it MUST verify

ClientHello mentions that earlydata should be removed, but earlydata doesn't mention it. Editorial.

Including a new KeyShareEntry as the lowest priority share (i.e., appended to the list of shares in the "key_share" extension).  <ins> Removing the "early_data" extension (early-data-indication) if one was present.  Early data is not permitted after HelloRetryRequest. </ins> If a server receives a ClientHello at any other time, it MUST send a fatal "unexpected_message" alert and close the connection. the early data.  It is not possible for the server to accept only a subset of the early data messages. <ins> Request that the client send another ClientHello by responding with a HelloRetryRequest.  A client MUST NOT include the "early_data" extension in its followup ClientHello. </ins> In order to accept early data, the server server MUST have accepted a PSK cipher suite and selected the the first key offered in the client's "pre_shared_key" extension.  In addition, it MUST verify


The primary goal of TLS is to provide a secure channel between two communicating peers.  Specifically, the channel should provide the <del> following properties. </del>  Authentication: The server side of the channel is always authenticated; the client side is optionally authenticated. TLS consists of two primary components: <del> A handshake protocol (handshake-protocol) which authenticates the </del>  communicating parties, negotiates cryptographic modes and parameters, and establishes shared keying material.  The handshake protocol is designed to resist tampering; an active attacker parameters than they would if the connection were not under attack. <del> A record protocol (record-protocol) which uses the parameters </del>  established by the handshake protocol to protect traffic between the communicating peers.  The record protocol divides traffic up into a series of records, each of which is independently protected TLS is application protocol independent; higher-level protocols can layer on top of TLS transparently.  The TLS standard, however, does <del> not specify how protocols add security with TLS; the decisions on how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left to the judgment of the designers and implementors of protocols that run on top of TLS. </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

Some suggested nits for s1: adding a semi-colon and swapping two whichs for thats.

The primary goal of TLS is to provide a secure channel between two communicating peers.  Specifically, the channel should provide the  <ins> following properties: </ins> Authentication: The server side of the channel is always authenticated; the client side is optionally authenticated. TLS consists of two primary components:  <ins> A handshake protocol (handshake-protocol) that authenticates the </ins> communicating parties, negotiates cryptographic modes and parameters, and establishes shared keying material.  The handshake protocol is designed to resist tampering; an active attacker parameters than they would if the connection were not under attack.  <ins> A record protocol (record-protocol) that uses the parameters </ins> established by the handshake protocol to protect traffic between the communicating peers.  The record protocol divides traffic up into a series of records, each of which is independently protected TLS is application protocol independent; higher-level protocols can layer on top of TLS transparently.  The TLS standard, however, does  <ins> not specify how protocols add security with TLS; how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left to the judgment of the designers and implementors of protocols that run on top of TLS. </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


client) and provide key confirmation and handshake integrity. In the Key Exchange phase, the client sends the ClientHello (client- <del> hello) message, which contains a random nonce (ClientHello.random), its offered protocol version, a list of symmetric cipher/HKDF hash pairs, some set of Diffie-Hellman key shares (in the "key_share" </del>  extension key-share), one or more pre-shared key labels (in the <del> "pre_shared_key" extension pre-shared-key-extension), or both, and </del>  potentially some other extensions. The server processes the ClientHello and determines the appropriate

At least to me, the KE phase description currently reads like the DH share and PSK are always sent. It's DH, PSK, or both.

client) and provide key confirmation and handshake integrity. In the Key Exchange phase, the client sends the ClientHello (client-  <ins> hello) message, which contains a random nonce (ClientHello.random); its offered protocol version; a list of symmetric cipher/HKDF hash pairs; some set of Diffie-Hellman key shares (in the "key_share" </ins> extension key-share), one or more pre-shared key labels (in the  <ins> "pre_shared_key" extension pre-shared-key-extension), or both; and </ins> potentially some other extensions. The server processes the ClientHello and determines the appropriate


being in the order of the client's preference, with most preferred first. <del> PskKeyExchangeModes have the following meanings: </del>  PSK-only key establishment.  In this mode, the server MUST not supply a "key_share" value. mode, the client and servers MUST supply "key_share" values as described in key-share. <del> PskAuthenticationModes have the following meanings: </del>  PSK-only authentication.  In this mode, the server MUST NOT supply either a Certificate or CertificateVerify message.  [TODO: Add a

The PskKeMode and PskAuthMode types were not defined, substitute them by the defined enums. Use non-plural enum names for consistency with other enumeration types. Remove the old opaque psk_identity type in favor of PskIdentity which was otherwise unused. Increase minimum length from 2 to 4 to account for the PskIdentity.identity field length.

being in the order of the client's preference, with most preferred first.  <ins> PskKeyExchangeMode values have the following meanings: </ins> PSK-only key establishment.  In this mode, the server MUST not supply a "key_share" value. mode, the client and servers MUST supply "key_share" values as described in key-share.  <ins> PskAuthenticationMode values have the following meanings: </ins> PSK-only authentication.  In this mode, the server MUST NOT supply either a Certificate or CertificateVerify message.  [TODO: Add a


4.1.1. TLS cryptographic negotiation proceeds by the client offering the <del> following four sets of options in its ClientHello. </del>  A list of cipher suites which indicates the AEAD cipher/HKDF hash <del> pairs which the client supports </del>  A "supported_group" (negotiated-groups) extension which indicates the (EC)DHE groups which the client supports and a "key_share" (key-share) extension which contains (EC)DHE shares for some or <del> all of these groups </del>  A "signature_algorithms" (signature-algorithms) extension which indicates the signature algorithms which the client can accept. options are entirely orthogonal: the server independently selects a cipher suite, an (EC)DHE group and key share for key establishment, and a signature algorithm/certificate pair to authenticate itself to <del> the client.  If any of these parameters has no overlap between the client and server parameters, then the handshake will fail.  If there is overlap in the "supported_group" extension but the client did not offer a compatible "key_share" extension, then the server will respond with a HelloRetryRequest (hello-retry-request) message. </del>  If the server selects a PSK, then the PSK will indicate which key establishment modes it can be used with (PSK alone or with (EC)DHE) in either of these parameters need not be fatal. The server indicates its selected parameters in the ServerHello as <del> follows: If PSK is being used then the server will send a "pre_shared_key" extension indicating the selected key.  If PSK is not being used, then (EC)DHE and certificate-based authentication are always used.  When (EC)DHE is in use, the server will also provide a "key_share" extension.  When authenticating via a certificate, the server will send an empty "signature_algorithnms" extension in the ServerHello and will subsequently send Certificate (certificate) and CertificateVerify (certificate-verify) messages. If the server is unable to negotiate a supported set of parameters, </del>  it MUST return a "handshake_failure" alert and close the connection. 4.1.2.

I took this bit out of the 1st paragraph: -If any of these parameters has no overlap between the -client and server parameters, then the handshake -will fail. and moved it to the last para in the section because it doesn't say what alert value is to be returned, there's not something similar in the following paragraph that describes the PSK failure case, and finally the full failure text is included in the final paragraph. Basically, I just move the failure case to the final paragraph. An alternate would be to copy the failure to the PSK paragraph and include the which alert to return in the non-PSK para.

4.1.1. TLS cryptographic negotiation proceeds by the client offering the  <ins> following four sets of options in its ClientHello: </ins> A list of cipher suites which indicates the AEAD cipher/HKDF hash  <ins> pairs which the client supports. </ins> A "supported_group" (negotiated-groups) extension which indicates the (EC)DHE groups which the client supports and a "key_share" (key-share) extension which contains (EC)DHE shares for some or  <ins> all of these groups. </ins> A "signature_algorithms" (signature-algorithms) extension which indicates the signature algorithms which the client can accept. options are entirely orthogonal: the server independently selects a cipher suite, an (EC)DHE group and key share for key establishment, and a signature algorithm/certificate pair to authenticate itself to  <ins> the client.  If there is overlap in the "supported_group" extension but the client did not offer a compatible "key_share" extension, then the server will respond with a HelloRetryRequest (hello-retry- request) message. </ins> If the server selects a PSK, then the PSK will indicate which key establishment modes it can be used with (PSK alone or with (EC)DHE) in either of these parameters need not be fatal. The server indicates its selected parameters in the ServerHello as  <ins> follows: If PSK is being used then the server will send a "pre_shared_key" extension indicating the selected key. If PSK is not being used, then (EC)DHE and certificate-based authentication are always used. When (EC)DHE is in use, the server will also provide a "key_share" extension. When authenticating via a certificate, the server will send an empty "signature_algorithnms" extension in the ServerHello and will subsequently send Certificate (certificate) and CertificateVerify (certificate-verify) messages. If the server is unable to negotiate a supported set of parameters (i.e., there is no overlap between the client and server parameters), </ins> it MUST return a "handshake_failure" alert and close the connection. 4.1.2.


It has been replaced by SignatureScheme which assumes that no more HashAlgorithms will ever be allocated. Future allocations will go in SignatureScheme. Closes issue .
(Well, I think, strictly speaking, we need only lock down HashAlgorithm.) The SignatureScheme change assumes that we will never again allocate new values in the TLS 1.2 HashAlgorithm and SignatureAlgorithm ranges. I'm not sure how to write that kind of IANA consideration or I'd put together a PR. The end result should probably be something like s/Unassigned/Reserved for TLS 1.3 compatibility/. From TLS 1.3 onwards, all new signature algorithms that apply to TLS 1.2 must go through a backported SignatureScheme. (If we're not happy with that strong of a restriction, we could perhaps only burn HashAlgorithms 0x80 and up. Then TLS 1.3 SignatureSchemes live in the 0x8000 to 0xfdff range. Though 's PSS text already implies we'll be backporting SignatureSchemes, so the division probably isn't necessary? I dunno. I don't really care either way.)
Let's just lock down HAshAlgorithm. Can you submit a PR?

values SHALL be marked as "Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, rsa_pss_sha256, rsa_pss_sha384, rsa_pss_sha512, ed25519. <ins> Finally, this document obsoletes a registry originally created in RFC5246.  IANA [shall/has] updated it to list values 7-223 as "Reserved". </ins>


network byte (big-endian) order; the uint32 represented by the hex bytes 01 02 03 04 is equivalent to the decimal value 16909060. <del> Note that in some cases (e.g., DH parameters) it is necessary to represent integers as opaque vectors.  In such cases, they are represented as unsigned integers (i.e., additional leading zero octets are not used even if the most significant bit is set). </del> 3.5. An additional sparse data type is available called enum.  A field of

It looks like this is carried over from TLS 1.2---seems I was wrong and TLS 1.2 did actually say whether there were leading zeros in front of DHE parameters---but I believe it is no longer used. Instead our crypto primitives all act on byte strings. Any conversion between byte strings and the primitive's internal structures is handled by the primitive itself. (RFC 7748 natively acts on byte strings, specifies how FFDHE is encoded, RSA-PSS comes with a byte string form, etc.)

network byte (big-endian) order; the uint32 represented by the hex bytes 01 02 03 04 is equivalent to the decimal value 16909060.  3.5. An additional sparse data type is available called enum.  A field of


If a server receives a ClientHello at any other time, it MUST send a fatal "unexpected_message" alert and close the connection.  Structure of this message: %%% Key Exchange Messages

the renegotiation mechanism from TLSv1.2 and earlier is deprecated, that deprecation extends to the ability to renegotiate existing TLSv1.2 (or earlier) session to TLSv1.3
Sorry, but I just realized you can't do this. You need to prohibit negotiating back up to 1.3, but the client has to be able to offer 1.3. Here's the Bugzilla thread on this URL
so the client MAY send a TLSv1.3 Client Hello in a TLSv1.2 session, but server MUST NOT negotiate TLSv1.3 then?
How about this?
OpenSSL derived implementations don't even allow you to switch versions on renego at all because that would be insane. We do send the higher ClientHello version for the reasons EKR pointed out, but the ServerHello version must match. I would actually argue that it is fair game to assume version-related things are implicitly forked and locked (a 1.1 session implicitly cannot be resumed at 1.2, etc.), but the spec should be much clearer on this, so saying it explicitly now is a good idea.
Yes. , Hubert Kario EMAIL wrote:
I agree, resuming sessions must be at the same version and text saying so is a good idea.
NAME This is actually about negotiating at TLS 1.2 and then renegotiating to TLS 1.3. It's not clear how you would even manage to resume a TLS 1.2 session at TLS 1.3 or vice versa, but explicit text to this effect would be good. It has certainly historically been a mess.
OK, that should fix all the comments.
Merged. NAME please send me a PR adding yourself to Contributors
NAME here it is:

If a server receives a ClientHello at any other time, it MUST send a fatal "unexpected_message" alert and close the connection. <ins> If a server established a TLS session at a previous version of the protocol and receives a TLS 1.3 ClientHello in a renegotiation, it MUST retain the previous protocol version.  In particular, it MUST NOT negotiate TLS 1.3.  A client that receives a TLS 1.3 ServerHello in an established session MUST send a fatal "protocol_version" alert and close the connection. </ins> Structure of this message: %%% Key Exchange Messages


the cryptographic context. The same extension types MUST NOT appear in both the ServerHello and <del> EncryptedExtensions.  If the same extension appears in both locations, the client MUST rely only on the value in the EncryptedExtensions block.  All server-sent extensions other than those explicitly listed in server-hello or designated in the IANA registry MUST only appear in EncryptedExtensions.  Extensions which are designated to appear in ServerHello MUST NOT appear in </del>  EncryptedExtensions.  Clients MUST check EncryptedExtensions for the presence of any forbidden extensions and if any are found MUST terminate the handshake with an "illegal_parameter" alert.

since server hello says that presence of extra extensions is a illegalparameter and encrypted extensions say that presence of server hello specific extensions is illegalparameter there is no reason to specify what to do with situation that MUST generate fatal alert

the cryptographic context. The same extension types MUST NOT appear in both the ServerHello and  <ins> EncryptedExtensions.  All server-sent extensions other than those explicitly listed in server-hello or designated in the IANA registry MUST only appear in EncryptedExtensions.  Extensions which are designated to appear in ServerHello MUST NOT appear in </ins> EncryptedExtensions.  Clients MUST check EncryptedExtensions for the presence of any forbidden extensions and if any are found MUST terminate the handshake with an "illegal_parameter" alert.


The selected ALPN RFC7443 value, if any. <del> The server_name RFC6066 value provided by the client, if any. </del> Future extensions MUST define their interaction with 0-RTT. If any of these checks fail, the server MUST NOT respond with the

This seems to have just been a mistake? Unlike ALPN, servername isn't a value that is selected by the server, so there's no need to match it against a value stored in the session. There is the issue of whether sessions are resumable across names or other application-level contexts (for instance, whether we send client certificates, different cipher profiles, etc.), but that is a more complex issue than simply matching on servername on the server side. Moreover, any rules there would want to apply to resumption as a whole. It seems there's no reason to have 0-RTT-specific rules over resumption ones here.

The selected ALPN RFC7443 value, if any.  Future extensions MUST define their interaction with 0-RTT. If any of these checks fail, the server MUST NOT respond with the


outputs of the corresponding functions defined in RFC7748, 32 bytes for x25519 and 56 bytes for x448. <del> Note: Versions of TLS prior to 1.3 permitted point negotiation; TLS 1.3 removes this feature in favor of a single point format for each curve. </del>  4.2.5.

TLS still permits shared point negotiation via ECDH, TLS 1.3 removes point format negotiation.

outputs of the corresponding functions defined in RFC7748, 32 bytes for x25519 and 56 bytes for x448.  <ins> Note: Versions of TLS prior to 1.3 permitted point format negotiation; TLS 1.3 removes this feature in favor of a single point format for each curve. </ins> 4.2.5.


IANA [SHALL add/has added] the cipher suites listed in cipher- suites to the registry.  The "Value" and "Description" columns are <del> taken from the table.  The "DTLS-OK" column is marked as "Yes". IANA [SHALL add/has added] a "Recommended" column to the cipher suite registry.  All cipher suites listed in cipher-suites are marked as "Yes".  All other cipher suites are marked as "No". IANA [SHALL add/has added] add a note to this column reading: Cipher suites marked as "Yes" are those allocated via Standards Track RFCs.  Cipher suites marked as "No" are not; cipher suites marked "No" range from "good" to "bad" from a cryptographic standpoint. </del>  TLS ContentType Registry: Future values are allocated via Standards Action RFC2434.

We are inconsistent about "AEAD cipher" and "AEAD algorithm". RFC 5116 uses "AEAD algorithm" and "AEAD cipher" is confusing with "cipher suite", so standardize on algorithm. IANA considerations were never updated to actually add the cipher suites. Fix that. Match the cipher suite name column with the IANA name so we can reuse the table. Finally, since we are defining new cipher suites, we should take care to cite where our AEADs come from. Do so.

IANA [SHALL add/has added] the cipher suites listed in cipher- suites to the registry.  The "Value" and "Description" columns are  <ins> taken from the table.  The "DTLS-OK" and "Recommended" columns are both marked as "Yes" for each new cipher suite.  [[This assumes draft-sandj-tls-iana-registry-updates-00 has been applied.]] </ins> TLS ContentType Registry: Future values are allocated via Standards Action RFC2434.


Sent by servers when a client certificate is desired but none was provided by the client.  New Alert values are assigned by IANA as described in iana- considerations.

There is no alert for a server which requested a client certificate, required it, but was not sent one. Servers today send a generic handshakefailure which means clients must use heuristics to show error messages to the user. Unlike nearly every other negotiation in TLS, client certificate selection is actually sometimes a user-level decision, so it is arguably the most important place for us to have a dedicated alert. (Also remove a "This alert is always fatal" note on badcertificatestatusresponse. All alerts are now fatal, so this is redundant.)
+1

Sent by servers when a client certificate is desired but none was provided by the client. <ins> [[TODO: IANA Considerations for new alert values.]] </ins> New Alert values are assigned by IANA as described in iana- considerations.


TLS SignatureScheme Registry: Values with the first byte in the range 0-254 (decimal) are assigned via Specification Required RFC2434.  Values with the first byte 255 (decimal) are reserved <del> for Private Use RFC2434.  This registry SHALL have a "Recommended" column.  The registry [shall be/ has been] initially populated with the values described in signature-algorithms.  The following values SHALL be marked as "Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, rsa_pss_sha256, rsa_pss_sha384, rsa_pss_sha512, ed25519. [[TODO: How to denote that values ending in 0x00 through 0x03 are also reserved?]] </del>  Finally, this document obsoletes the TLS HashAlgorithm Registry and the TLS SignatureAlgorithm Registry, both originally created in

Avoid both starting with an existing hash AND ending with an existing SignatureAlgorithm. In principle, this should not be necessary, but TLS says: Bouncy Castle appears to have been enforcing this, causing interop issues. As this was a straight-up MUST NOT, it seems prudent to renumber. And if we're renumbering anyway, may as well avoid all the old SignatureAlgorithms and avoid confusing tools like Wireshark.

TLS SignatureScheme Registry: Values with the first byte in the range 0-254 (decimal) are assigned via Specification Required RFC2434.  Values with the first byte 255 (decimal) are reserved  <ins> for Private Use RFC2434.  Values with the first byte in the range 0-6 or with the second byte in the range 0-3 that are not currently allocated are reserved for backwards compatibility. This registry SHALL have a "Recommended" column.  The registry [shall be/ has been] initially populated with the values described in signature-algorithms.  The following values SHALL be marked as "Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, rsa_pss_sha256, rsa_pss_sha384, rsa_pss_sha512, ed25519. </ins> Finally, this document obsoletes the TLS HashAlgorithm Registry and the TLS SignatureAlgorithm Registry, both originally created in


A list of offered KeyShareEntry values in descending order of client preference.  This vector MAY be empty if the client is <del> requesting a HelloRetryRequest.  The ordering of values here SHOULD match that of the ordering of offered support in the "supported_groups" extension. </del>  The mutually supported group the server intends to negotiate and is requesting a retried ClientHello/KeyShare for.

The text already says that both supportedgroups and keyshares are in order of "client preference". Supposing "client preference" is a well-defined notion, we are already requiring the order match. The SHOULD was also unclear on whether the list may be a general subsequence. Clarify that this is allowed. This may be useful if, say, we define some very large NamedGroup (post-quantum?) in the future that is still preferable over the existing options. Clients would likely wish to NOT offer it initially because it would be a waste of bandwidth for the vast majority of servers which don't support it. (Not to mention intolerance problems.) In that scenario, a client would likely not predict a keyshare by default and instead use some kind of server info cache (either caching what the server chose or using the full server supportedgroups list). But that client would still wish to advertise the new group first.
This is what I get for uploading PR immediately before trying to enforce it instead of immediately afterwards... :-) On the plus side, yay for tests! The list in the extension is supposed to be "in descending order of client preference". However, this isn't true for the second ClientHello because the new KeyShareEntry is always appended. It's only a SHOULD-level requirement with reverted, but the spec text is still off, and it is a little bit odd for stateless HRR implementations. (Though if the stateless implementation remembers in the cookie that it already committed to a group, it's probably still fine?)
Just put an "except for the last , in the case where an additional is requested with a HelloRetryRequest" or something on the sentence.
Sounds reasonable. Another option is we say isn't ordered at all. I dunno, maybe you have to keep them sorted or something. There already is a ordering. We're pretty ambiguous right now about whether is a secondary preference list or merely a prediction set. (I think it's best to make it a prediction set and avoid the complex semantics.)
Although keeping them sorted would be a huge pain, even if it is easier to enforce. That's probably not a good idea.
Well, if we wanted the HRR case to jive nicely with sorting, we could mandate reverse priority order; the appended would be top priority. This would work nicely, but could be considered unnecessary if sorting is any burden. I don't remember if this was specifically why I put a SHOULD here, but mandating an absolute requirement here could just be more trouble than it's worth. The worry with not having any requirement is that a pair of bad implementations could use the keyshare priority instead of supportedgroups and mess things up, however I'm not so sure it's that big of a risk. I think a SHOULD with NAME exception is fine.
NAME proposal on-list to replace the key_share after an HRR, rather than append to it, would fix this rather easily. Much better than fiddling with the language or ordering.

A list of offered KeyShareEntry values in descending order of client preference.  This vector MAY be empty if the client is  <ins> 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. </ins> The mutually supported group the server intends to negotiate and is requesting a retried ClientHello/KeyShare for.


server's selected version is contained in the ServerHello.version field as in previous versions of TLS.  4.2.2. %%% Cookie Extension

By the way, you also need to update Version Negotiation section of the .
lgtm
Done , Xiaoyin Liu EMAIL wrote:

server's selected version is contained in the ServerHello.version field as in previous versions of TLS. <ins> 4.2.1.1. RFC EDITOR: PLEASE REMOVE THIS SECTION While the eventual version indicator for the RFC version of TLS 1.3 will be {3, 4}, implementations of draft versions of this specification SHOULD instead advertise {0x7f, [draft-version]} in their "supported_versions" extension, in ServerHello.version, and HelloRetryRequest.server_version.  This allows pre-RFC implementations to safely negotiate with each other, even if they would otherwise be incompatible. </ins> 4.2.2. %%% Cookie Extension


preferences and MUST only select a version of TLS present in that extension.  They MUST ignore any unknown versions.  If the extension is not present, they MUST negotiate TLS 1.2 or prior as specified in <del> RFC5246, even if ClientHello.version is {3, 4} or later. </del>  The server MUST NOT send the "supported_versions" extension.  The server's selected version is contained in the ServerHello.version

ClientHello.version -> ClientHello.legacy_version
Merged. Please send me a PR adding yourself to Contributors in alphabetical order
NAME Thank you! Done in PR .

preferences and MUST only select a version of TLS present in that extension.  They MUST ignore any unknown versions.  If the extension is not present, they MUST negotiate TLS 1.2 or prior as specified in  <ins> RFC5246, even if ClientHello.legacy_version is {3, 4} or later. </ins> The server MUST NOT send the "supported_versions" extension.  The server's selected version is contained in the ServerHello.version


When a client first connects to a server, it is REQUIRED to send the ClientHello as its first message.  The client will also send a ClientHello when the server has responded to its ClientHello with <del> a HelloRetryRequest that selects cryptographic parameters that don't match the client's "key_share" extension.  In that case, the client MUST send the same ClientHello (without modification) except: </del>  Including a new KeyShareEntry as the lowest priority share (i.e., appended to the list of shares in the "key_share" extension).

In the first paragraph, remove "that selects cryptographic parameters that don’t match the client’s 'keyshare' extension". Reason: According to section 4.2.5, HelloRetryRequest might not include the “keyshare” extension. Also there is a whole section for Hello Retry Request. So I don't think we need to explain what a HelloRetryRequest is here.

When a client first connects to a server, it is REQUIRED to send the ClientHello as its first message.  The client will also send a ClientHello when the server has responded to its ClientHello with  <ins> a HelloRetryRequest.  In that case, the client MUST send the same ClientHello (without modification) except: </ins> Including a new KeyShareEntry as the lowest priority share (i.e., appended to the list of shares in the "key_share" extension).


(*) indicates changes to the wire protocol which may require implementations to update.  draft-15 New negotiation syntax as discussed in Berlin (*)

PR changed enum values which would need updating by any experimental implementations that were actually using them. Even if this doesn't come up in practice, it should be listed in the changelog.

(*) indicates changes to the wire protocol which may require implementations to update. <ins> draft-16 Change RSASSA-PSS and EdDSA SignatureScheme codepoints for better backwards compatibility (*) </ins> draft-15 New negotiation syntax as discussed in Berlin (*)


skew distributions are not symmetric, so the optimal tradeoff may involve an asymmetric replay window. <del> 4.2.8. RFC6066 and RFC6961 provide extensions to negotiate the server sending OCSP responses to the client.  In TLS 1.2 and below, the server sends an empty extension to indicate negotiation of this extension and the OCSP information is carried in a CertificateStatus message.  In TLS 1.3, the server's OCSP information is carried in an extension in EncryptedExtensions.  Specifically: The body of the "status_request" or "status_request_v2" extension from the server MUST be a CertificateStatus structure as defined in RFC6066 and RFC6961 respectively. Note: This means that the certificate status appears prior to the certificates it applies to.  This is slightly anomalous but matches the existing behavior for SignedCertificateTimestamps RFC6962, and is more easily extensible in the handshake state machine. </del> 4.3. The next two messages from the server, EncryptedExtensions and of certificate_request_context in that message.  Otherwise, in the case of server authentication this field SHALL be zero length. <del> This is a sequence (chain) of certificates.  The sender's certificate MUST come first 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 some 4.4.1.1.  The following rules apply to the certificates sent by the server: The certificate type MUST be X.509v3 RFC5280, unless explicitly on the above-mentioned criteria (in addition to other criteria, such as transport layer endpoint, local configuration and preferences). <del> 4.4.1.2. </del>  The following rules apply to certificates sent by the client: that use algorithm combinations that cannot be currently used with TLS. <del> 4.4.1.3. </del>  In general, detailed certificate validation procedures are out of scope for TLS (see RFC5280).  This section provides TLS-specific Sent by endpoints receiving any hello message containing an extension known to be prohibited for inclusion in the given hello <del> message, including any extensions in a ServerHello not first offered in the corresponding ClientHello. </del>  Sent by servers when unable to obtain a certificate from a URL provided by the client via the "client_certificate_url" extension 1.3" column with the following four values: "Client", indicating that the server shall not send them.  "Clear", indicating that they shall be in the ServerHello.  "Encrypted", indicating that <del> they shall be in the EncryptedExtensions block, and "No" </del>  indicating that they are not used in TLS 1.3.  This column [shall be/has been] initially populated with the values in this document.

This change adds a set of extensions to the Certificate message. This is intended to hold all extension messages that are certificate-specific as opposed to extensions that apply to the entire connection. This change facilitates future extensions to the protocol for post-handshake server authentication and resolves the anomaly of OCSP messages appearing before certificates in the handshake.
Changed SingleCertificate to CertificateEntry
NAME this seems ready to land from my side modulo the rename I propose. Do you have any changes to make?

skew distributions are not symmetric, so the optimal tradeoff may involve an asymmetric replay window.  4.3. The next two messages from the server, EncryptedExtensions and of certificate_request_context in that message.  Otherwise, in the case of server authentication this field SHALL be zero length.  <ins> This is a sequence (chain) of CertificateEntry structures, each containing a single certificate and set of extensions.  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. A set of extension values for the CertificateEntry.  The "Extension" format is defined in hello-extensions.  Valid extensions include OCSP Status extensions (RFC6066 and RFC6961) and SignedCertificateTimestamps (RFC6962).  Any extension presented in a Certificate message must only be presented if the corresponding ClientHello extension was presented in the initial handshake.  If an extension applies the the entire chain, it SHOULD be included in the first CertificateEntry. </ins> Note: Prior to TLS 1.3, "certificate_list" ordering required each certificate to certify the one immediately preceding it, however some 4.4.1.1. <ins> RFC6066 and RFC6961 provide extensions to negotiate the server sending OCSP responses to the client.  In TLS 1.2 and below, the server sends an empty extension to indicate negotiation of this extension and the OCSP information is carried in a CertificateStatus message.  In TLS 1.3, the server's OCSP information is carried in an extension in the CertificateEntry containing the assoiciated certificate.  Specifically: The body of the "status_request" or "status_request_v2" extension from the server MUST be a CertificateStatus structure as defined in RFC6066 and RFC6961 respectively. Similarly, RFC6962 provides a mechanism for a server to send a Signed Certificate Timestamp (SCT) as an extension in the ServerHello.  In TLS 1.3, the server's SCT information is carried in an extension in CertificateEntry. 4.4.1.2. </ins> The following rules apply to the certificates sent by the server: The certificate type MUST be X.509v3 RFC5280, unless explicitly on the above-mentioned criteria (in addition to other criteria, such as transport layer endpoint, local configuration and preferences).  <ins> 4.4.1.3. </ins> The following rules apply to certificates sent by the client: that use algorithm combinations that cannot be currently used with TLS.  <ins> 4.4.1.4. </ins> In general, detailed certificate validation procedures are out of scope for TLS (see RFC5280).  This section provides TLS-specific Sent by endpoints receiving any hello message containing an extension known to be prohibited for inclusion in the given hello  <ins> message, including any extensions in a ServerHello or Certificate not first offered in the corresponding ClientHello. </ins> Sent by servers when unable to obtain a certificate from a URL provided by the client via the "client_certificate_url" extension 1.3" column with the following four values: "Client", indicating that the server shall not send them.  "Clear", indicating that they shall be in the ServerHello.  "Encrypted", indicating that  <ins> they shall be in the EncryptedExtensions block, "Certificate" indicating that they shall be in the Certificate block, and "No" </ins> indicating that they are not used in TLS 1.3.  This column [shall be/has been] initially populated with the values in this document.


by sending the client an empty "signature_algorithms" extension. The "extension_data" field of this extension in a ClientHello <del> contains a "supported_signature_algorithms" value: </del>  %%% Signature Algorithm Extension rsa_pkcs1_sha1, dsa_sha1, and ecdsa_sha1 SHOULD NOT be offered. Clients offering these values for backwards compatibility MUST list <del> them as the lowest priority (listed after all other algorithms in the supported_signature_algorithms vector).  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

Criteria for one member structure / non structure is as follows: Non structure: basic type -- not messages nor extensions One member structure: others such as messages or extensions
LGTM

by sending the client an empty "signature_algorithms" extension. The "extension_data" field of this extension in a ClientHello  <ins> contains a SignatureSchemeList value: </ins> %%% Signature Algorithm Extension rsa_pkcs1_sha1, dsa_sha1, and ecdsa_sha1 SHOULD NOT be offered. Clients offering these values for backwards compatibility MUST list  <ins> 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


2.3. <del> When resuming via a PSK with an appropriate ticket (i.e., one with the "early_data_info" extension), clients can also send data on their first flight ("early data").  This data is encrypted solely under keys derived using the first offered PSK as the static secret.  As shown in tls-0-rtt, the Zero-RTT data is just added to the 1-RTT </del>  handshake in the first flight.  The rest of the handshake uses the same messages as with a 1-RTT handshake with PSK resumption. 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, because it is encrypted solely with the PSK. </del>  There are no guarantees of non-replay between connections.  Unless the server takes special measures outside those provided by TLS,

I am proposing that a client can also use the Zero-RTT with PSK-based authentication without having to rely on a previously obtained ticket.
Surely there would need to be additional security considerations for this behavior?!
This seems reasonable and was my intent, at least. Can you fix the build problem.
Could you please add linebreaks to wrap to about 80 character or so lines? Our line length is often rather inconsistent, but we do generally try to keep lines shorter than in the current changeset.
This LGTM. I'll let it sit for a little but in case anyone wants to weigh in (NAME NAME NAME
That's the sort of additional considerations that I was expecting to see, yes. I think that you got the list basically right, though there are a few things here that could be clearer.

2.3.  <ins> With the Zero-RTT mode clients can send data on their first flight ("early data") whereby the client uses a PSK either obtained out-of- band or as a ticket (i.e., one with the "early_data_info" extension) from an earlier exchange to authenticate to the server. When clients use a PSK obtained out-of-band then the following information MUST be provisioned to both parties: * PSK identity, * ciphersuite for use with this PSK, * key exchange and authentication modes this PSK is allowed to be used with, * the Application-Layer Protocol Negotiation (ALPN) label(s), and * optionally the Server Name Indication (SNI). As shown in tls-0-rtt, the Zero-RTT data is just added to the 1-RTT </ins> handshake in the first flight.  The rest of the handshake uses the same messages as with a 1-RTT handshake with PSK resumption. IMPORTANT NOTE: The security properties for 0-RTT data are weaker than those for other kinds of TLS data.  Specifically:  <ins> The early data is encrypted solely under keys derived using the offered PSK as the static secret.  Hence, this data is not forward secret, because it is encrypted solely with the PSK. </ins> There are no guarantees of non-replay between connections.  Unless the server takes special measures outside those provided by TLS,


which will be echoed in the client's Certificate message.  The certificate_request_context MUST be unique within the scope of this connection (thus preventing replay of client <del> CertificateVerify messages).  Within the handshake, this field MUST be empty. </del>  A list of the signature algorithms that the server is able to verify, listed in descending order of preference.  Any

I wanted to clarify in what part of the exchange the certificaterequestcontext field has a zero length.

which will be echoed in the client's Certificate message.  The certificate_request_context MUST be unique within the scope of this connection (thus preventing replay of client  <ins> CertificateVerify messages).  This field SHALL be zero length unless used for the post-handshake authentication exchanges described in Section 4.5.2. </ins> A list of the signature algorithms that the server is able to verify, listed in descending order of preference.  Any


is provided, the value is computed as: Where Secret is either the early_exporter_secret or the <del> exporter_secret. </del>  If no context is provided, the value is computed as:

Various changes to make exporters/resumption work better. The rationale is to be able to do stuff in 0/0.5RTT. Add a 0-RTT exporter and change the transcript for the regular exporter (*). Explicitly allow predicting ClientFinished for NST when not doing Client auth.

is provided, the value is computed as: Where Secret is either the early_exporter_secret or the  <ins> exporter_secret.  Implementations MUST use the exporter_secret unless explicitly specified by the application.  When adding TLS 1.3 to TLS 1.2 stacks, the exporter_secret MUST be for the existing exporter interface. </ins> If no context is provided, the value is computed as:


Pre-Shared Key ("pre_shared_key"; pre-shared-key-extension) <del> Server Name Indication ("server_name"; Section 3 of RFC6066) </del> Cookie ("cookie"; cookie)  All implementations MUST send and use these extensions when offering <del> applicable cipher suites: </del>  "supported_versions" is REQUIRED for all ClientHello messages. <del> "signature_algorithms" is REQUIRED for certificate authenticated cipher suites. </del>  "supported_groups" and "key_share" are REQUIRED for DHE or ECDHE <del> cipher suites. </del>  <del> "pre_shared_key" is REQUIRED for PSK cipher suites. </del>  <del> "cookie" is REQUIRED for all cipher suites. </del>  <del> When negotiating use of applicable cipher suites, endpoints MUST abort the handshake with a "missing_extension" alert if the required extension was not provided.  Any endpoint that receives an invalid combination of cipher suites and extensions MAY abort the connection with a "missing_extension" alert, regardless of negotiated parameters. </del>  Additionally, all implementations MUST support use of the "server_name" extension with applications capable of using it.

The MTI Extensions section is currently out-of-date. It wasn't updated with the new negotiation and still refers to the old cipher suites system. This PR cleans that up. I also drop the cookie extension universal send requirement, as that was in there as an alternative to allowing a server to send a cookie without first being prompted. We have that in as an explicit exception, currently.
I already did some of this in PR, so I'm going to hold this PR until that has landed and then we can take stock
Sure, I hadn't read that PR yet. A notable difference in the language here is that I'm replacing the "MAY abort the connection" line with specific requirements, as that high level of generalization is counterproductive now that cipher suites and feature extensions are decoupled.

Pre-Shared Key ("pre_shared_key"; pre-shared-key-extension)  Cookie ("cookie"; cookie) <ins> Server Name Indication ("server_name"; Section 3 of RFC6066) </ins> All implementations MUST send and use these extensions when offering  <ins> applicable features: </ins> "supported_versions" is REQUIRED for all ClientHello messages.  <ins> "signature_algorithms" is REQUIRED for certificate authentication. </ins> "supported_groups" and "key_share" are REQUIRED for DHE or ECDHE  <ins> key exchange. </ins>  <ins> "pre_shared_key" is REQUIRED for PSK key agreement. </ins>  <ins> A client is considered to be attempting to negotiate using this specification if the ClientHello contains a "supported_versions" extension, at minimum.  Such ClientHello messages MUST meet following requirements: </ins>  <ins> If not containing a "pre_shared_key" extension, it MUST contain both a "signature_algorithms" extension and a "supported_groups" extension. If containing a "supported_groups" extension, it MUST also contain a "key_share" extension, and vice versa. (an empty KeyShare.client_shares vector is permitted) Servers receiving a ClientHello which is attempting to negotiate using this specification, yet failing any of the above requirements, MUST abort the handshake with a "missing_extension" alert. </ins> Additionally, all implementations MUST support use of the "server_name" extension with applications capable of using it.


T.f2 refers to the second field of the previous declaration. Structure definitions may be embedded.  3.6.1. Defined structures may have variants based on some knowledge that is

To let's add some explanations to Section 3.
I have written a syntax validator to check the validity of definitions. In this issue, I would like to point out what I noticed.
(1) Some enum definitions use "floor..ceiling" notation which is not defined. Section 3.5 should clearly define this.
(2) I think that the keyword is allowed only in the top level definitions. But is used inside of EarlyDataIndication. I would suggest to defined the following in the top level:
(3) The following assignment is really strange: I would suggest to change this to:
On Wednesday, September 07, 2016 04:24:15 am Kazu Yamamoto wrote: I don't understand why you consider this current notation here strange. It's the same notation used for enum values elsewhere.
What I can tell from Section 3 is as follows: The "symbol(num)" notation is allowed in the declaration of enum. "symbol" can be used as label of the case clause. "{num, ...}" can be used for assignment. I don't see that "symbol(num)" can be used for assignment. I wrote a parse based on Section 3 and what I reported here is the errors reported by the parser.

T.f2 refers to the second field of the previous declaration. Structure definitions may be embedded. <ins> Basically the "struct" notation is used in the top level to define a new type.  However, there is one exception that an anonymous structure "struct {}", which means empty, can be used inside of another structure. </ins> 3.6.1. Defined structures may have variants based on some knowledge that is


3.5. <del> An additional sparse data type is available called enum.  A field of type enum can only assume the values declared in the definition. Each definition is a different type.  Only enumerateds of the same type may be assigned or compared.  Every element of an enumerated must be assigned a value, as demonstrated in the following example. Since the elements of the enumerated are not ordered, they can be assigned any unique value, in any order. </del>  An enumerated occupies as much space in the byte stream as would its maximal defined ordinal value.  The following definition would cause force the width definition without defining a superfluous element. In the following example, Taste will consume two bytes in the data <del> stream but can only assume the values 1, 2, or 4. </del>  The names of the elements of an enumeration are scoped within the defined type.  In the first example, a fully qualified reference to

with few possible exceptions, enumerateds will assume values different than the ones they were originally defined with. Backwards compatibility of Client Hello is dependent on implementations being able to ignore values they do not know about.
This doesn't seem quite right. Some enums are complete in the sense that you should not ignore unknown ones (HandshakeType) and some are not complete (ExtensionType, CipherSuite).
How about then "URL parse and ignore them unless the their deifnition states otherwise".?
sure that would be fine

3.5.  <ins> An additional sparse data type is available called enum.  Each definition is a different type.  Only enumerateds of the same type may be assigned or compared.  Every element of an enumerated must be assigned a value, as demonstrated in the following example.  Since the elements of the enumerated are not ordered, they can be assigned any unique value, in any order. Future extension or additions to the protocol may define new values. Implementations need to be able to parse and ignore them unless their definition states otherwise. </ins> An enumerated occupies as much space in the byte stream as would its maximal defined ordinal value.  The following definition would cause force the width definition without defining a superfluous element. In the following example, Taste will consume two bytes in the data  <ins> stream but can only assume the values 1, 2, or 4 in current version of protocol. </ins> The names of the elements of an enumeration are scoped within the defined type.  In the first example, a fully qualified reference to


deprecated and MUST be ignored for all purposes. The length (in bytes) of the following TLSPlaintext.fragment.  The <del> length MUST NOT exceed 2^14. </del>  The data being transmitted.  This value transparent and treated as an independent block to be dealt with by the higher-level protocol

Before record protection is established, if an endpoint receives a TLSPlaintext structure whose "length" field is too large (>2^14), should it send a "record_overflow" alert?

deprecated and MUST be ignored for all purposes. The length (in bytes) of the following TLSPlaintext.fragment.  The  <ins> length MUST NOT exceed 2^14.  An endpoint that receives a record that exceeds this length MUST terminate the connection with a "record_overflow" alert. </ins> The data being transmitted.  This value transparent and treated as an independent block to be dealt with by the higher-level protocol


Versions of TLS before TLS 1.3 supported a session resumption feature which has been merged with Pre-Shared Keys in this version (see resumption-and-psk).  This field MUST be ignored by a server <del> negotiating TLS 1.3 and SHOULD be set as a zero length vector (i.e., a single zero byte length field) by clients which do not have a cached session ID set by a pre-TLS 1.3 server. </del>  This is a list of the symmetric cipher options supported by the client, specifically the record protection algorithm (including

All other fields deprecated by this spec use "MUST be set to ...", such as ClientHello.legacyversion, ClientHello.legacycompressionmethods, TLSPlaintext.legacyrecordversion. Only ClientHello.legacysession_id "SHOULD be set as [...]" So I suggest changing this to "MUST" as well.

Versions of TLS before TLS 1.3 supported a session resumption feature which has been merged with Pre-Shared Keys in this version (see resumption-and-psk).  This field MUST be ignored by a server  <ins> negotiating TLS 1.3 and MUST be set as a zero length vector (i.e., a single zero byte length field) by clients which do not have a cached session ID set by a pre-TLS 1.3 server. </ins> This is a list of the symmetric cipher options supported by the client, specifically the record protection algorithm (including


registries and their allocation policies are below: TLS Cipher Suite Registry: Values with the first byte in the range <del> 0-254 (decimal) are assigned via Specification Required RFC2434. </del>  Values with the first byte 255 (decimal) are reserved for Private <del> Use RFC2434. </del>  IANA [SHALL add/has added] the cipher suites listed in cipher- suites to the registry.  The "Value" and "Description" columns are D.sandj-tls-iana-registry-updates has been applied.]] TLS ContentType Registry: Future values are allocated via <del> Standards Action RFC2434. </del>  TLS Alert Registry: Future values are allocated via Standards <del> Action RFC2434. </del>  TLS HandshakeType Registry: Future values are allocated via <del> Standards Action RFC2434.  IANA [SHALL update/has updated] this </del>  registry to rename item 4 from "NewSessionTicket" to "new_session_ticket". TLS ExtensionType Registry: Values with the first byte in the range 0-254 (decimal) are assigned via Specification Required <del> RFC2434.  Values with the first byte 255 (decimal) are reserved for Private Use RFC2434.  IANA [SHALL update/has updated] this </del>  registry to include the "key_share", "pre_shared_key", and "early_data" extensions as defined in this document. TLS SignatureScheme Registry: Values with the first byte in the range 0-254 (decimal) are assigned via Specification Required <del> RFC2434.  Values with the first byte 255 (decimal) are reserved for Private Use RFC2434.  Values with the first byte in the range </del>  0-6 or with the second byte in the range 0-3 that are not currently allocated are reserved for backwards compatibility. This registry SHALL have a "Recommended" column.  The registry

RFC 5226 obsoleted RFC 2434 so we should refer to that to avoid a GENART review comment.

registries and their allocation policies are below: TLS Cipher Suite Registry: Values with the first byte in the range  <ins> 0-254 (decimal) are assigned via Specification Required RFC5226. </ins> Values with the first byte 255 (decimal) are reserved for Private  <ins> Use RFC5226. </ins> IANA [SHALL add/has added] the cipher suites listed in cipher- suites to the registry.  The "Value" and "Description" columns are D.sandj-tls-iana-registry-updates has been applied.]] TLS ContentType Registry: Future values are allocated via  <ins> Standards Action RFC5226. </ins> TLS Alert Registry: Future values are allocated via Standards  <ins> Action RFC5226. </ins> TLS HandshakeType Registry: Future values are allocated via  <ins> Standards Action RFC5226.  IANA [SHALL update/has updated] this </ins> registry to rename item 4 from "NewSessionTicket" to "new_session_ticket". TLS ExtensionType Registry: Values with the first byte in the range 0-254 (decimal) are assigned via Specification Required  <ins> RFC5226.  Values with the first byte 255 (decimal) are reserved for Private Use RFC5226.  IANA [SHALL update/has updated] this </ins> registry to include the "key_share", "pre_shared_key", and "early_data" extensions as defined in this document. TLS SignatureScheme Registry: Values with the first byte in the range 0-254 (decimal) are assigned via Specification Required  <ins> RFC5226.  Values with the first byte 255 (decimal) are reserved for Private Use RFC5226.  Values with the first byte in the range </ins> 0-6 or with the second byte in the range 0-3 that are not currently allocated are reserved for backwards compatibility. This registry SHALL have a "Recommended" column.  The registry


This document deals with the formatting of data in an external representation.  The following very basic and somewhat casually <del> defined presentation syntax will be used.  The syntax draws from several sources in its structure.  Although it resembles the programming language "C" in its syntax and XDR RFC4506 in both its syntax and intent, it would be risky to draw too many parallels.  The purpose of this presentation language is to document TLS only; it has no general application beyond that particular goal. </del>  3.1. Structure definitions may be embedded.  Anonymous structs may also be defined inside other structures. <del> 3.6.1. </del>  Defined structures may have variants based on some knowledge that is available within the environment.  The selector must be an enumerated For example: <del> 3.7. Typed constants can be defined for purposes of specification by declaring a symbol of the desired type and assigning values to it. Under-specified types (opaque, variable-length vectors, and structures that contain opaque) cannot be assigned values.  No fields of a multi-element structure or vector may be omitted. For example: </del> 3.8. TLS defines two generic alerts (see alert-protocol) to use upon

The caveats at the beginning are silly We don't seem to every use Foo = { A, B} but we do use Foo = A;
Fixed, thanks

This document deals with the formatting of data in an external representation.  The following very basic and somewhat casually  <ins> defined presentation syntax will be used. </ins> 3.1. Structure definitions may be embedded.  Anonymous structs may also be defined inside other structures.  <ins> 3.7. Fields and variables may be assigned a fixed value using "=", as in: 3.7.1. </ins> Defined structures may have variants based on some knowledge that is available within the environment.  The selector must be an enumerated For example:  3.8. TLS defines two generic alerts (see alert-protocol) to use upon


server sends an empty extension to indicate negotiation of this extension and the OCSP information is carried in a CertificateStatus message.  In TLS 1.3, the server's OCSP information is carried in an <del> extension in the CertificateEntry containing the assoiciated </del>  certificate.  Specifically: The body of the "status_request" or "status_request_v2" extension from the server MUST be a CertificateStatus structure as defined in RFC6066 and RFC6961

I believe that these are just cleanup, though you might want to check the PSK one a little more carefully (happy to separate it if it is a problem).
We seem to have reached consensus that the record layer will use the AEAD form only. The stream and CBC forms will be removed.
Fixed.

server sends an empty extension to indicate negotiation of this extension and the OCSP information is carried in a CertificateStatus message.  In TLS 1.3, the server's OCSP information is carried in an  <ins> extension in the CertificateEntry containing the associated </ins> certificate.  Specifically: The body of the "status_request" or "status_request_v2" extension from the server MUST be a CertificateStatus structure as defined in RFC6066 and RFC6961


qualification is not required if the target of the assignment is well specified. <del> For enumerateds that are never converted to external representation, the numerical information may be omitted. </del> The names assigned to enumerateds do not need to be unique.  The numerical value can describe a range over which the same name applies.  The value includes the minimum and maximum inclusive values

We don't actually use this syntax, and having it in here just adds useless complexity. Defining syntax we don't actually use just risks confusing people reading the document for the first time.

qualification is not required if the target of the assignment is well specified.  The names assigned to enumerateds do not need to be unique.  The numerical value can describe a range over which the same name applies.  The value includes the minimum and maximum inclusive values


the server has ignored any early data and an ordinary 1-RTT handshake is required. <del> Return an empty extension, indicating that it intends to process </del>  the early data.  It is not possible for the server to accept only a subset of the early data messages.

This extension is now empty. Minor cleanup.
I think "it's own" is useful, but my instinct is that having the empty struct makes life easier.
If you would rather keep the empty struct, I don't have a strong objection. Repushed with just the minor wording tweak.

the server has ignored any early data and an ordinary 1-RTT handshake is required.  <ins> Return its own extension, indicating that it intends to process </ins> the early data.  It is not possible for the server to accept only a subset of the early data messages.


The version and extensions fields have the same meanings as their corresponding values in the ServerHello.  The server SHOULD send only the extensions necessary for the client to generate a correct <del> ClientHello pair (currently no such extensions exist).  As with ServerHello, a HelloRetryRequest MUST NOT contain any extensions that were not first offered by the client in its ClientHello, with the exception of optionally the "cookie" (see cookie) extension. </del>  Upon receipt of a HelloRetryRequest, the client MUST verify that the extensions block is not empty and otherwise MUST abort the handshake

I think this aside is out-of-date: extensions cannot be empty, and there are now defined extensions to put here.

The version and extensions fields have the same meanings as their corresponding values in the ServerHello.  The server SHOULD send only the extensions necessary for the client to generate a correct  <ins> ClientHello pair.  As with ServerHello, a HelloRetryRequest MUST NOT contain any extensions that were not first offered by the client in its ClientHello, with the exception of optionally the "cookie" (see cookie) extension. </ins> Upon receipt of a HelloRetryRequest, the client MUST verify that the extensions block is not empty and otherwise MUST abort the handshake


The following table defines the Handshake Context and MAC Base Key for each scenario: <del> The [sender] in this table denotes the sending side. </del> In all cases, the handshake context is formed by concatenating the indicated handshake messages, including the handshake message type and length fields.

NAME please double-check
URL The 1-RTT annotations are redundant and you also don't need [sender] in brackets because we can just fill in the values, as client/server have separate tables lines

The following table defines the Handshake Context and MAC Base Key for each scenario:  In all cases, the handshake context is formed by concatenating the indicated handshake messages, including the handshake message type and length fields.


this connection (thus preventing replay of client CertificateVerify messages).  This field SHALL be zero length unless used for the post-handshake authentication exchanges <del> described in Section 4.5.2. </del>  A list of the signature algorithms that the server is able to verify, listed in descending order of preference.  Any

Fix a reference to a section that's directly citing a section number in plain text. (not linkified and will break if sections change) I assume this is a copy/paste error.

this connection (thus preventing replay of client CertificateVerify messages).  This field SHALL be zero length unless used for the post-handshake authentication exchanges  <ins> described in post-handshake-authentication. </ins> A list of the signature algorithms that the server is able to verify, listed in descending order of preference.  Any


optional data differs from the normal TLS method of having a variable-length field, but it is used for compatibility with TLS before extensions were defined.  As of TLS 1.3, all clients and <del> servers will send at least one extension (at least "key_share" or </del>  "pre_shared_key"). In previous versions of TLS, this field was used for version

The current text works, but tweaking it to be more general for issue is simple.
In the Client Hello (4.1.2) it says: As of TLS 1.3, all clients and servers will send at least one extension (at least "keyshare" or "presharedkey"). I believe that at least the supportedversions extension is also required for a client.
Rather than enumerating everything here, I've pushed a PR to just change "at least" to "e.g.".
I changed this separately.

optional data differs from the normal TLS method of having a variable-length field, but it is used for compatibility with TLS before extensions were defined.  As of TLS 1.3, all clients and  <ins> servers will send at least one extension (e.g. "key_share" or </ins> "pre_shared_key"). In previous versions of TLS, this field was used for version


TLS Alert Registry: Future values are allocated via Standards Action RFC5226.  IANA [SHALL update/has updated] this registry to <del> include values for "end_of_early_data" and "missing_extension". </del>  TLS HandshakeType Registry: Future values are allocated via Standards Action RFC5226.  IANA [SHALL update/has updated] this

and fix also not needed comma
:+1: was about to fix this too. Change was introduced by NAME in f6f752f9af24f99241ba98510cfb1dd758bf4bf9 (included with draft 16).
Hi, I have update the change !

TLS Alert Registry: Future values are allocated via Standards Action RFC5226.  IANA [SHALL update/has updated] this registry to  <ins> include values for "end_of_early_data", "missing_extension", and "certificate_required". </ins> TLS HandshakeType Registry: Future values are allocated via Standards Action RFC5226.  IANA [SHALL update/has updated] this


The content to be signed This structure is intended to prevent an attack on previous versions <del> of previous versions of TLS in which the ServerKeyExchange format meant that attackers could obtain a signature of a message with a chosen, 32-byte prefix.  The initial 64 byte pad clears that prefix. </del>  The context string for a server signature is "TLS 1.3, server CertificateVerify" and for a client signature is "TLS 1.3, client

I think this is a typo. But I'm not sure since I'm not a native English speaker. Please check it out.

The content to be signed This structure is intended to prevent an attack on previous versions  <ins> of TLS in which the ServerKeyExchange format meant that attackers could obtain a signature of a message with a chosen, 32-byte prefix. The initial 64 byte pad clears that prefix. </ins> The context string for a server signature is "TLS 1.3, server CertificateVerify" and for a client signature is "TLS 1.3, client


The AEAD output consists of the ciphertext output by the AEAD encryption operation.  The length of the plaintext is greater than <del> TLSPlaintext.length due to the inclusion of TLSPlaintext.type and however much padding is supplied by the sender.  The length of the AEAD output will generally be larger than the plaintext, but by an amount that varies with the AEAD algorithm.  Since the ciphers might incorporate padding, the amount of overhead could vary with different lengths of plaintext.  Symbolically, </del>  In order to decrypt and verify, the cipher takes as input the key, nonce, and the AEADEncrypted value.  The output is either the

TLSCiphertext.fragment is undefined. I guess it should be "TLSCiphertext.encrypted_record"? This sentence "due to the inclusion of URL and however much padding is supplied by the sender" is unclear to me. Does it mean "due to the inclusion of URL and the padding"?

The AEAD output consists of the ciphertext output by the AEAD encryption operation.  The length of the plaintext is greater than  <ins> TLSPlaintext.length due to the inclusion of TLSPlaintext.type and any padding supplied by the sender.  The length of the AEAD output will generally be larger than the plaintext, but by an amount that varies with the AEAD algorithm.  Since the ciphers might incorporate padding, the amount of overhead could vary with different lengths of plaintext.  Symbolically, </ins> In order to decrypt and verify, the cipher takes as input the key, nonce, and the AEADEncrypted value.  The output is either the


In all cases, the handshake context is formed by concatenating the indicated handshake messages, including the handshake message type <del> and length fields. </del>  4.4.1. functions defined below: The Hash function and the HKDF hash are the cipher suite hash <del> algorithm.  Hash.length is its output length. </del>  Given a set of n InputSecrets, the final "master secret" is computed by iteratively invoking HKDF-Extract with InputSecret_1,

When I was implementing the key schedule, it was unclear to me what stands for. This additional note would help other implementors. Kazuho Oku pointed out the similarity to Handshake Context. So, I updated that part, too.

In all cases, the handshake context is formed by concatenating the indicated handshake messages, including the handshake message type  <ins> and length fields, but not including record layer headers. </ins> 4.4.1. functions defined below: The Hash function and the HKDF hash are the cipher suite hash  <ins> algorithm.  Hash.length is its output length.  Messages are the concatenation of the indicated handshake messages, including the handshake message type and length fields, but not including record layer headers. </ins> Given a set of n InputSecrets, the final "master secret" is computed by iteratively invoking HKDF-Extract with InputSecret_1,


ServerHello messages authenticates the protocol version, so this value is redundant. <del> The length (in bytes) of the following TLSCiphertext.fragment, which is the sum of the lengths of the content and the padding, plus one for the inner content type.  The length MUST NOT exceed 2^14 + 256.  An endpoint that receives a record that exceeds this length MUST terminate the connection with a "record_overflow" alert. </del>  The AEAD encrypted form of the serialized TLSInnerPlaintext structure.

Yes. There is a fair amount of other cleanup needed in this area; I have lots of red pen markings on a printout but haven't translated them into a patch yet.
Yes. There is a fair amount of other cleanup needed in this area; I have lots of red pen markings on a printout but haven't translated them into a patch yet.
Bah, github was angry-unicorning on me and did not indicate that the comment went through. I guess github doesn't like me this week...

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 the content and the padding, plus one for the inner content type. The length MUST NOT exceed 2^14 + 256.  An endpoint that receives a record that exceeds this length MUST terminate the connection with a "record_overflow" alert. </ins> The AEAD encrypted form of the serialized TLSInnerPlaintext structure.