Leave question of replaying early data to application profile? #971
Comments
brainhub
added a commit
to brainhub/tls13-spec
that referenced
this issue
Jun 2, 2017
* Remove redundant whitespace in word composition * x-dash-byte * Add article before version [replaces leonklingele's original commit.] * Update 'octets' -> 'bytes' to better preserve context * Command -> 'and' * Use correct plural / singlar form * Add 'as described in' * Make use of 'TLS' more uniform [revised from leonklingele's original by ekr] * Lowercase 'length' * Lowercase 'certificate' * Add missing hyphen symbols * Add unit of a number * Split word * Add missing comma [revised from leonklingele's original by ekr] * Uppercase 'X' in 'X25519' and 'X448' * Use 'an' instead of 'a' * Add myself as contributor * Use MAY / MUST NOT in extension requests definition [revised by ekr] * Uppercase 'SHOULD' * 'MUST behave' * Use MUST / MAY for specification of 'Certificate Request' * Uppercase 'MAY' * Alert MUST be ignored * Uppercase 'MUST' * Closing the connection after receiving a fatal alert is required. Use MUST. * Make the labels the same. Clean up diagram a bit * Update changelog * Clarify what max_early_data_size refers to * Fix the security analysis to indicate that it's the keys derived from the master key that are unique, not the master key itself. Thanks to @davidben for pointing this out * Tidy up singular vs. plural session keys. Follow-up to 3996e45. * MT comments * Fix exporter definition bustage from PR#882. Fixes tlswg#898 * fix consistency of the key schedule diagram * Derive-Secret can now have an argument from the top. Closes tlswg#900 * Remove unnecessary arrowheads * Special-case the hash for CH1 when HRR is used. This allows the server to just store H(CH1) when doing HRR. * Warn about eternal ticket extension. Fixes tlswg#871 * End of ClientHello and EndOfEarlyData messages should be on a record boundary An EndOfEarlyData message signals a key change. A ClientHello can be the last message read before a key is changed, and it never makes sense for a ClientHello to have more data after it in the record. * Fix editorial issues for PR tlswg#901 * Add cipher suite to the HRR. This makes it slightly easier for the client to implement because it knows what hash the server will select. Also clarify the language about HRR and Key Shares. * Clarify the relationship between PSK and certificates. Closes tlswg#870 * Add comma * Text clarification * Update change log * Clarify the HRR->PSK interaction * Update changelog * Explain max_fragment_length * Fix xref * Clarify that status_request in CR extensions is empty * Clean up description of messages in the transcript hash: 1. Move the list to the new transcript hash section. 2. Note that EndOfEarlyData goes in the client Handshake Context. * Suggest more strongly that EndOfEarlyData is deferred. 31f8362 missed a spot. * This was too deep * RFC 5746 isn't mentioned in the text * Contributors appears to be sorted by last name, clean up for consistency * extensions cleanups in ClientHello This tweaks some text in ClientHello with regard to handling the extensions field. The two blocks of text on it in this section are merged together, dropping a little repeated information and putting it in one paragraph after definition of the relevant field instead of covering this in two places in the same section. * Add Brian Sniffen to contributors * Require implementations to verify record boundary when a key change happens rather than on receipt of handshake messages. * Add self to contributors. * Update Jim Roskind's affiliation. Fixes tlswg#927 * Standardize on {client, server} Finished. Closes tlswg#916 * - Remove support for disallowed extensions (cert_type, user_mapping). - Explicitly define RFC 7250 certificate support. * All post-handshake messages must be consecutive. Fixes tlswg#930. * Remove vestigial text about EOED being an alert. Fixes tlswg#918 * require fresh ticket_age_add. Fixes tlswg#913 * Add an extension to negotiate use of post-handshake client authentication Squashed version of MT's draft. * Clarify announcement not negotiation * Add Matt Green's name. Fixes tlswg#928. * IANA considerations section tweak. * Minor editorial * Inline certificate * IDNits reports unused references. * Editorial * Server sends early_data in EE * Sync extension enum with table of extensions Give the values for the extensions we mention as usable. Also some extension-related editorial changes, since apparently I was sloppy about my 'git add -p's. * Add signature_algorithms to the full handshake diagram You need it if you're going to get certificate auth from the server. * Fix NewSessionTicket links With this short anchor we were ending up in the appendix, not the body section that actually talks about the contents. * Swap the order of some text about PSKs/early data It's rather jarring to go straight from EarlyDataIndication to PSKs provisioned via NewSessionTicket. There may be a better place for some of this text, but I didn't see one in a less-than-cursory skim. * No alerts in 0-RTT data? (Mostly I just wanted to take out 'respectively', as there is no previous list to be parallel with. * Always send EndOfEarlyData Not just if the server accepts it. This way if the server can decrypt the messages it doesn't have to do trial decryption to find the end. * Revert "Always send EndOfEarlyData" This reverts commit 7501876e544d7688246309390b8938b3491ee04b. Whoops, we can't do this, since it goes into the transcript now. * Content-type 0 is just invalid, not RESERVED That is, we say _RESERVED means "was used in previous version of TLS", but we are allocating it so as to avoid ambiguity when stripping padding. * Opportunistic encryption is a thing * Apply feedback from @davegarrett * Post-landing cleanup for PR#936 * Ben Kaduk's on-list comments * Address Nikos's straightforward comments * client_certificate_type is CR and CT * Revert "client_certificate_type is CR and CT". Pilot error. This reverts commit 56759ec. * Note some application considerations about padding We allow sending just padding and no application data; be sure you think about what you want to do with that. Also note that the max_early_data_size limit is something of a lie in terms of clients sending lots of padding. * Annotate extension code points with RFC number Show inline which document defines the meaning of that extension, in addition to listing it in the table of extensions. * Move references to the same line * Remove some text I thought was unnecessary * Insert anti-downgrade token when TLS 1.0 or below as well. * Revise the text on ticket age handling on the client and server. Fixes tlswg#919, tlswg#940, tlswg#944.tlswg#944 * Require (2119 SHOULD) that the certificate context for post-handshake be unpredictable in order to prevent pre-computation of CertificateVerify. Maybe this should actually be a MUST? * Formal representation of point format. Fixes tlswg#943. As suggested by Nikos, provide a formal description of the point format modelled on 4492-bis. * Update major differences section to actually be differences from TLS 1.2, not a change log. Fixes tlswg#931, Fixes tlswg#923 * Clean up the Major Differences section * module -> modulo * Update variable names. Fixes tlswg#942. Make the variable names of various secrets correspond to the labels used for Derive-Secret(). This is not a wire format change, but just a change in the internal variable names. * Tweak guidance on clock skew window Mention the assumptions going into the quoted number. Also fix a typo. * Bigger caveat for 0-RTT data * Add references to published analyses Some additions/modifications to tlswg#951 changes * Add references to published analyses Ordering by year * Add references to published analyses added BBK17 * Formatting * Add additional security considerations text provided by Hugo Krawczcyk * Minor editorial * Minor editorial * Update based on comments from Hugo and Ben * Move text about PSK interaction with certificate-based client authentication. Fixes tlswg#934. * Break sentence * Re-enable post-handshake client authentication for PSK handshakes. When we banned client auth and PSK, we only meant to do it for the main handshake, not the post-handshake phase. This reverts that change, as well as clarifies the prophibition on PSK plus cert-based auth. * Remove redundant 'an' * Added contribs on request by ekr * Fix xref * Fix reference * Fix some stragglers * One more straggler * Enhanced the list of TLS 1.3 features * Add post_handshake_auth to the list of extensions in IANA considerations. * Editorial work on the Major Changes section * Add text about PSK entropy. Fixes tlswg#965. As Ilari points out on the list, the PSK mechanism is subject to dictionary attacks based on the PSK binder. Make this clear. Modification of text originally provided by Hannes Tschofenig. * Update text * Revert "Update text" This reverts commit 4e2c304. * Update text again * Use ekr's version of ID template while waiting for MT to fix recent defect * Fix make issue * Revert "Fix make issue" This reverts commit f54385d. * Fix markdown * Fix makefile * Shorter HKDF labels. Fixes tlswg#964. Per mailing list discussion, this allows us to have every HKDF-Expand just have one hash block of info. * Fix up two missing labels * Add changelog and explanatory note * Add a reference to RFC 6960. Fixes tlswg#974. There was a fair amount of on-list debate about how much guidance to give about OCSP. This merely cites 6960, which I think matches the area of consensus overlap. * Revise text about auto-replay of early data. Fixes tlswg#971. This just moves the warnings up so it's clear they generally apply. * Move Decoding Errors section for greater clarity. Fixes tlswg#970. * Change log for -20 * Align SignatureScheme ALL-CAPS-VERBS with RESERVED labels. Values in RESERVED labels, per the note at the top of Appendix B, MUST NOT be sent. This conflicts other text which tags ecdsa_sha1 and dsa_sha1 as SHOULD NOT. Back in early drafts, {*, dsa} and {sha1, ecdsa} were not tagged RESERVED and were merely SHOULD NOT in the text: https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-6.3.2.1 Then things were redone as SignatureScheme with the intent of preserving SHOULD NOTs and MUST NOTs. Accordingly, dsa_* values were defined, and with SHOULD NOTs in prose. tlswg#404 That was followed up by a cleanup change which left dsa_* values in there, but not defined. Intentionally or not, this took away the SHOULD NOT and left it with something unclear. tlswg@bed7281 Then the RESERVED tag was added, in response to the cleanup. Intentionally or not, this kicked in the Appendix B MUST NOT, which means TLS 1.3 implementations are forbidden from offering DSA to TLS 1.2 servers. Nonetheless, the SHOULD NOT reference to the now non-existent and verboten dsa_sha1 remained. tlswg#434 Next, an oversight in PR tlswg#404 was "corrected". PR tlswg#404 was intended to leave SHOULD NOTs and MUST NOTs as-is but downgraded {sha1, ecdsa} to a MUST NOT by omission. However, I did not notice the Appendix B text, so my correction was, in fact, a no-op. tlswg#488 Restoring ecdsa_sha1 was motivated by existing many implementations still offering {sha1, ecdsa} at TLS 1.2, so it was not clear whether removing it was realistic yet. (Notably, dependence on {sha1, rsa} aka rsa_pkcs1_sha1 is known to be prevalent.) Since then, BoringSSL has removed ecdsa_sha1, so that is some evidence it is unnecessary. NSS still offers it, however. So now we have a small mess on our hands. This PR attempts to bring things to a self-consistent picture. Implementations I'm involved with no longer offer ecdsa_sha1 or dsa_*, so I am personally fine with any self-consistent option. For this PR, I went with: Since PR#488 was accepted and even called out in the changelog, my interpretation was that it should end at SHOULD NOT. That I failed to actually implement originally is a bug. DSA is less clear, but since there were two changes by two separate people who chipped away at the SHOULD NOT, my interpretation is to leave it at MUST NOT. I have taken the two changes to their logical conclusion, removing the named dsa_*_RESERVED values and references to non-existent dsa_sha1. * Add sections on traffic analysis and side-channels. Original by Ben Kaduk. Substantial rewrites by EKR. * Revised per MT * Adding missing "no_application_protocol" alert RFC 7301 defines the ALPN extension and defined a new alert "no_application_protocol". TLS 1.3 uses ALPN but currently misses the alert in Section 6. * Error description for "no_application_protocol" alert added * Add ALPN clarification * Update references. Editorial * Updated with a few -20 changes * removing unused references * Fix build * updating reference for obsoleted normative reference * fixing spacing in 5869 reference * added list of updated and obsoleted RFS to the introduction. * Post-landing fixups for RFC updating text * Incorporate comments on PR#980. 1. Merge the legacy discussion for ecdsa_sha1 and rsa_pkcs1_sha1. 2. Restore the labels for the reserved dsa code points. * Revised per Kaduk's comments * adding me:spt * nit * moving reserved values for hash/sig algorithms registry * More editorial by Kaduk * Add Joe Salowey as contributor * Pre-publish editorial nits * Even more editorial nits * Even more minor tweak * Editorial, verb added * Update Joe's email * fixing syntax errors of ID 20. * "supported_groups" is not MTU in EncryptedExtensions Even when (EC)DHE is in use, the "supported_groups" extension is only mandatory in the ClientHello; it can be omitted from the EncryptedExtensions, as per section 4.2.6. Given that, it is not MTI for the server sending to the client, but the client must be prepared to accept the extension in EncryptedExtensions (at least to the point of not crashing or aborting the handshake), so leave the MTI text unchanged. It would be too awkward to try to express this subtlety in such a concise list. * Clarify "KDF Hash" HKDF-Expand-Label has changed between draft -19 and -20, clarify that "HDF Hash" refers to the hash algorithm and not a version-specific instance of HKDF-Expand-Label which is populated with a hash algorithm. * PSK context for 0-RTT needs version number The 0-RTT key might differ between TLS versions (as demonstrated with the draft -20 changes). Be explicit about storing this version number since section 4.2.9 requires this information too. * cite RFC for alert * Fix plural * 7301 is normative * Fixed Hugo's address * Add contrib ACK for Colm MacCarthaigh per tlswg#1001 (comment) * Clarify that EOED is sent iff server accepts early data * Servers may send extension responses in a Certificate message * Add Matt Caswell as a contributor * Allow clients to use any suitable alert if a non-acceptable cert chain There are a number of different alerts that may be suitable for sending to indicate a non-acceptable cert chain, e.g. certificate_revoked, certificate_expired, unknown_ca, etc. We should not restrict the client to only sending one specific alert. * Always send client's second flight. Fixes tlswg#1017 * A bunch of editorial changes to the security considerations suggested by Hugo Krawczyk. * Editorial * Encourage logging alerts, per Kathleen's AD review. Fixes tlswg#1014. * Update changelog to indicate updated references. Fixes tlswg#1015 * Add Brian Smith as a contributor. * revise to give more implementor flexibility, per comments by Brian Smith * Remove warnings * Not in figures FFS
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is from a note I made on a paper copy; I don't think I mentioned it anywhere already, but my apologies if it is a duplicate.
At the end of section 4.2.7 we have a paragraph saying that the client application MAY replay early data if the server rejects early data, but SHOULD NOT do so automatically (absent application input). Do we need to say anything about this topic other than "what to do when early data is rejected is left to the application profile"? I guess the concerns about matching ALPN and connection state do need to be here, at least.
The text was updated successfully, but these errors were encountered: