Exported Authenticators in TLS
draft-ietf-tls-exported-authenticator-15
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2022-05-10
|
15 | (System) | RFC Editor state changed to EDIT |
|
2022-05-10
|
15 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
|
2022-05-10
|
15 | (System) | Announcement was received by RFC Editor |
|
2022-05-10
|
15 | (System) | IANA Action state changed to In Progress |
|
2022-05-10
|
15 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
|
2022-05-10
|
15 | Cindy Morgan | IESG has approved the document |
|
2022-05-10
|
15 | Cindy Morgan | Closed "Approve" ballot |
|
2022-05-10
|
15 | Cindy Morgan | Ballot approval text was generated |
|
2022-05-10
|
15 | (System) | Removed all action holders (IESG state changed) |
|
2022-05-10
|
15 | Roman Danyliw | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Revised I-D Needed |
|
2022-03-19
|
15 | Roman Danyliw | Two remaining things from the IESG review: * Francesca Palombini From Section 4: used to send the authenticator request SHOULD use a secure with … Two remaining things from the IESG review: * Francesca Palombini From Section 4: used to send the authenticator request SHOULD use a secure with equivalent security to TLS, such as QUIC [QUIC-TLS], as its as its FP: What are the implications of not using such a secure transport protocol? Why is it just RECOMMENDED and not MANDATED? * Martin Duke Sec 1. I think you mean Sec 4.2.6 of RFC 8446, not 4.6.3. |
|
2022-03-19
|
15 | (System) | Changed action holders to Nick Sullivan (IESG state changed) |
|
2022-03-19
|
15 | Roman Danyliw | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Approved-announcement to be sent::AD Followup |
|
2022-03-04
|
15 | (System) | Removed all action holders (IESG state changed) |
|
2022-03-04
|
15 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
|
2022-03-04
|
15 | Nick Sullivan | New version available: draft-ietf-tls-exported-authenticator-15.txt |
|
2022-03-04
|
15 | (System) | New version accepted (logged-in submitter: Nick Sullivan) |
|
2022-03-04
|
15 | Nick Sullivan | Uploaded new revision |
|
2021-11-05
|
14 | Christopher Wood | Added to session: IETF-112: tls Tue-1600 |
|
2021-04-08
|
14 | (System) | Changed action holders to Nick Sullivan (IESG state changed) |
|
2021-04-08
|
14 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
|
2021-04-07
|
14 | Murray Kucherawy | [Ballot comment] Why are the SHOULDs in Section 4 only SHOULDs? Why might an implementer reasonably not do what this says? Similarly, the SHOULDs in … [Ballot comment] Why are the SHOULDs in Section 4 only SHOULDs? Why might an implementer reasonably not do what this says? Similarly, the SHOULDs in Section 7 seem awkward, as they have little to do with interoperability. |
|
2021-04-07
|
14 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
|
2021-04-07
|
14 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
|
2021-04-06
|
14 | Benjamin Kaduk | [Ballot comment] I've made some (mostl) editorial suggestions in a github PR: https://github.com/tlswg/tls-exported-authenticator/pull/73 Despite the overall YES ballot, I do have some substantive comments that … [Ballot comment] I've made some (mostl) editorial suggestions in a github PR: https://github.com/tlswg/tls-exported-authenticator/pull/73 Despite the overall YES ballot, I do have some substantive comments that may be worth some further consideration. Do we want to give any insight or examples into how an application might choose to use the certificate_request_context? Thanks to Yaron Sheffer for the multiple secdir reviews. My understanding is that the intent of this document is to only allow "server_name" to appear in the ClientCertificateRequest structure that otherwise uses the "CR" notation in the TLS 1.3 column of the TLS ExtensionType Values registry, but not to allow for "server_name" in authenticator CertificateRequests or handshake CertificateRequests. Assuming that's correct, the easiest way to indicate that would be if there was a "Comment" column in the registry that could say "only used in ClientCertificateRequest certificate requests and no other certificate requests", but there is not such a column in the registry. I think it could also work to be much more clear in the IANA considerations of this document as to why the "CR" is being added and what restrictions there are on its use, even if that's not quite as clean of a solution. Section 1 multiple identities - Endpoints that are authoritative for multiple identities - but do not have a single certificate that includes all of the identities - can authenticate additional identities over a single connection. IIUC this is only new functionality for server endpoints, since client endpoints can use different certificates for subsequent post-handshake authentication events. TLS (or DTLS) version 1.2 [RFC5246] [RFC6347]. or later are REQUIRED to implement the mechanisms described in this document. Please clarify whether this is a minimum TLS version required for using EAs, or that this is a binding requirement on implementations of the named protocol versions. (If the latter is intended we may have some discussions about an Updates: tag...) Section 5.1 Using an exporter value as the handshake context means that any client authentication from the initial handshake is not cryptographically digested into the exporter value. In light of what we ran into with EAP-TLS1.3, do we want to revisit whether we're still happy with that? We should in practice still benefit from the implicit confirmation that anything the server participates in after receiving the Client Finished means the server properly validated it and did not abort the handshake, but it's a bit awkward, especially since the RFC 8446 post-handshake authentication does digest the entire initial handshake transcript. Would we feel any safer if an exporter variant was available that digested the entire initial handshake transcript and we could use that? Section 5.2.1 Certificates chosen in the Certificate message MUST conform to the requirements of a Certificate message in the negotiated version of TLS. In particular, the certificate chain MUST be valid for the signature algorithms indicated by the peer in the "signature_algorithms" and "signature_algorithms_cert" extension, as described in Section 4.2.3 of [TLS13] for TLS 1.3 or the "signature_algorithms" extension from Sections 7.4.2 and 7.4.6 of [RFC5246] for TLS 1.2. This seems awkward. Do "the requirements of a Certificate message in the negotiated version of TLS" include the actual message structure? Because the rest of the document suggests that we always use the TLS 1.3 Certificate, but this line would set us up for using a TLS 1.2 Certificate. Also, per §1.3 of RFC 8446, "signature_algorithms_cert" also applies to TLS 1.2, so the last sentence seems incorrect or at least incomplete. Section 5.2.1 Otherwise, the Certificate message MUST contain only extensions present in the TLS handshake. Unrecognized extensions in the authenticator request MUST be ignored. At least the first sentence seems redundant with the previous section (but I did not propose removing this in my editorial PR). The second sentence arguably follows from the RFC 8446 requirements, though I don't mind mentioning it again as much as I do for the first sentence. Section 5.2.2 The authenticator transcript is the hash of the concatenated Handshake Context, authenticator request (if present), and Certificate message: Hash(Handshake Context || authenticator request || Certificate) Where Hash is the authenticator hash defined in section 4.1. If the authenticator request is not present, it is omitted from this construction, i.e., it is zero-length. This construction is injective, because the handshake messages start with a message HandshakeType. Should we say so explicitly in the document? If the party that generates the exported authenticator does so with a different connection than the party that is validating it, then the Handshake Context will not match, resulting in a CertificateVerify message that does not validate. This includes situations in which the application data is sent via TLS-terminating proxy. Given a failed CertificateVerify validation, it may be helpful for the application to confirm that both peers share the same connection using a value derived from the connection secrets before taking a user-visible action. Is it safe to reuse the Handshake Context itself as the "value derived from the connection secrets"? Section 7.4 It returns the identity, such as the certificate chain and its extensions, and a status to indicate whether the authenticator is valid or not after applying the function for validating the certificate chain to the chain contained in the authenticator. I strongly recommend not returning the identity in the case when validation fails. The API should return a failure if the certificate_request_context of the authenticator was used in a previously validated authenticator. Is the intent for this to be a "distinct previously validated authenticator" (i.e., that the API returns the same value when given the same inputs subsequently)? That does not seem to be the meaning conveyed by the current text. Section 8.2 IANA is requested to add the following entries to the registry for Exporter Labels (defined in [RFC5705]): "EXPORTER-server authenticator handshake context", "EXPORTER-client authenticator finished key" and "EXPORTER-server authenticator finished key" with Don't we also need "EXPORTER-client authenticator handshake context"? Section 9 I think we should more explicitly incorporate the TLS 1.3 security considerations by reference. Section 11.1 I don't think [QUIC-TLS] or RFCs 7250 and 7540 are normative references. |
|
2021-04-06
|
14 | Benjamin Kaduk | [Ballot Position Update] New position, Yes, has been recorded for Benjamin Kaduk |
|
2021-04-06
|
14 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated), and some … [Ballot comment] Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits. I hope that this helps to improve the document, Regards, -éric == COMMENTS == I am trusting the WG and the responsible AD for ensuring that the specific section in references are the correct ones. -- Section 2 -- Unsure where the "terminology" part is... Also, should "Client" and "Server" be defined here ? Reading section 3, I am still unsure whether the "client" and "server" are the "TLS client" and "TLS server" ... In the same vein, a small figure with all parties involved would be welcome by the reader. == NITS == In some places, 'TLS13' is used as an anchor rather than 'RFC8446'. Sometimes, the document uses 'octet' and sometimes 'bytes'. -- Section 1 -- Spurious '.' in the last §. -- Section 4 -- "as its as its" ? |
|
2021-04-06
|
14 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
|
2021-04-06
|
14 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
|
2021-04-06
|
14 | Warren Kumari | [Ballot comment] Thanks! |
|
2021-04-06
|
14 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
|
2021-04-06
|
14 | Lars Eggert | [Ballot comment] All comments below are very minor change suggestions that you may choose to incorporate in some way (or ignore), as you see fit. … [Ballot comment] All comments below are very minor change suggestions that you may choose to incorporate in some way (or ignore), as you see fit. There is no need to let me know what you did with these suggestions. Section 1, paragraph 9, nit: - TLS (or DTLS) version 1.2 [RFC5246] [RFC6347]. or later are REQUIRED - - - + TLS (or DTLS) version 1.2 [RFC5246][RFC6347] or later are REQUIRED |
|
2021-04-06
|
14 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert |
|
2021-04-06
|
14 | Zaheduzzaman Sarker | [Ballot comment] Thanks for the work on this document. I found it well written and I have minor comments and Nits Comment : * … [Ballot comment] Thanks for the work on this document. I found it well written and I have minor comments and Nits Comment : * As this document asked for a IANA registration entry with DTLS-OK, hence this mechanism is OK to be used with DTLS. I understand the heavily references to TLS 1.3 as it relay on the mechanisms described there. However, I found it odd not find any reference to DTLS1.3 (we had it on the last formal IESG telechat, it is quite ready to be referenced). Is this intentional? is it supposed to be that this mechanism defined in this document on can be used with DTLS1.2? * Section 7.3 & 7.4: is "active connection" defined somewhere? it would be good if some descriptive texts are added for clarification as done for the other bullets in the same list. * For the API considerations I was expecting a API to generate the certificate_request_context. Nits: * Post-handshake authentication is not defined in section 4.6.3 of TLS 1.3 * Section 4 & 5: likely copy paste error -- s/as its as its/as its |
|
2021-04-06
|
14 | Zaheduzzaman Sarker | Ballot comment text updated for Zaheduzzaman Sarker |
|
2021-04-06
|
14 | Zaheduzzaman Sarker | [Ballot comment] Thanks for the work on this document. I found it well written and I have minor comments and Nits Comment : * As … [Ballot comment] Thanks for the work on this document. I found it well written and I have minor comments and Nits Comment : * As this document asked for a IANA registration entry with DTLS-OK, hence this mechanism is OK to be used with DTLS. I understand the heavily references to TLS 1.3 as it relay on the mechanisms described there. However, I found it odd not find any reference to DTLS1.3 (we had it on the last formal IESG telechat, it is quite ready to be referenced). Is this intentional? is it supposed to be that this mechanism defined in this document on can be used with DTLS1.2? * Section 7.3 & 7.4: is "active connection" defined somewhere? it would be good if some descriptive texts are added for clarification as done for the other bullets in the same list. * For the API considerations I as expecting a API to generate the certificate_request_context. Nits: * Post-handshake authentication is not defined in section 4.6.3 of TLS 1.3 * Section 4 & 5: likely copy paste error -- s/as its as its/as its |
|
2021-04-06
|
14 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
|
2021-04-05
|
14 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
|
2021-04-05
|
14 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
|
2021-04-04
|
14 | Francesca Palombini | [Ballot comment] Thank you for the work on this document, and thank you to the doc shepherd for the in-depth background. Please find some comments … [Ballot comment] Thank you for the work on this document, and thank you to the doc shepherd for the in-depth background. Please find some comments below. Francesca 1. ----- TLS (or DTLS) version 1.2 [RFC5246] [RFC6347]. or later are REQUIRED to implement the mechanisms described in this document. FP: Does this mechanism applies to DTLS as well? The sentence above, the normative reference to DTLS 1.2, and the IANA section 8.2 would imply so. However, this is the only time DTLS is mentioned in the body of the document, excluding IANA considerations. I would like it to be made explicit that this mechanism can be used for DTLS (if that's the case) both in the abstract and in the introduction, add any useful considerations about using this mechanism with DTLS vs TLS, and possibly add a sentence in the introduction stating that DTLS 1.X uses what specified for TLS 1.X. Two examples of why that would be useful are the following sentences: using an exporter as described in Section 4 of [RFC5705] (for TLS 1.2) or Section 7.5 of [TLS13] (for TLS 1.3). For TLS 1.3, the "signature_algorithms" and "signature_algorithms_cert" extension, as described in Section 4.2.3 of [TLS13] for TLS 1.3 or the "signature_algorithms" extension from Sections 7.4.2 and 7.4.6 of [RFC5246] for TLS 1.2. which makes it clear what applies for TLS but not for DTLS. 2. ----- used to send the authenticator request SHOULD use a secure with equivalent security to TLS, such as QUIC [QUIC-TLS], as its as its FP: What are the implications of not using such a secure transport protocol? Why is it just RECOMMENDED and not MANDATED? nits: missing word "use a secure with" ; remove one of the duplicated "as its". (Note: this text appears again with the same typos for the authenticator in section 5) 3. ----- extensions (OCSP, SCT, etc.) FP: Please consider adding informative references. |
|
2021-04-04
|
14 | Francesca Palombini | [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini |
|
2021-04-03
|
14 | Erik Kline | [Ballot comment] [ sections 4 & 5 ] * "SHOULD use a secure with" -> "SHOULD use a secure communications channel with" or … [Ballot comment] [ sections 4 & 5 ] * "SHOULD use a secure with" -> "SHOULD use a secure communications channel with" or "SHOULD use a secure transport with" or something? * "as its as its" -> "as its" [ section 5.2.3 ] * I think the first sentence of the first paragraph may not be a grammatically complete sentence? [ section 7 ] * "following sections describes APIs" -> "following sections describe APIs" |
|
2021-04-03
|
14 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
|
2021-04-02
|
14 | Yaron Sheffer | Request for Telechat review by SECDIR Completed: Has Issues. Reviewer: Yaron Sheffer. Sent review to list. |
|
2021-04-01
|
14 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Yaron Sheffer |
|
2021-04-01
|
14 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Yaron Sheffer |
|
2021-03-31
|
14 | Martin Duke | [Ballot comment] - I come away from this not being entirely sure if this document applies to DTLS or not. There is the one reference … [Ballot comment] - I come away from this not being entirely sure if this document applies to DTLS or not. There is the one reference in the intro to DTLS, but it's not in the abstract, nor anywhere else. Assuming that the Sec. 1 reference is not some sort of artifact, the document would benefit from a liberal sprinkling of 's/TLS/(D)TLS' (but this would not apply to every instance) - If (D)TLS 1.2 is REQUIRED to implement, then does this document not update those RFCs? NITS: - Sec 1. I think you mean Sec 4.2.6 of RFC 8446, not 4.6.3. - Sec 4 and 5. "use a secure with..." ? - Sec 4. s/messages structures/message structures |
|
2021-03-31
|
14 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
|
2021-03-30
|
14 | Amy Vezza | Placed on agenda for telechat - 2021-04-08 |
|
2021-03-30
|
14 | Roman Danyliw | Ballot has been issued |
|
2021-03-30
|
14 | Roman Danyliw | [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw |
|
2021-03-30
|
14 | Roman Danyliw | Created "Approve" ballot |
|
2021-03-30
|
14 | (System) | Changed action holders to Roman Danyliw (IESG state changed) |
|
2021-03-30
|
14 | Roman Danyliw | IESG state changed to IESG Evaluation from Waiting for Writeup::AD Followup |
|
2021-03-30
|
14 | Roman Danyliw | Ballot writeup was changed |
|
2021-02-25
|
14 | Roman Danyliw | Please respond to remaining IETF LC feedback: https://mailarchive.ietf.org/arch/msg/last-call/pL1bBsDDrpwu2gxdcIGQQK98n6s/ |
|
2021-01-25
|
14 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
|
2021-01-25
|
14 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
|
2021-01-25
|
14 | Nick Sullivan | New version available: draft-ietf-tls-exported-authenticator-14.txt |
|
2021-01-25
|
14 | (System) | New version approved |
|
2021-01-25
|
14 | (System) | Request for posting confirmation emailed to previous authors: Nick Sullivan <nick@cloudflare.com> |
|
2021-01-25
|
14 | Nick Sullivan | Uploaded new revision |
|
2020-11-05
|
13 | Yaron Sheffer | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Yaron Sheffer. Sent review to list. |
|
2020-10-28
|
13 | Christer Holmberg | Request for Last Call review by GENART Completed: Ready. Reviewer: Christer Holmberg. Sent review to list. |
|
2020-10-21
|
13 | Roman Danyliw | Please respond to: -- Last Call Feedback: https://mailarchive.ietf.org/arch/msg/last-call/pL1bBsDDrpwu2gxdcIGQQK98n6s/ -- AD Review: https://mailarchive.ietf.org/arch/msg/tls/zX0aay5kCNDJkpMEImtFupOYPLQ/ |
|
2020-10-21
|
13 | Roman Danyliw | IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup |
|
2020-10-19
|
13 | Sabrina Tanamal | IANA Experts State changed to Expert Reviews OK |
|
2020-10-19
|
13 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
|
2020-10-16
|
13 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
|
2020-10-15
|
13 | (System) | IANA Review state changed to IANA - Not OK from Version Changed - Review Needed |
|
2020-10-15
|
13 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-tls-exported-authenticator-13. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-tls-exported-authenticator-13. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete. First, in the TLS ExtensionType Values registry on the Transport Layer Security (TLS) Extensions registry page located at: https://www.iana.org/assignments/tls-extensiontype-values/ the existing registration for: Value: 0 Extension Name: server_name with have its registration changed so that the "TLS 1.3" column will indicate: CH, EE, CR Second, in the TLS Exporter Labels registry on the Transport Layer Security (TLS) Parameters registry page located at: https://www.iana.org/assignments/tls-parameters/ three new registrations are to be made as follows: EXPORTER-server authenticator handshake context EXPORTER-client authenticator finished key EXPORTER-server authenticator finished key As this section requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK." For each of these registration requests, IANA suggests that the registration information in Section 8.2 of the current document be expanded to include information to fill out the columns "DTLS-OK" and "Recommended" in the registry. The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
|
2020-10-09
|
13 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
|
2020-10-09
|
13 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
|
2020-10-08
|
13 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Yaron Sheffer |
|
2020-10-08
|
13 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Yaron Sheffer |
|
2020-10-06
|
13 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Carlos Martínez |
|
2020-10-06
|
13 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Carlos Martínez |
|
2020-10-02
|
13 | Amy Vezza | The following Last Call announcement was sent out (ends 2020-10-16):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: sean@sn3rd.com, rdd@cert.org, … The following Last Call announcement was sent out (ends 2020-10-16):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: sean@sn3rd.com, rdd@cert.org, draft-ietf-tls-exported-authenticator@ietf.org, tls@ietf.org, Christopher Wood <christopherwood07@gmail.com>, tls-chairs@ietf.org, Sean Turner <sean@sn3rd.com> Reply-To: last-call@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-tls-exported-authenticator-13.txt> (Exported Authenticators in TLS) to Proposed Standard The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Exported Authenticators in TLS' <draft-ietf-tls-exported-authenticator-13.txt> as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-10-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a mechanism in Transport Layer Security (TLS) for peers to provide a proof of ownership of an identity, such as an X.509 certificate. This proof can be exported by one peer, transmitted out-of-band to the other peer, and verified by the receiving peer. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ No IPR declarations have been submitted directly on this I-D. |
|
2020-10-02
|
13 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
|
2020-10-02
|
13 | Amy Vezza | Last call announcement was generated |
|
2020-10-02
|
13 | Roman Danyliw | Last call was requested |
|
2020-10-02
|
13 | Roman Danyliw | IESG state changed to Last Call Requested from Publication Requested |
|
2020-10-02
|
13 | Roman Danyliw | AD Review: https://mailarchive.ietf.org/arch/msg/tls/zX0aay5kCNDJkpMEImtFupOYPLQ/ |
|
2020-09-18
|
13 | Benjamin Kaduk | Shepherding AD changed to Roman Danyliw |
|
2020-07-02
|
13 | Sean Turner | Summary Sean Turner is the DS. Ben Kaduk is the responsible AD. Exported Authenticators (EAs) provide a way for endpoints of a TLS connection to … Summary Sean Turner is the DS. Ben Kaduk is the responsible AD. Exported Authenticators (EAs) provide a way for endpoints of a TLS connection to prove ownership over multiple identities (certificates) outside of TLS. Endpoints can export authenticators to applications for transmission and verification. Mechanically, authenticators mirror certificate proofs in the TLS handshake, i.e., triggered by an authenticator (certificate) request, an endpoint can provide an authenticator response comprised of a certificate, signature, and enveloping MAC (Certificate, CertificateVerify, and Finished). Endpoints may encode requests and responses using standard TLS encoding rules for transmission at the application layer, e.g., within CERTIFICATE_REQUEST and CERTIFICATE HTTP/2 frames as specified in [1]. Authenticator MACs are computed using keys exported from the underlying TLS connection, which means that authenticators are only useful to endpoints party to that keying material. As an authentication mechanism, EAs provide an alternative to post-handshake client authentication in TLS 1.3 and renegotiation in TLS 1.2 (with the extended master secret extension). Moreover, unlike Token Binding, which is negotiated via an extension, there is little risk of endpoint non-interoperatbility due to non-compliant or extension-stripping middle boxes. EAs received formal security review from Cas Cremers and Jonathan Hoyland [2] (which in turn led to followup work in [3]). EAs guarantee compound authentication, i.e., proof of multiple separate identities, bound to a single TLS connection against an attacker without access to certificate private keys or TLS secrets. The intended status is Standards Track, given its use for HTTP/2 Secondary Certificates [1]. The document has received ample review from the WG members, as well as discussion in the httpbis working group with respect to its use in Secondary Certificates. Review and Consensus Nick presented the document several times to the WG. Over 50 emails were exchanged on the draft during its lifecycle in the WG. The group waited to move to WGLC until the security review [2] was complete. The document went through three WGLCs, with the first leading to non-trivial changes in the document before completion. (Some editorial, and some content changes that came out of the security review.) There were no objections or blocking issues during the second WGLC. The 3rd WGLC addressed changes introduced as a result of a secdir review that returned the draft to the WG. Intellectual Property The DS confirmed with the author that any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. Other Considerations EAs have been implemented by at least two independent parties. To the best of our knowledge, no browser has yet implemented the mechanism yet. [1] https://tools.ietf.org/html/draft-ietf-httpbis-http2-secondary-certs-03 [2] https://datatracker.ietf.org/meeting/101/materials/slides-101-tls-sessa-exported-authenticators-security-analysis-00.pdf [3] https://tools.ietf.org/html/draft-hoyland-tls-layered-exported-authenticator-00 |
|
2020-07-02
|
13 | Sean Turner | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
|
2020-07-02
|
13 | Sean Turner | IESG state changed to Publication Requested from AD is watching |
|
2020-07-02
|
13 | Sean Turner | Tag Revised I-D Needed - Issue raised by WG cleared. |
|
2020-07-02
|
13 | Sean Turner | IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead |
|
2020-06-26
|
13 | Nick Sullivan | New version available: draft-ietf-tls-exported-authenticator-13.txt |
|
2020-06-26
|
13 | (System) | New version approved |
|
2020-06-26
|
13 | (System) | Request for posting confirmation emailed to previous authors: Nick Sullivan <nick@cloudflare.com> |
|
2020-06-26
|
13 | Nick Sullivan | Uploaded new revision |
|
2020-06-16
|
12 | Sean Turner | Tag Revised I-D Needed - Issue raised by WG set. |
|
2020-06-16
|
12 | Sean Turner | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
|
2020-06-03
|
12 | Sean Turner | Summary Sean Turner is the DS. Ben Kaduk is the responsible AD. Exported Authenticators (EAs) provide a way for endpoints of a TLS connection to … Summary Sean Turner is the DS. Ben Kaduk is the responsible AD. Exported Authenticators (EAs) provide a way for endpoints of a TLS connection to prove ownership over multiple identities (certificates) outside of TLS. Endpoints can export authenticators to applications for transmission and verification. Mechanically, authenticators mirror certificate proofs in the TLS handshake, i.e., triggered by an authenticator (certificate) request, an endpoint can provide an authenticator response comprised of a certificate, signature, and enveloping MAC (Certificate, CertificateVerify, and Finished). Endpoints may encode requests and responses using standard TLS encoding rules for transmission at the application layer, e.g., within CERTIFICATE_REQUEST and CERTIFICATE HTTP/2 frames as specified in [1]. Authenticator MACs are computed using keys exported from the underlying TLS connection, which means that authenticators are only useful to endpoints party to that keying material. As an authentication mechanism, EAs provide an alternative to post-handshake client authentication in TLS 1.3 and renegotiation in TLS 1.2 (with the extended master secret extension). Moreover, unlike Token Binding, which is negotiated via an extension, there is little risk of endpoint non-interoperatbility due to non-compliant or extension-stripping middle boxes. EAs received formal security review from Cas Cremers and Jonathan Hoyland [2] (which in turn led to followup work in [3]). EAs guarantee compound authentication, i.e., proof of multiple separate identities, bound to a single TLS connection against an attacker without access to certificate private keys or TLS secrets. The intended status is Standards Track, given its use for HTTP/2 Secondary Certificates [1]. The document has received ample review from the WG members, as well as discussion in the httpbis working group with respect to its use in Secondary Certificates. Review and Consensus Nick presented the document several times to the WG. Over 50 emails were exchanged on the draft during its lifecycle in the WG. The group waited to move to WGLC until the security review [2] was complete. The document went through three WGLCs, with the first leading to non-trivial changes in the document before completion. (Some editorial, and some content changes that came out of the security review.) There were no objections or blocking issues during the second WGLC. The 3rd WGLC addressed changes introduced as a result of a secdir review that returned the draft to the WG. Intellectual Property The DS confirmed with the author that any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. Other Considerations EAs have been implemented by at least two independent parties. To the best of our knowledge, no browser has yet implemented the mechanism yet. [1] https://tools.ietf.org/html/draft-ietf-httpbis-http2-secondary-certs-03 [2] https://datatracker.ietf.org/meeting/101/materials/slides-101-tls-sessa-exported-authenticators-security-analysis-00.pdf [3] https://tools.ietf.org/html/draft-hoyland-tls-layered-exported-authenticator-00 |
|
2020-05-22
|
12 | Sean Turner | 3rd WGLC to ensure changes made a result of secdir review are addressed. |
|
2020-05-22
|
12 | Sean Turner | IETF WG state changed to In WG Last Call from WG Document |
|
2020-05-21
|
12 | Sean Turner | Tag Revised I-D Needed - Issue raised by WG cleared. |
|
2020-05-15
|
12 | Nick Sullivan | New version available: draft-ietf-tls-exported-authenticator-12.txt |
|
2020-05-15
|
12 | (System) | New version approved |
|
2020-05-15
|
12 | (System) | Request for posting confirmation emailed to previous authors: Nick Sullivan <nick@cloudflare.com> |
|
2020-05-15
|
12 | Nick Sullivan | Uploaded new revision |
|
2020-04-10
|
11 | Sean Turner | Document shepherd changed to Sean Turner |
|
2019-12-18
|
11 | Nick Sullivan | New version available: draft-ietf-tls-exported-authenticator-11.txt |
|
2019-12-18
|
11 | (System) | New version approved |
|
2019-12-18
|
11 | (System) | Request for posting confirmation emailed to previous authors: Nick Sullivan <nick@cloudflare.com> |
|
2019-12-18
|
11 | Nick Sullivan | Uploaded new revision |
|
2019-11-21
|
10 | Sean Turner | Tag Revised I-D Needed - Issue raised by WG set. |
|
2019-11-21
|
10 | Benjamin Kaduk | Moving back to the WG for resolution of issues raised by secdir review; may require defining new TLS message types and re-review. |
|
2019-11-21
|
10 | Benjamin Kaduk | Tag Point Raised - writeup needed cleared. |
|
2019-11-21
|
10 | Benjamin Kaduk | IETF WG state changed to WG Document from Submitted to IESG for Publication |
|
2019-11-21
|
10 | Benjamin Kaduk | IESG state changed to AD is watching::Point Raised - writeup needed from Waiting for Writeup::Point Raised - writeup needed |
|
2019-11-12
|
10 | Benjamin Kaduk | IESG state changed to Waiting for Writeup::Point Raised - writeup needed from Waiting for Writeup |
|
2019-11-04
|
10 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
|
2019-11-04
|
10 | Nick Sullivan | New version available: draft-ietf-tls-exported-authenticator-10.txt |
|
2019-11-04
|
10 | (System) | New version approved |
|
2019-11-04
|
10 | (System) | Request for posting confirmation emailed to previous authors: Nick Sullivan <nick@cloudflare.com> |
|
2019-11-04
|
10 | Nick Sullivan | Uploaded new revision |
|
2019-11-04
|
09 | Sean Turner | Changed document URLs from: [] to: repository https://github.com/tlswg/tls-exported-authenticator |
|
2019-08-26
|
09 | Gunter Van de Velde | Assignment of request for Last Call review by OPSDIR to Jon Mitchell was marked no-response |
|
2019-07-16
|
09 | Yaron Sheffer | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Yaron Sheffer. Sent review to list. |
|
2019-07-16
|
09 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
|
2019-07-16
|
09 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-tls-exported-authenticator-09. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-tls-exported-authenticator-09. If any part of this review is inaccurate, please let us know. The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete. First, in the TLS ExtensionType Values registry on the Transport Layer Security (TLS) Extensions registry page located at: https://www.iana.org/assignments/tls-extensiontype-values/ in the existing registration for: Value: 0 Extension Name: server_name the entry for TLS 1.3 will be changed from: CH, EE to: CH, EE, CR As this document requests modifications to existing registrations in a Specification Required (see RFC 8126) registry, the IESG-designated experts for the TLS ExtensionType Values have asked that you send a review request to the <tls-reg-review@ietf.org> mailing list. Expert review will need to be completed before your document can be approved for publication as an RFC. Second, in the TLS Exporter Labels registry on the Transport Layer Security (TLS) Parameters registry page located at: https://www.iana.org/assignments/tls-parameters/ three new registrations are to be made as follows: Value: EXPORTER-server authenticator handshake context DTLS-OK: Recommended: Reference: [ RFC-to-be ] Note: Value: EXPORTER-client authenticator finished key DTLS-OK: Recommended: Reference: [ RFC-to-be ] Note: Value: EXPORTER-server authenticator finished key DTLS-OK: Recommended: Reference: [ RFC-to-be ] Note: IANA Question --> What should be the entries for DTLS-OK and Recommended for each of these three new registrations? As this also requests registrations in a Specification Required (see RFC 8126) registry, the IESG-designated experts for the TLS Exporter Labels have asked that you send a review request to the <tls-reg-review@ietf.org> mailing list. Expert review will need to be completed before your document can be approved for publication as an RFC. The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
|
2019-07-16
|
09 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
|
2019-07-15
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Yaron Sheffer |
|
2019-07-15
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Yaron Sheffer |
|
2019-07-15
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jon Mitchell |
|
2019-07-15
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jon Mitchell |
|
2019-07-07
|
09 | Christer Holmberg | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Christer Holmberg. Sent review to list. |
|
2019-07-03
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
|
2019-07-03
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
|
2019-07-02
|
09 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
|
2019-07-02
|
09 | Cindy Morgan | The following Last Call announcement was sent out (ends 2019-07-16):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: draft-ietf-tls-exported-authenticator@ietf.org, christopherwood07@gmail.com, … The following Last Call announcement was sent out (ends 2019-07-16):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: draft-ietf-tls-exported-authenticator@ietf.org, christopherwood07@gmail.com, tls-chairs@ietf.org, Sean Turner <sean@sn3rd.com>, Christopher Wood <christopherwood07@gmail.com>, tls@ietf.org, kaduk@mit.edu Reply-To: ietf@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-tls-exported-authenticator-09.txt> (Exported Authenticators in TLS) to Proposed Standard The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Exported Authenticators in TLS' <draft-ietf-tls-exported-authenticator-09.txt> as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-07-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a mechanism in Transport Layer Security (TLS) to provide an exportable proof of ownership of a certificate that can be transmitted out of band and verified by the peer. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ballot/ No IPR declarations have been submitted directly on this I-D. |
|
2019-07-02
|
09 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
|
2019-07-02
|
09 | Benjamin Kaduk | Last call was requested |
|
2019-07-02
|
09 | Benjamin Kaduk | Last call announcement was generated |
|
2019-07-02
|
09 | Benjamin Kaduk | Ballot approval text was generated |
|
2019-07-02
|
09 | Benjamin Kaduk | Ballot writeup was generated |
|
2019-07-02
|
09 | Benjamin Kaduk | IESG state changed to Last Call Requested from AD Evaluation |
|
2019-05-03
|
09 | Nick Sullivan | New version available: draft-ietf-tls-exported-authenticator-09.txt |
|
2019-05-03
|
09 | (System) | New version approved |
|
2019-05-03
|
09 | (System) | Request for posting confirmation emailed to previous authors: Nick Sullivan <nick@cloudflare.com> |
|
2019-05-03
|
09 | Nick Sullivan | Uploaded new revision |
|
2019-04-18
|
08 | Benjamin Kaduk | IESG state changed to AD Evaluation from Publication Requested |
|
2019-01-31
|
08 | Christopher Wood | Summary Christopher Wood is the DS. Ben Kaduk is the responsible AD. Exported Authenticators (EAs) provide a way for endpoints of a TLS connection to … Summary Christopher Wood is the DS. Ben Kaduk is the responsible AD. Exported Authenticators (EAs) provide a way for endpoints of a TLS connection to prove ownership over multiple identities (certificates) outside of TLS. Endpoints can export authenticators to applications for transmission and verification. Mechanically, authenticators mirror certificate proofs in the TLS handshake, i.e., triggered by an authenticator (certificate) request, an endpoint can provide an authenticator response comprised of a certificate, signature, and enveloping MAC (Certificate, CertificateVerify, and Finished). Endpoints may encode requests and responses using standard TLS encoding rules for transmission at the application layer, e.g., within CERTIFICATE_REQUEST and CERTIFICATE HTTP/2 frames as specified in [1]. Authenticator MACs are computed using keys exported from the underlying TLS connection, which means that authenticators are only useful to endpoints party to that keying material. As an authentication mechanism, EAs provide an alternative to post-handshake client authentication in TLS 1.3 and renegotiation in TLS 1.2 (with the extended master secret extension). Moreover, unlike Token Binding, which is negotiated via an extension, there is little risk of endpoint non-interoperatbility due to non-compliant or extension-stripping middle boxes. EAs received formal security review from Cas Cremers and Jonathan Hoyland [2] (which in turn led to followup work in [3]). EAs guarantee compound authentication, i.e., proof of multiple separate identities, bound to a single TLS connection against an attacker without access to certificate private keys or TLS secrets. The intended status is Standards Track, given its use for HTTP/2 Secondary Certificates [1]. The document has received ample review from the WG members, as well as discussion in the httpbis working group with respect to its use in Secondary Certificates. Review and Consensus Nick presented the document several times to the WG. Over 50 emails were exchanged on the draft during its lifecycle in the WG. The group waited to move to WGLC until the security review [2] was complete. The document went through two WGLCs, with the first leading to non-trivial changes in the document before completion. (Some editorial, and some content changes that came out of the security review.) There were no objections or blocking issues during the second WGLC. Intellectual Property The DS confirmed with the author that any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. Other Considerations EAs have been implemented by at least two independent parties. To the best of our knowledge, no browser has yet implemented the mechanism yet. [1] https://tools.ietf.org/html/draft-ietf-httpbis-http2-secondary-certs-03 [2] https://datatracker.ietf.org/meeting/101/materials/slides-101-tls-sessa-exported-authenticators-security-analysis-00.pdf [3] https://tools.ietf.org/html/draft-hoyland-tls-layered-exported-authenticator-00 |
|
2019-01-31
|
08 | Christopher Wood | Responsible AD changed to Benjamin Kaduk |
|
2019-01-31
|
08 | Christopher Wood | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
|
2019-01-31
|
08 | Christopher Wood | IESG state changed to Publication Requested from I-D Exists |
|
2019-01-31
|
08 | Christopher Wood | IESG process started in state Publication Requested |
|
2019-01-31
|
08 | Christopher Wood | Summary Christopher Wood is the DS. Ben Kaduk is the responsible AD. Exported Authenticators (EAs) provide a way for endpoints of a TLS connection to … Summary Christopher Wood is the DS. Ben Kaduk is the responsible AD. Exported Authenticators (EAs) provide a way for endpoints of a TLS connection to prove ownership over multiple identities (certificates) outside of TLS. Endpoints can export authenticators to applications for transmission and verification. Mechanically, authenticators mirror certificate proofs in the TLS handshake, i.e., triggered by an authenticator (certificate) request, an endpoint can provide an authenticator response comprised of a certificate, signature, and enveloping MAC (Certificate, CertificateVerify, and Finished). Endpoints may encode requests and responses using standard TLS encoding rules for transmission at the application layer, e.g., within CERTIFICATE_REQUEST and CERTIFICATE HTTP/2 frames as specified in [1]. Authenticator MACs are computed using keys exported from the underlying TLS connection, which means that authenticators are only useful to endpoints party to that keying material. As an authentication mechanism, EAs provide an alternative to post-handshake client authentication in TLS 1.3 and renegotiation in TLS 1.2 (with the extended master secret extension). Moreover, unlike Token Binding, which is negotiated via an extension, there is little risk of endpoint non-interoperatbility due to non-compliant or extension-stripping middle boxes. EAs received formal security review from Cas Cremers and Jonathan Hoyland [2] (which in turn led to followup work in [3]). EAs guarantee compound authentication, i.e., proof of multiple separate identities, bound to a single TLS connection against an attacker without access to certificate private keys or TLS secrets. The intended status is Standards Track, given its use for HTTP/2 Secondary Certificates [1]. The document has received ample review from the WG members, as well as discussion in the httpbis working group with respect to its use in Secondary Certificates. Review and Consensus Nick presented the document several times to the WG. Over 50 emails were exchanged on the draft during its lifecycle in the WG. The group waited to move to WGLC until the security review [2] was complete. The document went through two WGLCs, with the first leading to non-trivial changes in the document before completion. (Some editorial, and some content changes that came out of the security review.) There were no objections or blocking issues during the second WGLC. Intellectual Property The DS confirmed with the author that any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. Other Considerations EAs have been implemented by at least two independent parties. To the best of our knowledge, no browser has yet implemented the mechanism yet. [1] https://tools.ietf.org/html/draft-ietf-httpbis-http2-secondary-certs-03 [2] https://datatracker.ietf.org/meeting/101/materials/slides-101-tls-sessa-exported-authenticators-security-analysis-00.pdf [3] https://tools.ietf.org/html/draft-hoyland-tls-layered-exported-authenticator-00 |
|
2019-01-24
|
08 | Christopher Wood | Summary Christopher Wood is the DS. Ben Kaduk is the responsible AD. Exported Authenticators (EAs) provide a way for endpoints of a TLS connection to … Summary Christopher Wood is the DS. Ben Kaduk is the responsible AD. Exported Authenticators (EAs) provide a way for endpoints of a TLS connection to prove ownership over multiple identities (certificates) outside of TLS. Endpoints can export authenticators to applications for transmission and verification. Mechanically, authenticators mirror certificate proofs in the TLS handshake, i.e., triggered by an authenticator (certificate) request, an endpoint can provide an authenticator response comprised of a certificate, signature, and enveloping MAC (Certificate, CertificateVerify, and Finished). Endpoints may encode requests and responses using standard TLS encoding rules for transmission at the application layer, e.g., within CERTIFICATE_REQUEST and CERTIFICATE HTTP/2 frames as specified in [1]. Authenticator MACs are computed using keys exported from the underlying TLS connection, which means that authenticators are only useful to endpoints party to that keying material. As an authentication mechanism, EAs provide an alternative to post-handshake client authentication in TLS 1.3 and renegotiation in TLS 1.2 (with the extended master secret extension). Moreover, unlike Token Binding, which is negotiated via an extension, there is little risk of endpoint non-interoperatbility due to non-compliant or extension-stripping middle boxes. EAs received formal security review from Cas Cremers and Jonathan Hoyland [2] (which in turn led to followup work in [3]). EAs guarantee compound authentication, i.e., proof of multiple separate identities, bound to a single TLS connection against an attacker without access to certificate private keys or TLS secrets. The intended status is Standards Track, given its use for HTTP/2 Secondary Certificates [1]. The document has received ample review from the WG members, as well as discussion in the httpbis working group with respect to its use in Secondary Certificates. Review and Consensus Nick presented the document several times to the WG. Over 50 emails were exchanged on the draft during its lifecycle in the WG. The group waited to move to WGLC until the security review [2] was complete. The document went through two WGLCs, with the first leading to non-trivial changes in the document before completion. (Some editorial, and some content changes that came out of the security review.) There were no objections or blocking issues during the second WGLC. Intellectual Property The DS confirmed with the author that any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. Other Considerations EAs have been implemented by at least two independent parties. No browser has yet implemented the mechanism yet. [1] https://tools.ietf.org/html/draft-ietf-httpbis-http2-secondary-certs-03 [2] https://datatracker.ietf.org/meeting/101/materials/slides-101-tls-sessa-exported-authenticators-security-analysis-00.pdf [3] https://tools.ietf.org/html/draft-hoyland-tls-layered-exported-authenticator-00 |
|
2018-12-03
|
08 | Christopher Wood | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
|
2018-11-16
|
08 | Christopher Wood | Notification list changed to Sean Turner <sean@sn3rd.com>, Christopher Wood <christopherwood07@gmail.com> from Sean Turner <sean@sn3rd.com> |
|
2018-11-16
|
08 | Christopher Wood | Document shepherd changed to Christopher A. Wood |
|
2018-11-06
|
08 | Christopher Wood | Tag Revised I-D Needed - Issue raised by WGLC cleared. |
|
2018-11-06
|
08 | Christopher Wood | IETF WG state changed to In WG Last Call from Waiting for WG Chair Go-Ahead |
|
2018-10-18
|
08 | Nick Sullivan | New version available: draft-ietf-tls-exported-authenticator-08.txt |
|
2018-10-18
|
08 | (System) | New version approved |
|
2018-10-18
|
08 | (System) | Request for posting confirmation emailed to previous authors: Nick Sullivan <nick@cloudflare.com> |
|
2018-10-18
|
08 | Nick Sullivan | Uploaded new revision |
|
2018-06-05
|
07 | Nick Sullivan | New version available: draft-ietf-tls-exported-authenticator-07.txt |
|
2018-06-05
|
07 | (System) | New version approved |
|
2018-06-05
|
07 | (System) | Request for posting confirmation emailed to previous authors: Nick Sullivan <nick@cloudflare.com> |
|
2018-06-05
|
07 | Nick Sullivan | Uploaded new revision |
|
2018-06-05
|
07 | Nick Sullivan | Uploaded new revision |
|
2018-05-29
|
06 | Sean Turner | Tag Revised I-D Needed - Issue raised by WGLC set. |
|
2018-05-29
|
06 | Sean Turner | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
|
2018-04-19
|
06 | Sean Turner | IETF WG state changed to In WG Last Call from WG Document |
|
2018-04-19
|
06 | Sean Turner | Notification list changed to Sean Turner <sean@sn3rd.com> |
|
2018-04-19
|
06 | Sean Turner | Document shepherd changed to Sean Turner |
|
2018-03-05
|
06 | Nick Sullivan | New version available: draft-ietf-tls-exported-authenticator-06.txt |
|
2018-03-05
|
06 | (System) | New version approved |
|
2018-03-05
|
06 | (System) | Request for posting confirmation emailed to previous authors: Nick Sullivan <nick@cloudflare.com> |
|
2018-03-05
|
06 | Nick Sullivan | Uploaded new revision |
|
2017-12-13
|
05 | Nick Sullivan | New version available: draft-ietf-tls-exported-authenticator-05.txt |
|
2017-12-13
|
05 | (System) | New version approved |
|
2017-12-13
|
05 | (System) | Request for posting confirmation emailed to previous authors: Nick Sullivan <nick@cloudflare.com> |
|
2017-12-13
|
05 | Nick Sullivan | Uploaded new revision |
|
2017-11-07
|
04 | Sean Turner | Added to session: IETF-100: tls Thu-0930 |
|
2017-10-30
|
04 | Nick Sullivan | New version available: draft-ietf-tls-exported-authenticator-04.txt |
|
2017-10-30
|
04 | (System) | New version approved |
|
2017-10-30
|
04 | (System) | Request for posting confirmation emailed to previous authors: Nick Sullivan <nick@cloudflare.com> |
|
2017-10-30
|
04 | Nick Sullivan | Uploaded new revision |
|
2017-07-17
|
03 | Nick Sullivan | New version available: draft-ietf-tls-exported-authenticator-03.txt |
|
2017-07-17
|
03 | (System) | New version approved |
|
2017-07-16
|
03 | (System) | Request for posting confirmation emailed to previous authors: Nick Sullivan <nick@cloudflare.com> |
|
2017-07-16
|
03 | Nick Sullivan | Uploaded new revision |
|
2017-06-20
|
02 | Nick Sullivan | New version available: draft-ietf-tls-exported-authenticator-02.txt |
|
2017-06-20
|
02 | (System) | New version approved |
|
2017-06-20
|
02 | (System) | Request for posting confirmation emailed to previous authors: Nick Sullivan <nick@cloudflare.com> |
|
2017-06-20
|
02 | Nick Sullivan | Uploaded new revision |
|
2017-06-20
|
01 | Nick Sullivan | New version available: draft-ietf-tls-exported-authenticator-01.txt |
|
2017-06-20
|
01 | (System) | New version approved |
|
2017-06-20
|
01 | (System) | Request for posting confirmation emailed to previous authors: Nick Sullivan <nick@cloudflare.com> |
|
2017-06-20
|
01 | Nick Sullivan | Uploaded new revision |
|
2017-05-18
|
00 | Sean Turner | Changed consensus to Yes from Unknown |
|
2017-05-18
|
00 | Sean Turner | Intended Status changed to Proposed Standard from None |
|
2017-05-18
|
00 | Sean Turner | This document now replaces draft-sullivan-tls-exported-authenticator instead of None |
|
2017-05-18
|
00 | Nick Sullivan | New version available: draft-ietf-tls-exported-authenticator-00.txt |
|
2017-05-18
|
00 | (System) | New version approved |
|
2017-05-18
|
00 | Nick Sullivan | Request for posting confirmation emailed to submitter and authors: Nick Sullivan <nick@cloudflare.com> |
|
2017-05-18
|
00 | Nick Sullivan | Uploaded new revision |