Re: [AVTCORE] Roman Danyliw's Discuss on draft-ietf-avtcore-cryptex-06: (with DISCUSS and COMMENT)

Roman Danyliw <rdd@cert.org> Mon, 25 July 2022 15:03 UTC

Return-Path: <rdd@cert.org>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1C5C13C21B; Mon, 25 Jul 2022 08:03:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=seicmu.onmicrosoft.com
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 Cqnybz3xQsOt; Mon, 25 Jul 2022 08:03:41 -0700 (PDT)
Received: from USG02-CY1-obe.outbound.protection.office365.us (mail-cy1usg02on0109.outbound.protection.office365.us [23.103.209.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DB97C13C210; Mon, 25 Jul 2022 08:03:40 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=UfnJdc66+6v9U7jhAfigkzGn7jcYNG5UTqhYZKdaYLD2sBIa3KTYFrHKV++0A6iYOnQ4V3Ml7BNZLjjNX5I/9TZTPZBPXFXTTKNE16xirHqhZZF/SQwCCl0sgmTtWoNQXhAMo5qJx5IXDj9zoN7GZYi00PL7TE2Bqcyn/AIkZ4FTN0z6oCkSknXI3UqYXh8KejcduZ8FRsoOqEUfBf7MMV5aweGPWyC9EcPOq8c7bEwjXLTsoOOi2DIAU+W4ED7puaxZNYYbpDdu0rAMmmQKOw8YTo0Kj6THy5u1H6HjiDKtVfB3WAPvjL3ikdRUg/cPi+gpkC+9hoeh+ORGYNztdg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=kzOp4R0emArr2wGI8XiKTgULcBpEONt644KNsJQCdZQ=; b=dhkdtKpVPt81Th6cOZcDUo1Qb+n6Jmzb8MuKWT/rUFGPx6/ofP0RglIMIR6+7QbZhm1VtRlZBRGjcQpZPteg5o4rQD2k8RlwPEc/WlOdJrAOq9gF3gcApmScC3CGbBfNR0aobRpJS1csX1Z5rl3vOXG1u4GJ5GLjOUo3jnunlM/vOzoT/h5RH6klqg8A/ZxAhQl+UE6wYlTMaV5N0RDvodE8YwsqPiIrxXm3IVM8hNdYiYm54J68K1QfD7y48p4FPCVToNBID09cVlqc5JY8Z455wwfrIvjZK/abJeZCJDiKtcnUV5iOWGROlRLybYEfw0HCl1QVs9xE/lC1pLydhQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cert.org; dmarc=pass action=none header.from=cert.org; dkim=pass header.d=cert.org; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seicmu.onmicrosoft.com; s=selector1-seicmu-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kzOp4R0emArr2wGI8XiKTgULcBpEONt644KNsJQCdZQ=; b=GyLElYqJQjzzhy5ju7Gr+MSoKQY9CvTGT9r/A/Dhnec0IvzRFC6XwKKEZo8gTjpAVDFja6j3bfBibfCYVCsWpxtqQjBdeY0MKccyN+fCqkEuRsa7UbaTfUQdZCqKdA+HnYqsXyOsx7tXbnHiWC41W5LPfQH84tGiKBRd2Tk+u+o=
Received: from BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:168::11) by BN2P110MB0993.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:16b::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5458.20; Mon, 25 Jul 2022 15:03:37 +0000
Received: from BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM ([fe80::61c5:afc3:7804:7d27]) by BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM ([fe80::61c5:afc3:7804:7d27%3]) with mapi id 15.20.5458.024; Mon, 25 Jul 2022 15:03:37 +0000
From: Roman Danyliw <rdd@cert.org>
To: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
CC: The IESG <iesg@ietf.org>, "avtcore-chairs@ietf.org" <avtcore-chairs@ietf.org>, IETF AVTCore WG <avt@ietf.org>, "draft-ietf-avtcore-cryptex@ietf.org" <draft-ietf-avtcore-cryptex@ietf.org>
Thread-Topic: [AVTCORE] Roman Danyliw's Discuss on draft-ietf-avtcore-cryptex-06: (with DISCUSS and COMMENT)
Thread-Index: AQHYgDjl1DgM4ikBM0aQwfmyJTBc661QHKIAgD9SGhA=
Date: Mon, 25 Jul 2022 15:03:37 +0000
Message-ID: <BN2P110MB11075C197BC8D2606378B9A7DC959@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM>
References: <165524346459.28356.10056151788224458199@ietfa.amsl.com> <CA+ag07Yz0PhmWNpRSVkKsVFGkOo8cuCr1iojBwC2FCOPxpDH3w@mail.gmail.com>
In-Reply-To: <CA+ag07Yz0PhmWNpRSVkKsVFGkOo8cuCr1iojBwC2FCOPxpDH3w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cert.org;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 51c17dc9-25dd-489f-1961-08da6e4eda40
x-ms-traffictypediagnostic: BN2P110MB0993:EE_
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: A34MdnNxx9vGXkXLju+nJxfHWhl5XkETBPI+bA4ulWeHM2aLsKHvq6gjiAbdqVns1uTG1feBFg6WcaVJSWfrQ+QS0J5Mna9cXgSJ1zQrgt6QeAstog0a5kXeuvO7aD4HoGzS6YrxS+GHDq1AFt1WtB5kvhBhbyZjw1i9eecvjWtz+T7ucH+Bh7XBc/6owIaAci7mnY1xEusOdTooQpzs57JotSdXpHR2Q4xI3EFk5kD3CqzlfDWNonR8TKcVPnu8PO3O8t0UVzkNX/Kb9wy12C6MgQhtj5HEzq26Lr4dcGdi892pRuptYOQ26AuDUFhZeyylT7ciwgurySVe8AX0AfNAY2A48wTgbeY2fsO1jytzojBV1v2JtCN4gyptc1FrmWbXKzxQNiprPIaGVuFBV0g6cZelqaYxYEmCTHZ2VLLOdoldQhoARqaGgdIoANXBimxEAVZbcCNBUyFaKY+0t1Ca9NXBXqgxT+0dBlB9hqCVliRYu2KLrF9mxy53BjV4BclAIIi3QecbkE/eBgVwpyMSFe3AAQGwoRu6gZwi8GMgWq1lFfbbtHmLYJ+ncb0nBZkvs7IShpof3W4savtIUd4DeclSzlUPqkB8b7axowWB4Gds2FIEzDHFl4yoy//hDq9rt/5e9VIXbYGZ2/xlK5UhHsnCs+ZVRxZTSPlY5CbSyOljN7gAXa2m7nwbjMWJZ2qQsfsAq+8Ar4RY0Xmtq5a/Y0Ek7/f4nqCQGcUGYCo3aYVfxIxOvKhlUwa+Q+rs
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230016)(366004)(122000001)(166002)(38070700005)(38100700002)(52536014)(82960400001)(8936002)(5660300002)(66446008)(55016003)(966005)(498600001)(71200400001)(2906002)(8676002)(9686003)(26005)(6916009)(83380400001)(7696005)(66946007)(6506007)(66476007)(64756008)(76116006)(66556008)(4326008)(186003)(86362001)(33656002)(53546011)(54906003); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: ZgmBgS/+SEMIeI5SWdmbryEYh+Us0jtpuleB6/94AIh+TTOE0bX9nYli62XC9IJUAMnu88iMajgoFTdNoslwb6cA9QM3QiYu5R61sZqXD8TYn0l/x/4uaA9Wa6RgWyn9LTTBTzbc3zm0IvUiVGVIDZ7sydlA1p2gv7AJJr34Bwaq7Dqegw3PqcCUmIWEurZEe50MwxAT2ufl2epvHSI5TshFBBNWGKlhezM28EAIKobeup4yp4z/zgSyiBa/etmlfSMigFqUloZO0GkxSSto2R7yc59Xd8H2OMqV4PWaD+XAQzuQ47OVWThBrXlzzJhuE9TLqlNyl06TFp3XuwfQx/1EagRiJ5kAoAKACH9zrT2073Ah5/6Zxm8P1UhCF1mBYIek1DcEpZKS0GTGN2pc9JC+cdtC07Lczt7geOAY2QM=
Content-Type: multipart/alternative; boundary="_000_BN2P110MB11075C197BC8D2606378B9A7DC959BN2P110MB1107NAMP_"
MIME-Version: 1.0
X-OriginatorOrg: cert.org
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 51c17dc9-25dd-489f-1961-08da6e4eda40
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2022 15:03:37.4172 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 95a9dce2-04f2-4043-995d-1ec3861911c6
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN2P110MB0993
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/WvlCUMt2cy953Mliixy-uIfIqCU>
Subject: Re: [AVTCORE] Roman Danyliw's Discuss on draft-ietf-avtcore-cryptex-06: (with DISCUSS and COMMENT)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jul 2022 15:03:43 -0000

