Hi Eric and Eliot,
To clarify: My framework is not content-related.
I am not proposing 'how' to design a protocol. I am proposing that the
RFC series requires a specific structural integrity (modularity, stable
labeling, and Testsuites according to ISO 9646 to verify audit-ability)
to remain operational.
If the RSWG defines the 'vehicle' (the RFC), it must define the
structural container that ensures the series can be managed, audited,
and maintained across all streams. Leaving this to individual stream
preference is what led us to the current namespace crisis.
R's,
Timo
Am 18.05.26 um 08:20 schrieb Timo Gerke:
Hi Eric,
To be clear: TLS was merely an illustrative example, not a specific
protocol proposal for the TLS WG.
The goal of this discussion is the Policy and Architecture of the STD
series as a whole. Whether it's TLS, IPsec, or BGP—the requirement for a
modular, audit-ready structure remains the same.
Let's focus on the Blueprint (Points 1–5) and how we prevent the
namespace collapse, rather than getting lost in the implementation
details of a single example.
Regards,
Timo
Am 17.05.26 um 23:21 schrieb Eric Rescorla:
I agree with those who have observed that this is out of scope for RSWG.
With that said, I also don't think that this proposal really addresses
the issues with mapping specifications onto RFCs. In particular,
the proposed restructuring of TLS 1.3 would not really be an
improvement.
On Sun, May 17, 2026 at 6:07 AM Timo Gerke <[email protected]
<mailto:[email protected]>> wrote:
Part 1: Core Specification (Algorithm-agnostic Handshake/State
Machine)
Parts 2–5: Mandatory Crypto Modules (Key Exchange, Signatures,
etc.)
I don't see how this would really work, for several reasons:
1. The vast majority of the complexity in 8446 is in what you're calling
the "core specification", with the actual algorithm specifications being
comparatively short.
2. It's much easier to understand 8446 if you have some sense
of how the key establishment works.
3. The distinction between Mandatory and Optional isn't really
that interesting from the perspective of understanding the
specification and we sometimes move algorithms from one
category to another.
Parts 6–8: Optional Extension Modules (ECH, SNI, etc.)
And what if there are > 3 modules?
Part 9: Strict Compliance Profile (SCP) (Test Vectors and
Environments for Parts 1 to 5, chapter-separated)
Part 10: Extended Compliance Profile (ECP) (Test Vectors and
Environments for Parts 6 to , chapter-separated)
Parts 11-18 modules mot defined yet
Part 19 Test Vektor and Environments for modules 11-18
Having the modules and test vectors interlaced like this seems
like a mess.
--
Timo Gerke
Lohkoppelweg 40
22529 Hamburg
Germany
Fon: +49-40-24433033
Fax: +49-40-22628453
If you think technology can solve your security problems,
then you don't understand the problems and you don't
understand the technology.
Bruce Schneier, amerikanischer Kryptograph
--
rswg mailing list -- [email protected]
To unsubscribe send an email to [email protected]
