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