Hi!

Thanks for publishing -07 and your explanations below.  It addresses my DISCUSS and COMMENT feedback.  I’ve cleared by ballot.

Regards,
Roman

From: iesg <iesg-bounces@ietf.org> On Behalf Of Sergio Garcia Murillo
Sent: Wednesday, June 15, 2022 4:05 AM
To: Roman Danyliw <rdd@cert.org>
Cc: The IESG <iesg@ietf.org>; avtcore-chairs@ietf.org; IETF AVTCore WG <avt@ietf.org>; draft-ietf-avtcore-cryptex@ietf.org
Subject: Re: [AVTCORE] Roman Danyliw's Discuss on draft-ietf-avtcore-cryptex-06: (with DISCUSS and COMMENT)

Thank you Roman for your review, please find my comments below:


On Tue, Jun 14, 2022 at 11:51 PM Roman Danyliw via Datatracker <noreply@ietf.org<mailto:noreply@ietf.org>> wrote:
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I’m having trouble understanding the relationship between this work and SRTP
without making assumptions.  Section 1.3 notes that there is a design goal to
build on top of SRTP and to have simple SRTP interactions.  Section 3 also says
the design goal is to “reuse the existing SRTP framework.”  Finally, Section
6.2 and 6.3 says ”[t]he encryption (or decryption) procedure is identical to
that of [RFC3711] except for the Encrypted Portion of the SRTP packet.”

