Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

[Ilari Liusvaara]

On Wed, Apr 12, 2023 at 01:18:17AM +, Peter Gutmann wrote:
> On the subject of clarification, the update also needs to explain why PSK is
> split across two separate extensions, psk_key_exchange_modes and
> pre_shared_key, with complex and awkward reconciliation rules between then,
> and why the PSK has to be the last extension in the client hello.  I can't see
> any reason for either of those two, which in particular for the latter one
> means why would an implementation follow that apparently pointless
> requirement?  Is this codifying someone's implementation bug?  Do demons fly
> out of your nose if it's not the last extension?

For the first, I actually asked that very question during TLS 1.3
development. Psk_key_exchange_modes can appear without pre_shared_key.

As for the second, the present method of computing binders (message
truncation) requires pre_shared_key to be the last extension. While
it would be possible to design ways of computing binders without such
requirement, those methods would seem to be much more complicated.



-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

[Eric Rescorla]

On Wed, Apr 12, 2023 at 12:15 AM Ilari Liusvaara 
wrote:

> On Wed, Apr 12, 2023 at 01:18:17AM +, Peter Gutmann wrote:
> > On the subject of clarification, the update also needs to explain why
> PSK is
> > split across two separate extensions, psk_key_exchange_modes and
> > pre_shared_key, with complex and awkward reconciliation rules between
> then,
> > and why the PSK has to be the last extension in the client hello.  I
> can't see
> > any reason for either of those two, which in particular for the latter
> one
> > means why would an implementation follow that apparently pointless
> > requirement?  Is this codifying someone's implementation bug?  Do demons
> fly
> > out of your nose if it's not the last extension?
>
> For the first, I actually asked that very question during TLS 1.3
> development. Psk_key_exchange_modes can appear without pre_shared_key.
>

Yes. This is what happens in a non-resumption handshake, so that the client
can
advertise what it supports.


As for the second, the present method of computing binders (message
> truncation) requires pre_shared_key to be the last extension. While
> it would be possible to design ways of computing binders without such
> requirement, those methods would seem to be much more complicated.
>

Correct. The idea is that the binder is computed on a prefix of the CH, as
indicated
in S 4.2.11.2.

-Ekr


>
>
>
> -Ilari
>
> ___
> 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] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

[Loganaden Velvindron]

On Wed, 5 Apr 2023 at 06:32, Stephen Farrell  wrote:
>
>
> Hiya,
>
> On 05/04/2023 02:47, Sean Turner wrote:
> > A post IETF 116 bump to make sure folks get their reviews in. If you
> > look at the diffs from RFC 8446 you can see not that much has
> > changed. We will also take “I read it and it looks good” response.
>
> I looked at the diff between 8446bis-07 and 8446 and it seems
> fine to me. My only comment is that C.4 says one "SHOULD NOT
> reuse a key share" - I'd be happier if that was a "MUST NOT"
> but understand if we stick with SHOULD NOT. If there were a
> good reference showing that it's quite feasible to never
> deliberately re-use a key share, even at scale, that'd be a fine
> addition. (I don't have such a reference to offer,
> sorry;-)
>

Agreed. Overall, the document looks good.

> Cheers,
> S.
> ___
> 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

[TLS] Servers sending CA names

[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

Re: [TLS] Servers sending CA names

[Viktor Dukhovni]

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

Re: [TLS] Servers sending CA names

[Salz, Rich]

> 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

[David Benjamin]

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] [EXTERNAL] Re: Servers sending CA names

[Andrei Popov]

Windows TLS stack uses them (when available) for certificate selection. 
Schannel-based TLS servers don’t send CA names by default, but can be 
configured to do so.

Cheers,

Andrei

From: TLS  On Behalf Of David Benjamin
Sent: Wednesday, April 12, 2023 2:16 PM
To: tls@ietf.org
Subject: [EXTERNAL] 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 
mailto:ietf-d...@dukhovni.org>> 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] [EXTERNAL] Re: Servers sending CA names

[Martin Thomson]

I think that is also true for NSS, though my experience of this is not 
thorough.  As David notes, client certificates are something of a mess once you 
step outside a context where the client already knows what it should be sending.

On Thu, Apr 13, 2023, at 07:20, Andrei Popov wrote:
> Windows TLS stack uses them (when available) for certificate selection. 
> Schannel-based TLS servers don’t send CA names by default, but can be 
> configured to do so.
>
> 
> Cheers,
> 
> Andrei
> 
> *From:* TLS  *On Behalf Of * David Benjamin
> *Sent:* Wednesday, April 12, 2023 2:16 PM
> *To:* tls@ietf.org
> *Subject:* [EXTERNAL] 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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Servers sending CA names

[Peter Gutmann]

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

[Achim Kraus]

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

[Ilari Liusvaara]

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