Hi Bas,
On 4/28/26 09:27, Bas Westerbaan wrote:
> > A corollary is that we're only as secure as the weakest variant
that the
> > server advertises while maintaining standards compliance.
>
> No, you misunderstand how TLS works.
That is possible.
I am not saying that a client can be made, absent an active attacker or
implementation bug, to negotiate an algorithm it did not offer or that
its policy rejects. My understanding of TLS 1.3 is that the client
advertises acceptable parameters, including signature algorithms,
supported groups/key shares, and cipher suites; the server selects from
the compatible overlap; and if the server cannot select an acceptable
set of parameters, the handshake fails closed.
For certificates specifically, my understanding is that the server
controls which certificate chain or chains it is able and willing to
serve, subject to CA issuance and client validation policy. The client
can validate or reject what is offered, but it cannot complete a
connection using a certificate chain or handshake signature that the
server does not provide. If there is no acceptable overlap among the
client's policy, the server's available certificate chains, and the
server's handshake-signature capabilities, the connection fails closed.
So when I said "weakest variant that the server advertises" my phrasing
was probably too imprecise or too lengthy. The point I intended was
this: the practical security floor is shaped by the weakest
conforming/acceptable variant that implementations are expected to
support and that peers can actually negotiate. That floor is not set by
verifier policy alone; it is also shaped by the standard's baseline
requirements, server implementation and configuration, CA issuance, and
client implementation and policy.
If that is still wrong, I would appreciate a pointer to the specific RFC
section that shows the model you have in mind.
> You write long e-mails, Jake.
That is a fair criticism. Part of the length of emails reflects the IETF
process putting a lot of burden on commenters without a systematic
issue-resolution format. Part of it reflects the absence of an agreed
baseline security metric for these primitives. Part of it is also on me.
Thank you for reading and engaging. I know responding to criticism is
time-consuming and often thankless.
> I think I addressed all relevant points to this WGLC.
I do not think the draft currently addresses the security-section point
I am raising: why a non-hybrid PQ signature is an acceptable
authentication baseline when hybrid/PQ-T constructions are the more
cautious baseline for key establishment and signatures. It is my
understanding that you generally agree and yet this agreement is not
reflected in the draft.
The addition of the composites draft seems like a good start but it
doesn't cover everything discussed. Could you point me to the text or
pending change that addresses that distinction? If there is no such
text, I think this remains an unresolved WGLC issue. This document could
easily become a de facto transition document and that would lead to a
less secure baseline for TLS. A warning that it MUST not become a de
facto transition document is probably a good idea for building towards
consensus.
Kind regards,
Jacob Appelbaum
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