I believe the correct read is that “do everything from SRTP unless noted as
different here”.  However, saying “encryption and description procedures" per
Sections 6.2/6.3 doesn’t capture that for me.  This leaves open questions about
key management, establish and maintaining state for cryptographic contexts, MTI
algorithms, etc.

The text would benefit from being explicit on what behavior “a=cryptex”
behavior reuses from SRTP.  I don’t believe that changes any of the expected
core mechanics.


I like the approach of adding something for stating  “do everything from SRTP unless noted as different here” so we don't forget to list something that is unchanged by cryptex.

Would changing the  titles of the "encryption and description procedures" to something like "Modifications to the encryption and description procedures" make it clearer?



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Rifaat Shekh-Yusef for the SECDIR review.

** Section 6.2.  What does the notation “_4*CC_ bytes of the ciphertext …” mean?

Is your concern about the meaning of "4*CC" or the "first bytes of the ciphertext" part?



** Section 6.2.

Implementations can rearrange a packet so that the AAD and plaintext
   are contiguous by swapping the order of the extension header and the
   CSRC identifiers, resulting in an intermediate representation of the
   form shown in Figure 2.

Where would this intermediate representation be used?

This intermediate representation will only be used in case your encryption functions do not allow streaming operations and the app needs to pass a continuous block of memory to calculate the chipertext/AAD.

To double check, this would not be put on the wire?

Correct, it won't be put on the wire


** Section 8.  On MTI/optional/default transforms, does this document want to
change anything from what was said in RFC3711?

No, we don't intend to change anything in that regard.

-- Should something be said about AES-GCM per RFC7714, especially since it was
listed as an example.

If I recall correctly we chose AES-CRT and AES-GCM for the test vectors to be able to have an AAD and a non-AAD cases covered by the tests. What do you think that should be added to the doc?

-- Assuming this document inherits the MTI transforms for SRTP, please
explicitly call out the dangers using NULL transform.

I would prefer to reference the proper section of RFC3711 instead.

** Section 8.  Does any subset of the Security Considerations of RFC3711 apply
here?

Cryptex only changes the encrypted portion, so all security considerations of RFC 3711 apply, should we state that implicitly?
https://github.com/juberti/cryptex/pull/54/files?diff=unified&w=1

Do we need to add the reference to the NULL transform also?

** A.1.  Cite AES-CTR per RFC3711.

** A.2.  Cite AES-GCM per RFC7714.

What do you think about this?
https://github.com/juberti/cryptex/pull/53/files?diff=unified&w=0


Nits
** Section 5.1.  Typo.  There is a markdown typo of “{RFC8285}}” (i.e., single
open brace) which is preventing the rendering this reference correctly in the
first sentence.

Yes, already fixed, thank you for this.

** Section 5.2. Typo. s/the the/the/

Good catch too.

Best regards
Sergio