[TLS] Intolerance for delegated credentials
Hey, We've found a server that is intolerant of our offer to use delegated credentials. This seems to run a modern nginx and TLS 1.3, but it is not producing the same handshake keys as us, so I can't tell if it supports the extension or not (as the EncryptedExtensions message is indecipherable). The TLS stack is unknown, but as it supports ARIA, CAMELLIA, and CCM_8 (!) that might narrow things down a little. Is anyone deploying delegated credentials that I'm not aware of? Or has the codepoint assignment (34) run afoul of an experiment we're not aware of? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] [re-send] draft-ietf-tls-exported-authenticator IESG review
Hello TLSWG and IESG reviewers, This is a compendium of responses to the various reviews of the document. There are a few remaining open questions to address that I hope we can resolve in this thread. I’ve compiled the changes to the document in response to the comments in Github: https://github.com/tlswg/tls-exported-authenticator/pull/74 Responses welcome! = Open questions for debate Should we define an optional API to generate the certificate_request_context? [ns] Proposed solution: no, let the application decide Should we remove the SHOULDs in Section 7, as they have little to do with interoperability? [ns] Proposed solution: leave the text as is. Are there any security issues caused by the fact that the Exported Authenticator is based on the Exporter Secret, which does not incorporate the entire transcript: 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? [ns] This is a very good question. I didn’t follow the EAP-TLS1.3 issue closely, but this does seem to imply an imperfect match with post-handshake authentication in the case of mutually authenticated connections. I would like to suggest that Jonathan Hoyland (cc'd), who did the formal analysis on the protocol, provide his input. A comment from Yaron Scheffer/Benjamin Kaduk on the IANA considerations: 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. [ns] Proposed solution: Add text to section 8.1 to clarify why the CR is being added and what restrictions there are to its use, as is done in https://github.com/tlswg/tls-exported-authenticator/pull/74. Alternate solution: Propose a new column, as done in https://github.com/tlswg/tls-exported-authenticator/pull/75 = Comments and responses Proposals to address IESG comments below are here: https://github.com/tlswg/tls-exported-authenticator/pull/74 Martin Duke (No Objection): - 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) [ns] DTLS does not explicitly define a post-handshake authentication, so not all references made sense to update, but I updated all the relevant references. - If (D)TLS 1.2 is REQUIRED to implement, then does this document not update those RFCs? [ns] It doesn’t change existing versions of (D)TLS and it is not mandatory to include this functionality, so I don’t think that it updates them. It’s a separate and optional feature built on top of TLS. In any case, the text is changed to make it explicit that this is a minimum requirement. NITS: - Sec 1. I think you mean Sec 4.2.6 of RFC 8446, not 4.6.3. [ns] It’s actually neither, it’s 4.6.2. Sec. 4.2.6 defines the extension that the client uses to advertise support for post-handshake authentication. - Sec 4 and 5. "use a secure with..." ? [ns] Added “transport” - Sec 4. s/messages structures/message structures [ns] Fixed Erik Kline's No Objection -- 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? [ns] Fixed in previous change * "as
[TLS] draft-ietf-tls-exported-authenticator IESG review
Hello TLSWG and IESG reviewers, This is a compendium of responses to the various reviews of the document. There are a few remaining open questions to address that I hope we can resolve in this thread. I’ve compiled the changes to the document in response to the comments in Github: https://github.com/tlswg/tls-exported-authenticator/pull/74 Responses welcome! Open questions for debate Should we define an optional API to generate the certificate_request_context? *Proposed solution*: no, let the application decide Should we remove the SHOULDs in Section 7, as they have little to do with interoperability? *Proposed solution*: leave the text as is. Are there any security issues caused by the fact that the Exported Authenticator is based on the Exporter Secret, which does not incorporate the entire transcript 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? This is a very good question. I didn’t follow the EAP-TLS1.3 issue closely, but this does seem to imply an imperfect match with post-handshake authentication in the case of mutually authenticated connections. I would like to suggest that Jonathan Hoyland (cc'd), who did the formal analysis on the protocol, provide his input. A comment from Yaron Scheffer/Benjamin Kaduk on the IANA considerations 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. *Proposed solution*: Add text to section 8.1 to clarify why the CR is being added and what restrictions there are to its use, as is done in https://github.com/tlswg/tls-exported-authenticator/pull/74. *Alternate solution*: Propose a new column, as done in https://github.com/tlswg/tls-exported-authenticator/pull/75 = Comments and responses Proposals to address IESG comments below are here: https://github.com/tlswg/tls-exported-authenticator/pull/74 Martin Duke (No Objection): - 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) DTLS does not explicitly define a post-handshake authentication, so not all references made sense to update, but I updated all the relevant references. - If (D)TLS 1.2 is REQUIRED to implement, then does this document not update those RFCs? It doesn’t change existing versions of (D)TLS and it is not mandatory to include this functionality, so I don’t think that it updates them. It’s a separate and optional feature built on top of TLS. In any case, the text is changed to make it explicit that this is a minimum requirement. NITS: - Sec 1. I think you mean Sec 4.2.6 of RFC 8446, not 4.6.3. It’s actually neither, it’s 4.6.2. Sec. 4.2.6 defines the extension that the client uses to advertise support for post-handshake authentication. - Sec 4 and 5. "use a secure with..." ? Added “transport” - Sec 4. s/messages structures/message structures Fixed Erik Kline's No Objection -- 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? Fixed in previous change * "as its as its" -> "as its" Fixed [ section 5
[TLS] I-D Action: draft-ietf-tls-rfc8446bis-02.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : The Transport Layer Security (TLS) Protocol Version 1.3 Author : Eric Rescorla Filename: draft-ietf-tls-rfc8446bis-02.txt Pages : 153 Date: 2021-08-23 Abstract: This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066 and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-tls-rfc8446bis-02.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-rfc8446bis-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
