[TLS] Re: Errata 4800

[Michael StJohns <[e-mail]>]

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 suggest that "REJECTED" 
is correct.  I'm basing that on your comment above that this isn't 
actually a problem.  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...)

In general, I'm using Verified for "Technical - this is something that 
needs to be fixed otherwise things break."; and HFDU for Editorial - 
"This is annoying, but nothing breaks" and I think that's consistent 
with general usage of the system.  In the current case, I'm still 
working my way through errata against old or very old documents and had 
a few where there was a valid errata, but that the downstream 
(updates/obsoletes) document fixed the problem.  I've started marking 
those as "Verified" because they were a problem in the document and 
that's the state I have available in the Errata system.  I'd rather mark 
them "OBE" or "Fixed".

In the current case, if I could use any set of words,  it would probably 
be "REJECTED/OBSOLETE" given your comment, and "HFDU" if this hadn't 
been removed from TLS1.3.

Mike

ps - isn't ClientIdentity where you'd put a PQ certificate chain?  And 
aren't some of those > 64K in length?   I'm glad this has been removed 
from TLS1.3 and we don't have to go back and fix it... :-).

On 3/8/2025 3:48 AM, Martin Thomson wrote:
> 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 -- [e-mail]
>> To unsubscribe send an email to [e-mail]
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]