On Tue, Oct 24, 2023 at 06:05:27PM +, Ben Schwartz wrote:
> Hi TLS,
>
> We've just uploaded a new revision of the cTLS draft. The most
> exciting change in this revision is an additional informative
> reference to Comparse [1], a new formal verification system.
> The Comparse paper includes
On Tue, Oct 24, 2023 at 04:13:48PM +, Andrei Popov wrote:
> > So it may be necessary to have the server respond with its own flag
> > to indicate that it really does want client cert auth and isn't just
> > asking for a client cert on autopilot.
>
> An "I really mean it" flag. We can add
Hi TLS,
We've just uploaded a new revision of the cTLS draft. The most exciting change
in this revision is an additional informative reference to Comparse [1], a new
formal verification system. The Comparse paper includes a security proof of
cTLS (and also TLS and MLS). This revision also
Hi TLS,
We would like to re-introduce
https://datatracker.ietf.org/doc/draft-davidben-tls13-pkcs1/
(it's intended for the TLS WG and the Standards track, despite what the
document says at the top; we'll fix it as soon as the submission tool reopens).
In the course of TLS 1.3 deployment, it
Andrei Popov writes:
>An "I really mean it" flag. We can add these for every TLS message, not just
>authentication-related ones. Just to make sure the peer truly is serious
>about the TLS handshake.
It really depends on how servers react when they see client-cert-auth when
they're not expecting
This is similar to the case when a server is unable to use its RSA key to
sign with PSS passing (my slides for TLS WG in 2015
https://www.ietf.org/proceedings/94/slides/slides-94-tls-4.pdf , presented
by Eric), but instead this is about client keys/signatures.
I don't have a stake in this
Some changes from the last time this was posted:
- Apparently we got early codepoint allocation for this and I forgot about
it? Anyway the allocated codepoints are now in the draft.
- We've crisped up the motivation a bit.
One thing I'll call out is that the previous discussion mentioned one
On Wed, Oct 25, 2023 at 02:34:08AM +, Peter Gutmann wrote:
> Andrei Popov writes:
>
> >An "I really mean it" flag. We can add these for every TLS message, not just
> >authentication-related ones. Just to make sure the peer truly is serious
> >about the TLS handshake.
>
> It really depends
On Tue, Oct 24, 2023 at 02:40:35AM +, Peter Gutmann wrote:
> >Yes, but, arguably, such broken clients won't be fixed by adding new
> >extensions/flags/etc. If they do not comply with the simple RFC language that
> >exists, can we expect them to implement the new flag correctly?
>
> I would
Viktor Dukhovni writes:
>I don't see in your comment anything to suggest that the flag is a no-go.
Oh, it's definitely not a no-go, just pointing out that you shouldn't read too
much into seeing a cert request from a server. In other words if the client
says "I have a cert" and the server
A few comments and nits are below but I have one high level question. Why limit
the manifest produced by root programs to trust anchors? Root programs could
produce a structure that represents CA certificates and all possible partial
paths that can be validated by a trust store as well. This
> At least as a client, you can't read anything into seeing a cert request from
> the server, it's just a standard part of the handshake, like a keyex or a
> finished.
This is exactly my argument: when a client receives a cert request the client
cannot satisfy, the RFC says send an empty
> So it may be necessary to have the server respond with its own flag to
> indicate that it really does want client cert auth and isn't just asking for
> a client cert on autopilot.
An "I really mean it" flag. We can add these for every TLS message, not just
authentication-related ones. Just to
On Tue, Oct 24, 2023 at 04:11:53PM +, Andrei Popov wrote:
> > At least as a client, you can't read anything into seeing a cert request
> > from the server, it's just a standard part of the handshake, like a keyex
> > or a finished.
>
> This is exactly my argument: when a client receives a
Is the concern here errors or prompting? From the original email, it
sounded like the issue was that requesting client certificates showed
undesirable UI to human-backed clients.
That one is a bit harder to avoid since no one is acting incorrectly per
se. Clients for humans need to ask the human
On Tue, Oct 24, 2023 at 12:54:08PM -0400, David Benjamin wrote:
> Is the concern here errors or prompting? From the original email, it
> sounded like the issue was that requesting client certificates showed
> undesirable UI to human-backed clients.
My concern is errors, browser UX concerts are
On Tue, Oct 24, 2023, 13:07 Viktor Dukhovni wrote:
> On Tue, Oct 24, 2023 at 12:54:08PM -0400, David Benjamin wrote:
>
> > Is the concern here errors or prompting? From the original email, it
> > sounded like the issue was that requesting client certificates showed
> > undesirable UI to
17 matches
Mail list logo
