Re: [TLS] multi-identity support in RFC 8446
Hello Andrei - > On Mar 2, 2023, at 12:47 PM, Andrei Popov wrote: > >> I don't have details, but the NVMe/TCP specification suggests that it can >> make use of multiple PSK identities during a TLS handshake. > From my read of NVMe spec, it's one PSK/identity per TLS connection: > > "8.13.5.9 Generated PSK for TLS > When used with a non-NULL DH exchange, the DH-HMAC-CHAP protocol is able to > generate a session > key KS used to generate *a pre-shared key (PSK)* to establish a secure > channel session with the TLS protocol > between host and controller. A TLS session is concatenated to an > authentication transaction when the > SC_C indication is set to 01h in the AUTH_Negotiate message. A TLS session > should not be concatenated > to an authentication transaction if the involved host and controller are > administratively configured with *a > PSK* for use with each other. In this case, host and controller should just > establish a TLS session based on > the configured PSK." > > From the above, it looks like NVMe specifies two options: > 1.Generating PSK based on a Diffie-Hellman key exchange (as part of > DH-HMAC-CHAP protocol). > 2.Admin configuring host and controller with a PSK. > In both cases, it seems that there is one PSK/identity per host-controller > connection. > > Please correct me if I mis-interpret the NVMe spec, This is what I've been told: NVMe-TCP spec v1.0a section 3.6.1.3 (TLS PSK and PSK Identity Derivation): > In TLS 1.3 each PSK is identified by the client using a PSK > identity. Each PSK is also associated with one hash function > that shall be the same as the hash function of the selected > ciphersuite. For example, the cipher suites TLS_AES_128_GCM_SHA256 > and TLS_AES_256_GCM_SHA384 use the SHA-256 and SHA-384 hash > functions respectively. A TLS client that offers both cipher > suites shall offer two PSKs with different identities, different > hash functions, and different key material. In addition to that, each cipher suite might be used for either generated or retained PSKs. This results in a total of 4 possible PSK identities, each with different keying material. As per TLS 1.3 it's then the servers responsibility to pick one of the presented identities, and return that one with the ServerHello response. The PSK of the returned identity will then be used for the connection. Thus there is only one PSK/identity per connection. It's only the ClientHello which can/might carry several PSK identities (as outlined in RFC 8446). Note also: there is a provision in the NVMe spec to send only a single PSK identity with ClientHello: > A TLS 1.3 client implementation that only supports sending > a single PSK identity during connection setup may be required > to connect multiple times in order to negotiate cipher suites > with different hash functions. -- Chuck Lever ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] multi-identity support in RFC 8446
> I don't have details, but the NVMe/TCP specification suggests that it can > make use of multiple PSK identities during a TLS handshake. >From my read of NVMe spec, it's one PSK/identity per TLS connection: "8.13.5.9 Generated PSK for TLS When used with a non-NULL DH exchange, the DH-HMAC-CHAP protocol is able to generate a session key KS used to generate *a pre-shared key (PSK)* to establish a secure channel session with the TLS protocol between host and controller. A TLS session is concatenated to an authentication transaction when the SC_C indication is set to 01h in the AUTH_Negotiate message. A TLS session should not be concatenated to an authentication transaction if the involved host and controller are administratively configured with *a PSK* for use with each other. In this case, host and controller should just establish a TLS session based on the configured PSK." >From the above, it looks like NVMe specifies two options: 1. Generating PSK based on a Diffie-Hellman key exchange (as part of DH-HMAC-CHAP protocol). 2. Admin configuring host and controller with a PSK. In both cases, it seems that there is one PSK/identity per host-controller connection. Please correct me if I mis-interpret the NVMe spec, Cheers, Andrei -Original Message- From: TLS On Behalf Of Chuck Lever III Sent: Thursday, March 2, 2023 6:32 AM To: Peter Gutmann Cc: tls@ietf.org Subject: [EXTERNAL] Re: [TLS] multi-identity support in RFC 8446 [Some people who received this message don't often get email from chuck.le...@oracle.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > On Mar 1, 2023, at 11:29 PM, Peter Gutmann wrote: > > Chuck Lever III writes: > >> We're implementing TLSv1.3 support for PSK and note there is a >> capability in the PSK extension described in S 4.2.11 for sending a >> list of identities. We don't find support for a list of alternate >> identities implemented in user space TLS libraries such as GnuTLS or >> OpenSSL. Is there a known reason for that omission? > > If it's the same as similar locations in previous versions of TLS > where it's possible to specify a list of X instead of just an X then > it could be because no-one has any idea why you'd specify a list of X, > or what to do with it if one does turn up. There are several fields > where, in the past, we've had users ask what to do with them and it > turned out, after some testing, that the answer is "whatever you want" > because the other side pays no attention whatsoever to what's in there. I don't have details, but the NVMe/TCP specification suggests that it can make use of multiple PSK identities during a TLS handshake. -- Chuck Lever ___ TLS mailing list TLS@ietf.org https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls=05%7C01%7CAndrei.Popov%40microsoft.com%7Cb6836344b47047a1463508db1b2ae622%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638133643342690211%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=cksCXJngPspqMYcCmfRTAHwtkRxJ62O50qHTx5gdkgc%3D=0 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] multi-identity support in RFC 8446
> On Mar 1, 2023, at 11:29 PM, Peter Gutmann wrote: > > Chuck Lever III writes: > >> We're implementing TLSv1.3 support for PSK and note there is a capability in >> the PSK extension described in S 4.2.11 for sending a list of identities. We >> don't find support for a list of alternate identities implemented in user >> space TLS libraries such as GnuTLS or OpenSSL. Is there a known reason for >> that omission? > > If it's the same as similar locations in previous versions of TLS where it's > possible to specify a list of X instead of just an X then it could be because > no-one has any idea why you'd specify a list of X, or what to do with it if > one does turn up. There are several fields where, in the past, we've had > users ask what to do with them and it turned out, after some testing, that the > answer is "whatever you want" because the other side pays no attention > whatsoever to what's in there. I don't have details, but the NVMe/TCP specification suggests that it can make use of multiple PSK identities during a TLS handshake. -- Chuck Lever ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] multi-identity support in RFC 8446
On Thu, Mar 02, 2023 at 04:29:11AM +, Peter Gutmann wrote: > Chuck Lever III writes: > > >We're implementing TLSv1.3 support for PSK and note there is a capability in > >the PSK extension described in S 4.2.11 for sending a list of identities. We > >don't find support for a list of alternate identities implemented in user > >space TLS libraries such as GnuTLS or OpenSSL. Is there a known reason for > >that omission? > > If it's the same as similar locations in previous versions of TLS where it's > possible to specify a list of X instead of just an X then it could be because > no-one has any idea why you'd specify a list of X, or what to do with it if > one does turn up. There are several fields where, in the past, we've had > users ask what to do with them and it turned out, after some testing, that the > answer is "whatever you want" because the other side pays no attention > whatsoever to what's in there. If you would like to use a PSK for authentication a full handshake but also have the option of doing resumption, you would need to offer two distinct PSKs in order to ensure that a handshake would succeed. The only reasons I can think of to offer more than two would be somewhat exotic, where you are (e.g.) binding application-layer semantics to the PSK identity. -Ben ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] multi-identity support in RFC 8446
Chuck Lever III writes: >We're implementing TLSv1.3 support for PSK and note there is a capability in >the PSK extension described in S 4.2.11 for sending a list of identities. We >don't find support for a list of alternate identities implemented in user >space TLS libraries such as GnuTLS or OpenSSL. Is there a known reason for >that omission? If it's the same as similar locations in previous versions of TLS where it's possible to specify a list of X instead of just an X then it could be because no-one has any idea why you'd specify a list of X, or what to do with it if one does turn up. There are several fields where, in the past, we've had users ask what to do with them and it turned out, after some testing, that the answer is "whatever you want" because the other side pays no attention whatsoever to what's in there. Two that spring to mind are cert requests from the server, which some servers send out for every connection even though they don't actually want a cert from the client and get very surprised if one turns up (the user's comment on this was that no other software they'd used had an issue with this, which implied that exactly zero implementations actually paid any attention to it), and CA name lists, which some servers fill up with every CA name they've ever heard of with the server not actually caring which CA gets used, assuming they even care whether they get a response to the cert request. This actually extends to all of the other fields in the cert request as well, since the client typically has one single certificate to auth with and sends it, take-it-or-leave-it, without bothering to check whether it's in the server's long list of approved signature, hash, and CA names. Again, from interop testing, if you get a cert request from the server and have a cert you use it, if not you don't, and no server we could find ever complained about it. So the entire extension is in effect one of those zero-length signalling ones, telling the client "auth with a cert if you've got one, otherwise just keep going as if nothing had happened". Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] multi-identity support in RFC 8446
Hi Chuck, > A quick browse of other sections of RFC 8446 does not show a similar > capability for sending multiple certificates. This can be done using TLS 1.3 post-handshake client auth (https://www.rfc-editor.org/rfc/rfc8446#section-4.2.6). However, this is an optional TLS 1.3 feature and you may find that support for it among TLS stacks is either lacking or disabled by default. E.g., Windows TLS stack supports post-handshake client auth, but I don't think Chromium does. Cheers, Andrei -Original Message- From: TLS On Behalf Of Chuck Lever III Sent: Wednesday, March 1, 2023 6:44 AM To: tls@ietf.org Subject: [EXTERNAL] [TLS] multi-identity support in RFC 8446 [Some people who received this message don't often get email from chuck.le...@oracle.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Hi- We're implementing TLSv1.3 support for PSK and note there is a capability in the PSK extension described in S 4.2.11 for sending a list of identities. We don't find support for a list of alternate identities implemented in user space TLS libraries such as GnuTLS or OpenSSL. Is there a known reason for that omission? Are there any planned changes in this area coming soon? A quick browse of other sections of RFC 8446 does not show a similar capability for sending multiple certificates. We don't have a reason to need this yet, but would like our implementation to be prepared if such a capability were to be on the horizon. Did I misread the RFC? -- Chuck Lever ___ TLS mailing list TLS@ietf.org https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls=05%7C01%7CAndrei.Popov%40microsoft.com%7C1b3998c595b04c513bb808db1a636bd4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638132786607881637%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=VVjbauuSNgsMxuB2M4KkXVghXD1TxoSv%2BWfDtNDOB9k%3D=0 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] multi-identity support in RFC 8446
Hi- We're implementing TLSv1.3 support for PSK and note there is a capability in the PSK extension described in S 4.2.11 for sending a list of identities. We don't find support for a list of alternate identities implemented in user space TLS libraries such as GnuTLS or OpenSSL. Is there a known reason for that omission? Are there any planned changes in this area coming soon? A quick browse of other sections of RFC 8446 does not show a similar capability for sending multiple certificates. We don't have a reason to need this yet, but would like our implementation to be prepared if such a capability were to be on the horizon. Did I misread the RFC? -- Chuck Lever ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
