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 the maximum values exist to define the size of the length field, not the practical limits. In this particular case, the suggested ticket formulation simply doesn't work if the ClientIdentity is too large. Good thing too, because I doubt that anyone would want a 16MB ticket. I'd put this down as HFDU instead. On Fri, Mar 7, 2025, at 20:21, Michael StJohns wrote: > https://www.rfc-editor.org/errata/eid4800 > > RFC 5077 <https://www.rfc-editor.org/rfc/rfc5077>, "Transport Layer > Security (TLS) Session Resumption without Server-Side State", January > 2008 > > I'm working through the list of errata and came across this one. > > This mechanism is obsolete in TLS1.3, but still exists in TLS1.2. > > The errata appears to be valid with respect to the wrapping length > issues of the indicated structures - (E.g. a 2^16-1 object can't > encode/wrap a 2^24-1 object). > > Someone should consider the structures defined here but carried to > TLS1.3 and verify length consistency and issue an errata if needed. > > > > If TLS1.2 is actually still live for development (and new RFCs), I'd > mark this errata as Verified. Otherwise, if TLS1.2 is obsolete (and > not just its documents), I'd mark this errata as "Rejected" as there's > nowhere to apply the errata. > > I'll leave it to the chairs of TLS to figure out which is more appropriate. > > Mike > > > > > > > > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
