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

Michael Tuexen <michael.tuexen@lurchi.franken.de> Thu, 13 June 2024 11:25 UTC

Return-Path: <michael.tuexen@lurchi.franken.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B460C157931; Thu, 13 Jun 2024 04:25:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_PERMERROR=0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9LH3-fUyKD3; Thu, 13 Jun 2024 04:25:44 -0700 (PDT)
Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECD28C180B44; Thu, 13 Jun 2024 04:25:43 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2a02:c6a0:3052:202:e1d8:dfbd:4067:30b7]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id 7A41D721E2817; Thu, 13 Jun 2024 13:25:37 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\))
From: Michael Tuexen <michael.tuexen@lurchi.franken.de>
In-Reply-To: <AS4PR07MB8874F4834C60F9294D26315895C12@AS4PR07MB8874.eurprd07.prod.outlook.com>
Date: Thu, 13 Jun 2024 13:25:37 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8D32718E-6788-4602-836E-32EC9722BB0A@lurchi.franken.de>
References: <171820843899.39049.3184675366874098070@ietfa.amsl.com> <AS4PR07MB8874F4834C60F9294D26315895C12@AS4PR07MB8874.eurprd07.prod.outlook.com>
To: Magnus Westerlund <magnus.westerlund=40ericsson.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3774.600.62)
Message-ID-Hash: 3LILWYODRGVRPLYVSZH52KWAVZFNFDFF
X-Message-ID-Hash: 3LILWYODRGVRPLYVSZH52KWAVZFNFDFF
X-MailFrom: michael.tuexen@lurchi.franken.de
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tsvwg.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Paul Wouters <paul.wouters@aiven.io>, The IESG <iesg@ietf.org>, "draft-ietf-tsvwg-sctp-zero-checksum@ietf.org" <draft-ietf-tsvwg-sctp-zero-checksum@ietf.org>, "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [tsvwg] Re: Paul Wouters' Discuss on draft-ietf-tsvwg-sctp-zero-checksum-10: (with DISCUSS and COMMENT)
List-Id: Transport Area Working Group <tsvwg.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/dRXQK13w1I9TftA9dlBOK7PIuJ0>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Owner: <mailto:tsvwg-owner@ietf.org>
List-Post: <mailto:tsvwg@ietf.org>
List-Subscribe: <mailto:tsvwg-join@ietf.org>
List-Unsubscribe: <mailto:tsvwg-leave@ietf.org>

> On 13. Jun 2024, at 08:51, Magnus Westerlund <magnus.westerlund=40ericsson.com@dmarc.ietf.org> wrote:
> 
> Hi Paul,
>  I think you are correct that security considerations likely need to explicitly state that security mechanisms and the CRC32c integrity protection have a one way dependency between the mechanisms and the process to turn off the CRC32c should never impact the security solution negotiation and is never an alternative. The dependency that exist is that zero checksum has a pre-requisite that something stronger protects the packets. There should never be a dependency in the other direction.  
Just to be clear: of course, I willing to add any text to the document if it improves the
document. But I'm not sure what is needed.
I understood Pauls comment in the context of an attacker trying to perform a downgrade attack.
So are you referring to an attacker which inserts or modifies an Zero Checksum Acceptable Chunk Parameter?
This is not possible in the case of SCTP over DTLS, but might be possible in the general case.
> Secondly in WebRTC there are no alternative option to DTLS. So, if an attacker fails the DTLS handshake the whole PeerConnection establishment will fail. Also, because the whole SCTP packet is encrypted there is no way an external attacker could even know if zero-checksum was applied or not.
I agree here. This is specific to the alternate error detection method SCTP over DTLS.
But do we need to state this explicitly in this document? This only relates to
SCTP over DTLS, but not to an alternate error detection method. So think RFC 8261 is
an appropriate document for such a statement, but I am not sure if it belong in this
document.

Best regards
Michael
>  Cheers
>  Magnus
>   From: Paul Wouters via Datatracker <noreply@ietf.org>
> Date: Wednesday, 12 June 2024 at 18:07
> To: The IESG <iesg@ietf.org>
> Cc: draft-ietf-tsvwg-sctp-zero-checksum@ietf.org <draft-ietf-tsvwg-sctp-zero-checksum@ietf.org>, tsvwg-chairs@ietf.org<tsvwg-chairs@ietf.org>, tsvwg@ietf.org <tsvwg@ietf.org>
> Subject: [tsvwg] Paul Wouters' Discuss on draft-ietf-tsvwg-sctp-zero-checksum-10: (with DISCUSS and COMMENT)
> Paul Wouters has entered the following ballot position for
> draft-ietf-tsvwg-sctp-zero-checksum-10: Discuss
> 
> 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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot-positions%2F&data=05%7C02%7Cmagnus.westerlund%40ericsson.com%7C42fc8c719863435154f808dc8af9c2d0%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638538052513554079%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=dsWIk0k78sd%2Bc80qdwIGAgIbMQV6q2otQngrVNJDq0I%3D&reserved=0
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-tsvwg-sctp-zero-checksum%2F&data=05%7C02%7Cmagnus.westerlund%40ericsson.com%7C42fc8c719863435154f808dc8af9c2d0%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638538052513563148%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=wJaEeMg1BBAtq%2BVRSqPLSTxjGA9eWdJeV1ue82VCLiQ%3D&reserved=0
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Should there be a short discussion in the Security Considerations on what to do
> when DTLS fails? This could be a bid-down attack from DTLS to crc32. Perhaps
> some text that states if DTLS is configured, that if DTLS fails to establish,
> this should be a hard fail and not a soft fail to crc32 'protected' clear text?
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> NITS:
> 
>         A Virtual Network (VN) is a network provided by a service provider
>         to a customer for the customer to use in any way it wants.
> 
> I think "any way" is a bit too strong? Service providers have a lot of AUP and
> fine print.
> 
> being being received -> being received