Re: [TLS] dispatching DTLS 1.2 errata

[Achim Kraus <[e-mail]>]

Hi Sean,
Hi List,

 > Errata on obsolete RFCs should be considered according to whether the
error persists in the obsoleting RFC. ... If it does not, it should be
Rejected with an explanation that the error is corrected in the
obsoleting RFC (cited by number).

I'm not sure, but I guess, that assumes the error either persists or
is corrected in an obsoleting RFC. But of the obsoleting RFC doesn't
address it because of more fundamental changes, we need first to
decide, if such "stale" errors should be corrected or not.

If such stale errors should be corrected, then the most rejects
are wrong.

About EID 5186:

(p17 is 4.2.1 not 4.2.4)

AFAIK, for stateless implementations of 4.2.1 requires that
the HelloVerifyRequest takes both, the record sequence number
and the (handshake) message_seq from the ClientHello. The same
applies to the ServerHello

best regards
Achim






Am 20.03.24 um 05:11 schrieb Sean Turner:
> Hi! We’ve got 8 reported errata on DTLS 1.2 (RFC 6347):
> https://www.rfc-editor.org/errata_search.php?rfc=6347&rec_status=15&presentation=records
> that we, the royal we where we is the WG, need to dispatch.  By way of background, the
> IESG has the following statement about processing errata on the IETF stream:
> https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/
> Based on the IESG statement, please let me know by 3 April if you disagree with the following proposed
> resolutions:
>
> 1. https://www.rfc-editor.org/errata/eid3917
>
> Proposed dispatch: reject
> Rationale: RFC 9147 obsoletes RFC 6347 and extensions is added to the ClientHello struct (see s5.3).
>
> 2. https://www.rfc-editor.org/errata/eid4103
>
> Proposed dispatch: reject
> Rationale: RFC 9147 obsoletes RFC 6347 and HelloVerifyRequest is no longer applicable to DTLS 1.3.
>
> 3. https://www.rfc-editor.org/errata/eid5186
>
> Proposed dispatch: reject
> Rationale: RFC 9147 obsoletes RFC 6347 and the section in question was extensively revised; the offending text is removed or no longer applies.
>
> 4. https://www.rfc-editor.org/errata/eid4104
>
> Proposed dispatch: reject
> Rationale: RFC 9147 obsoletes RFC 6347and the paragraph in questions was extensively revised; the offending text is removed.
>
> 5. https://www.rfc-editor.org/errata/eid4105
>
> Proposed dispatch: reject
> Rationale: RFC 9147 obsoletes RFC 6347 and the two sections were merged into one.
>
> 6. https://www.rfc-editor.org/errata/eid4642
>
> Proposed dispatch: reject
> Rationale: RFC 9147 obsoletes RFC 6347, the field has been renamed, and the field’s explanation updated.
>
> 7. https://www.rfc-editor.org/errata/eid5903
>
> Proposed dispatch: reject
> Rationale: RFC 9147 obsoletes RFC 6347 and the paragraph in questions was extensively revised; the offending text is reworded.
>
> 8. https://www.rfc-editor.org/errata/eid5026
>
> Proposed dispatch: reject
> Rationale: RFC 9147 obsoletes RFC 6347 and the 2119-language for the length is no longer in RFC 9147.
>
> Cheers,
> spt
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls