Hi Martin - you said:
TLS is full of this sort of thing. The point being that the maximum values
exist to define the size of the length field, not the practical limits.
In that case, since this function is obsoleted, and there's nowhere to
actually put an update to the document, I would sugg
Issues
--
* tlswg/dtls13-spec (+16/-2/š¬3)
16 issues created:
- Contributions from David Benjamin (by hannestschofenig)
https://github.com/tlswg/dtls13-spec/issues/315
- Check with Implementers (by hannestschofenig)
https://github.com/tlswg/dtls13-spec/issues/313
- Replay protect
I don't think that Verified is quite right.
It's true that the maximum possible length of a ClientIdentity doesn't fit into
the structure defined. But nor does it fit into handshake messages (though the
overflow is potentially smaller).
TLS is full of this sort of thing. The point being that
Is there a "TLS Style Guide" or something similar
that captures this? (I think I knew this as a background noise thing
as being different from how ASN1 does length field encoding...)
Look at the āpresentation languageā section of the TLS RFCs
___
TLS m
Hi,
I missed this thread, but Ericsson put a lot of effort on this topic in our
recent comments to NIST, which might be of interest for people in TLS WG:
https://emanjon.github.io/NIST-comments/2025%20-%20SP%20800-227.pdf
https://csrc.nist.gov/csrc/media/Events/2025/workshop-on-guidance-for-kem
