Added text on determining the validity of OCSP responses #974
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
nmav
force-pushed
the
tmp-ocsp-validity-clarification
branch
from
142df98 to
9a0f0a0
Compare
|
I think this is more text than is needed (and also one paragraph too late); I would rather just see a minimal reference to RFC 6960 for all OCSP handling. |
|
@nmav: can you post this to the list? |
|
@ekr I have already (RH mail server is down, it may take some time till it is there sorry). The reason there is more text than the RFC6960 reference is the fact that RFC6960 says nothing about the validity time when the nextUpdate field is missing. |
Oh. Ugh. Maybe this amount of text will be appropriate, then; let's see what happens on the list. |
nmav
force-pushed
the
tmp-ocsp-validity-clarification
branch
from
9a0f0a0 to
178720d
Compare
kroeckx
reviewed
Apr 22, 2017
draft-ietf-tls-tls13.md
Outdated
| 'thisUpdate' OCSP response field. | ||
|
|
||
| Similarly with the OCSP response extension, {{!RFC6962}} provides a mechanism | ||
| for a server to send aSigned Certificate Timestamp (SCT) as an extension in |
There was a problem hiding this comment.
missing space between "a" and "Signed"
The OCSP protocol (RFC6960), defines the validity period of an OCSP response based on the presence of the thisUpdate and nextUpdate values. However, the nextUpdate value is optional, and may be omitted in an OCSP response. In that case it is implied by the OCSP issuer that an updated OCSP response is available at all time, however, that does not give a hint to verifier for how long to treat the previous response valid. Set a maximum value to 15 days.
nmav
force-pushed
the
tmp-ocsp-validity-clarification
branch
from
178720d to
ac15925
Compare
brainhub
added a commit
to brainhub/tls13-spec
that referenced
this pull request
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The OCSP protocol (RFC6960), defines the validity period of an
OCSP response based on the presence of the thisUpdate and nextUpdate
values. However, the nextUpdate value is optional, and may be omitted
in an OCSP response. In that case it is implied by the OCSP issuer
that an updated OCSP response is available at all time, however,
that does not give a hint to verifier for how long to treat the
previous response valid. Set a maximum value to 15 days.