Re: [TLS] Servers sending CA names
Ilari Liusvaara writes: >You mean overflow the maximum field size (64kB)? No, just the 16kB message size, so you get what should be a ~100-byte cert request that's 20-30kB long. The code assumed - and I know this is crazy talk here - that a 100-byte message would fit easily into a 16kB I/O buffer, just needed a quick mod to throw away the message in two parts rather than one. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Servers sending CA names
On Thu, Apr 13, 2023 at 02:35:50AM +, Peter Gutmann wrote: > Salz, Rich writes: > > >Is this generally used? Would things go badly if we stopped sending them? > > Just as a data point, in the SCADA world it seems to be universally ignored. > I've seen everything from servers that send a list containing every CA in > existence, so much data in that one field that it overflows the TLS maximum > message size (when queried the server admins asked what a CA name list was, > and what it was used for), to a few random CA names that don't correspond to > anything they'll accept (when queried the server admins asked what a CA name > list was, and what it was used for), to nothing at all. I've also seen plenty > of servers that send cert requests to the client without actually wanting a > cert (when queried the server admins asked what a cert request was, and what > it was used for). You mean overflow the maximum field size (64kB)? I don't think anything can deal with overflowing maximum message size, as that will cause the handshake to desync (everything afterwards will be garbage). Overflowing the field could still work if client just ignores what is in there (there is nothing after that in certificate request). And furthermore, overflowing the message would require a truly impressive number of CA certs. Even WebPKI, infamous for having lots of CAs, does not have even close to enough for that (an order of magnitude more might start coming close). -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Servers sending CA names
One purpose additional to the already mentioned selection of the "right" client certificate may be to truncate the sent client certificate path at such a CA certificate, though that certificate is already available at the server. If x509 is used at all for IoT, such a truncation may reduce the amount of data, but the list of CAs must be rather small to benefit from that effect. best regards Achim Am 12.04.23 um 22:41 schrieb Salz, Rich: Is this generally used? Would things go badly if we stopped sending them? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Servers sending CA names
Salz, Rich writes: >Is this generally used? Would things go badly if we stopped sending them? Just as a data point, in the SCADA world it seems to be universally ignored. I've seen everything from servers that send a list containing every CA in existence, so much data in that one field that it overflows the TLS maximum message size (when queried the server admins asked what a CA name list was, and what it was used for), to a few random CA names that don't correspond to anything they'll accept (when queried the server admins asked what a CA name list was, and what it was used for), to nothing at all. I've also seen plenty of servers that send cert requests to the client without actually wanting a cert (when queried the server admins asked what a cert request was, and what it was used for). The behaviour to make things work in this environment is to treat the cert request as a no-biased boolean: * No cert request present -> Proceed * Cert request present, no cert available -> Proceed * Cert request present, cert available -> Auth with whatever cert you happen to have using whatever algorithm it happens to use. So far this has produced zero complaints about things breaking. The fact that they've not received complaints from anyone else either indicates that pretty much every other implementation is doing something along similar lines. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Servers sending CA names
Chrome also uses this to filter the set of client certificates when asking the user to pick one. We also sometimes use this to figure out what intermediates to send, in cases where the server does not already have all its intermediates available. (Though this is not very reliable and OS-dependent. Client certificate deployments are a bit of a mess.) Omitting it may be fine in contexts where you expect clients to only have one possible certificate chain and that they have a priori knowledge to only send that one. That can make sense in machine-to-machine communication, and makes less sense when the client is a human that needs to make decisions about identities to use. I agree with Viktor that this isn't any more optional in TLS 1.2 than TLS 1.3. Optional and non-empty if present vs. mandatory but may be empty express the same set of states. It's just an encoding difference, motivated by extensibility and client/server symmetry, not changing client certificate expectations. On Wed, Apr 12, 2023 at 4:59 PM Viktor Dukhovni wrote: > On Wed, Apr 12, 2023 at 08:41:31PM +, Salz, Rich wrote: > > > Is this generally used? Would things go badly if we stopped sending > them? > > I take you mean sending CA names as part of a certificate request. > > https://datatracker.ietf.org/doc/html/rfc8446#section-4.3.2 > https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.4 > > Yes, many servers send a non-empty list of CA names as part of > certificate request, and some clients (notably some Java-based clients) > fail to complete the handshake if the request does not list an issuer > associated with any of the client's available certificates. > > So servers historically have been able to get away with an empty list, > hoping that the client will then send the only/default certificate it > typically has on hand (or not send any, but still continue the > handshake). > > It looks perhaps like CA name lists are "more optional" in TLS 1.3 than > they were in TLS 1.2, but this impression may be just an artefact of the > separation of the CA names to a separate extension, rather than an > actual change of expected client behaviour. > > -- > Viktor. > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Servers sending CA names
> I take you mean sending CA names as part of a certificate request. Yes, that's what I meant. >It looks perhaps like CA name lists are "more optional" in TLS 1.3 than they were in TLS 1.2 That's kind of what spurred my question. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Servers sending CA names
On Wed, Apr 12, 2023 at 08:41:31PM +, Salz, Rich wrote: > Is this generally used? Would things go badly if we stopped sending them? I take you mean sending CA names as part of a certificate request. https://datatracker.ietf.org/doc/html/rfc8446#section-4.3.2 https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.4 Yes, many servers send a non-empty list of CA names as part of certificate request, and some clients (notably some Java-based clients) fail to complete the handshake if the request does not list an issuer associated with any of the client's available certificates. So servers historically have been able to get away with an empty list, hoping that the client will then send the only/default certificate it typically has on hand (or not send any, but still continue the handshake). It looks perhaps like CA name lists are "more optional" in TLS 1.3 than they were in TLS 1.2, but this impression may be just an artefact of the separation of the CA names to a separate extension, rather than an actual change of expected client behaviour. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
