[tsvwg] Re: Deb Cooley's Discuss on draft-ietf-tsvwg-sctp-zero-checksum-10: (with DISCUSS and COMMENT)

[Deb Cooley <[e-mail]>]

This is perfect.  I have cleared my discuss.

Thank you for your consideration,

Deb Cooley

On Tue, Jun 18, 2024 at 2:48 PM <[e-mail]> wrote:

> > On 12. Jun 2024, at 00:27, Deb Cooley <[e-mail]> wrote:
> >
> > That addition to the Security Considerations works for me.
> >
> > If this work continues, we can have the debate on the aside then.
> >
> > Thank you.  When I see the update, I will clear my discuss.
> Hi Deb,
>
> since I have not seen any further correspondence, I updated the
> document. It should address your concern, but does not address
> Paul's issue (waiting for an answer from him).
>
> Best regards
> Michael
> >
> > Deb
> >
> > On Tue, Jun 11, 2024 at 3:55 PM <[e-mail]> wrote:
> > > On 11. Jun 2024, at 20:18, Deb Cooley <[e-mail]> wrote:
> > >
> > > I'm certainly not arguing that CRC32c is the best integrity mechanism
> ever, because it isn't.  This draft has basically allowed its removal
> because there is something better protecting the integrity of the data.
> There needs to be something written in the Security Considerations about
> that.  Even if it is to reference the requirements in Section 3 with a
> short rationale.  Or it can reference the part of the IANA section where
> the requirements are listed, again with a short rationale.  It doesn't have
> to be long, and it can reference the requirements you already specified.
> > OK. What about using:
> >
> > <section>
> > <name>Security Considerations</name>
> > <t>This document does not change the considerations given in
> > <xref target="RFC9260"/>.</t>
> > <t>Using an alternate error detection method provides an equal or better
> level
> > of data integrity than the one provided by using the CRC32c checksum
> algorithm
> > due to the first requirement of alternate error detection methods.
> > The second requirement of alternate error detection methods ensures that
> the
> > existence of middleboxes expecting correct CRC32c checksums does not
> result in
> > permanent path failures.</t>
> > </section>
> >
> > This also deals with the second requirement. Does this address your
> concern?
> > >
> > > An aside:  As for tunnels vs auth modes, is it even possible to meet
> the two requirements with an authentication mode, where the packet is not
> obscured from any device between sender and recipient?  I suspect that the
> answer is 'no'.
> > The answer is 'yes'.
> > But the focus on this document is the define the framework and provide
> one
> > (the most important one in my personal opinion) alternate error
> detection method.
> > If another one (based on the AUTH, CRYPTO, or DTLS chunk) will be
> defined, the
> > method to avoid permanent path failures needs to be defined. But this is
> not
> > needed for SCTP over DTLS.
> > Which one of these methods will be defined, or even if one additional
> method
> > at all will be defined, depends on how the work on securing SCTP traffic
> in
> > TSVWG will continue. This is not clear to me yet, since IPRs are involved
> > on the CRYTO and DTLS chunks...
> >
> > Best regards
> > Michael
> > >
> > > Deb
> > >
> > >
> > >
> > > On Fri, Jun 7, 2024 at 5:02 PM Michael Tuexen <
> [e-mail]> wrote:
> > >> On 7. Jun 2024, at 20:47, Deb Cooley <[e-mail]> wrote:
> > >>
> > >> Are the only two options DTLS or SCTP AUTH?  If so, the draft doesn't
> make
> > >> that clear.
> > > The only option currently being defined is SCTP over DTLS. One
> additional
> > > could be based on SCTP AUTH, but that will require additional details
> for
> > > dealing with middleboxes expecting correct CRC32c checksums. This is
> > > described in the document. Other additional method could be based on
> the
> > > DTLS or CRYPTO chunk, currently being proposed by Ericsson. However,
> these
> > > would also need some mechanisms to deal with middleboxes.
> > > Since these mechanisms are not required for SCTP over DTLS (the
> middleboxes
> > > don't see the CRC32c at all), and this might be the largest deployment
> > > scenario (WebRTC), this is left to the document describing such an
> > > alternate error detection method.
> > >
> > > Best regards
> > > Michael
> > >>
> > >> Deb
> > >>
> > >> On Fri, Jun 7, 2024 at 1:28 PM Michael Tuexen <
> > >> [e-mail]> wrote:
> > >>
> > >>>> On 7. Jun 2024, at 16:58, Deb Cooley via Datatracker <
> [e-mail]>
> > >>> wrote:
> > >>>>
> > >>>> Deb Cooley has entered the following ballot position for
> > >>>> draft-ietf-tsvwg-sctp-zero-checksum-10: Discuss
> > >>> Hi Deb,
> > >>>
> > >>> thanks for the review. Please see my responses in-line.
> > >>>
> > >>> Best regards
> > >>> Michael
> > >>>>
> > >>>> When responding, please keep the subject line intact and reply to
> all
> > >>>> email addresses included in the To and CC lines. (Feel free to cut
> this
> > >>>> introductory paragraph, however.)
> > >>>>
> > >>>>
> > >>>> Please refer to
> > >>>
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> > >>>> for more information about how to handle DISCUSS and COMMENT
> positions.
> > >>>>
> > >>>>
> > >>>> The document, along with other ballot positions, can be found here:
> > >>>>
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-zero-checksum/
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> ----------------------------------------------------------------------
> > >>>> DISCUSS:
> > >>>>
> ----------------------------------------------------------------------
> > >>>>
> > >>>> Currently Section 9 says roughly that there are no changes to the
> > >>> Security
> > >>>> Considerations to RFC 9260.  I have two comments:
> > >>>>
> > >>>> 1.  Since this draft is proposing to remove an integrity mechanism
> in
> > >>> SCTP,
> > >>>> there should be an update to the paragraph in RFC9260 Security
> > >>> Considerations,
> > >>>> specifically 12.2.2.  Protecting against Data Corruption in the
> Network
> > >
> > >
> >
>
>