Return-Path: X-Original-To: tcpm@mail2.ietf.org Delivered-To: tcpm@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 9C19911BA866C; Tue, 21 Jul 2026 12:22:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1784661741; bh=tBSLLX2+jaUJvFFlGsqIGid29yNxvWc/n4qM0v5QNHM=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=k1vnSGGuKnnNr4FVL+xgsACBj1ZGVUPQbbdJuDq2LYfPkXbts0vnQTWPgNXO3Az3C lJvWGOEwLAOK69ohw9kq4GetKJ28rEUZNBAfFXa8+p6K6K448jUnjXcHrv5nRNy76Z 7ciYtb1jSQSxp9V1dxpfZiUzJpl2uNrfOi/czXO0= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.794 X-Spam-Level: X-Spam-Status: No, score=-2.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=hpe.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fj50Ri6yMHXi; Tue, 21 Jul 2026 12:22:21 -0700 (PDT) Received: from mx0b-002e3701.pphosted.com (mx0b-002e3701.pphosted.com [148.163.143.35]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 0B53E11BA8665; Tue, 21 Jul 2026 12:22:21 -0700 (PDT) Received: from pps.filterd (m0150245.ppops.net [127.0.0.1]) by mx0b-002e3701.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 66LIuvoP3881007; Tue, 21 Jul 2026 19:22:16 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hpe.com; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=pps0720; bh=LqkZCRQndKhvI2/sHCIqvqoMZx PMaUMHFFLoWhyprWc=; b=AdeGwfxXLJK1R4FyhTCQpl3l5bDjt83A8K310fJITh JoYaWp+G6/ETVOdZwK3M+mKaC8kVKRnpxdDcrHY5zDGJeU4a1i0L9HFvkiAQwH+O R++spOdKWLd0ubJKPEf6sOf5VX5cF78+euLOravaE70kK7MkPfLMD11H646Sm4ur YMA9pAkmmQZWO2WePMntAi2c+jbgwQSEXe7+XF07RFBRq71VlX3M8bmydwzeHkz8 sqw/QxTrk4MEMXtsOlC0TUK5UAayQyBseVJsX8DiihpUopBJaDOpudILa9dM+q6H t9eOJfFGqMm2oatKY7ZuTdmDNI5a7hXBoaN5OvQY1KmA== Received: from p1lg14879.it.hpe.com (p1lg14879.it.hpe.com [16.230.97.200]) by mx0b-002e3701.pphosted.com (PPS) with ESMTPS id 4fje8d8s7w-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 21 Jul 2026 19:22:16 +0000 (GMT) Received: from p1wg14926.americas.hpqcorp.net (unknown [10.119.18.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by p1lg14879.it.hpe.com (Postfix) with ESMTPS id 8A8D613078; Tue, 21 Jul 2026 19:22:15 +0000 (UTC) Received: from p1wg14924.americas.hpqcorp.net (10.119.18.113) by p1wg14926.americas.hpqcorp.net (10.119.18.115) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.43; Tue, 21 Jul 2026 07:21:59 -1200 Received: from p1wg14919.americas.hpqcorp.net (16.230.19.122) by p1wg14924.americas.hpqcorp.net (10.119.18.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.43 via Frontend Transport; Tue, 21 Jul 2026 07:21:59 -1200 Received: from BN1PR07CU003.outbound.protection.outlook.com (192.58.206.38) by edge.it.hpe.com (16.230.19.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.43; Tue, 21 Jul 2026 07:21:37 -1200 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=aASRUfWJ40v8cKJ8DUw5RMr6ST6xpCtcFtnSf5bMPzrXIBM7AM9DwYFHnkNtIFYhSWehDoh8VOBb88YBPSJKAuIiIoIF63pO+d7ktjT/YOHgOPiFGSSOTOUAoCh0TGyHPSeJYMzsZz/+QFIn4e331SMB3C/DCPGhjVFrns/uaCEV88gYEsz+P/VcDMmKKsqrjWz9CJexDV6wOfS7eMMahggdlgFq7DxuYKa04KM8l2eQARhP1VWRRdvaUcCXWLmOfdF6EwdGtJEqrtykwaiXVNG03yZ6s1a9vvb5IJuu47w27xT7vDVgTPrtt2AYQrt+djZC4Hn/glWo28l/62nLwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=LqkZCRQndKhvI2/sHCIqvqoMZxPMaUMHFFLoWhyprWc=; b=wsyO0eXFOhcaedlW5xykuodm5JQWffNczslAXtW+dh6W/cvtpdOodG4VBwv0cckqTw723vPmIC5UZOSLx8j+MpgL6gJtCWtNP8ANW7ovMS2MC+VF3FClSjU0H+lCmtTCPyCJg48RyhdLUp92S/Kq8ij6Sz8WsOTKUxAVzqeo638zvaSCrd5KK2OiK5ZnC38XNDwrDJml7wtnfVDcfpDO0aX3yz8GIHJFZgkIWPbKduXqhrSUrUwTOh/NSXPI8eaQg1QfI5tyU7Zwv3ivjEAc8MLVriBlE/MsNHrV93KJXWIasqq15GKQz1vDUsrFudalcd1p8NN5jYt7ocuLR2VYig== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=hpe.com; dmarc=pass action=none header.from=hpe.com; dkim=pass header.d=hpe.com; arc=none Received: from DM4PR84MB2310.NAMPRD84.PROD.OUTLOOK.COM (2603:10b6:8:51::18) by DS7PR84MB3040.NAMPRD84.PROD.OUTLOOK.COM (2603:10b6:8:9f::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.223.18; Tue, 21 Jul 2026 19:21:35 +0000 Received: from DM4PR84MB2310.NAMPRD84.PROD.OUTLOOK.COM ([fe80::f9b2:4189:25fa:bd66]) by DM4PR84MB2310.NAMPRD84.PROD.OUTLOOK.COM ([fe80::f9b2:4189:25fa:bd66%6]) with mapi id 15.21.0223.017; Tue, 21 Jul 2026 19:21:34 +0000 From: "Bonica, Ron" To: Eric Biggers , "Bonica, Ron" Thread-Topic: [tcpm] Re: draft-ietf-tcpm-tcp-ao-algs-05 early Secdir review Thread-Index: AQHdGTQZkXIYMi3+5ki7hVB7oS3CFbZ4VUn0 Date: Tue, 21 Jul 2026 19:21:34 +0000 Message-ID: References: <178460966883.196860.10656020015618112794@dt-datatracker-d4d6ff9d9-fsx7d> <2925703C-A1C3-45EF-A60F-2FA7486C38A1@lurchi.franken.de> <20260721170904.GA3237852@google.com> In-Reply-To: <20260721170904.GA3237852@google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DM4PR84MB2310:EE_|DS7PR84MB3040:EE_ x-ms-office365-filtering-correlation-id: f235cfcd-ccb3-4639-2a30-08dee75d4731 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|23010399003|38070700021|22082099003|18002099003|8096899003|10067099003|4143699003|4133799003|56012099006|3023799007|6133799003; x-microsoft-antispam-message-info: ae3BFX2ehxyNCjCovOSOAci007QKl860Guh0ouq6B9dh5a/xd+mXan1u7Pk2Do4IdebD75VNSBFetSD/4LF5qsXwO6w4e1lybaGah7B1AISIokQ1O9syE4k6E3QDKIKXUQUZY4rNBl5PD5f6DakkEfbfm8yYD7q7rS8YTk2ZSZG5w+sgYrEMurGilG2m+gJ8lncfFTa2K0ke+L95CPkZTqE6bXjPZixSFwd3DUApg9ToMSecLAabeh9P/sjADe1H9HIVquO+Z7D7k364GqMS0zwNZwLIjKHBKo+PiJpbJWccKPiAimDME668UWsF1wwV4mVHOyo4BSp2sqHXMg9yFlieGsmaesYWkcZlgiQK7/c3zZAMIvhqKZdiMQauyC/ljY/SFFsXsL4jveF5EQHRfZyhvPHhVDCkUZhUgdjLy96VjTCt1Bt3kcTG9KTNa3KgAUsHczlSq5mFP5LzlMnpfwdLf8bFqnEFJe2HPMMfIzStUooA9QHHFNw87+Xf3hoWNTdZOdTHfVdbZJ7lYpMf0x4AXGb2Tv8RJd+m1B0EU2dZlWGGUGetF5qpvCM44wQcTareMkDIebGsIrN56mBbWWXnPsDnAXaUDYOmb9snsneswjw8c8ldKx9683sglKL5bNHdxbZnp1nlB4QLFfGjUQaCKazpDyTHbJ+DFKo7qn6vro+ckDwog+g8AgP66U/8Zn2+UMJ7NFi1gmMObialo7ZaAFy5V8l3RonMgY1vbGk= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR84MB2310.NAMPRD84.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(23010399003)(38070700021)(22082099003)(18002099003)(8096899003)(10067099003)(4143699003)(4133799003)(56012099006)(3023799007)(6133799003);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?jM9QMLEhaQE65KpnZqoeCmu1QapZPsAz1HmKlnDzCkksPePG1QwkeQpVvLkl?= =?us-ascii?Q?VIQl2D1P2CM0WJzOB9cO7QvX0gMrcJiZAxcnGFsCoszP7/cMLMWmnOTq/Ex2?= =?us-ascii?Q?T+6rd3Y4Dq72OhNkm8JQpo2xLeJJlzhOJNFNH1bfwyyx8SnCaRJbmnBRi3Df?= =?us-ascii?Q?HCTzs7QQ9xJDeVqYYuW97WcOl1iOIYzcyoVuEk55DJ41cUPZuTLEchtjlDnL?= =?us-ascii?Q?eocdAXPB48uzlstpU1MKm1zYZhzrzmmjXipIjjgB4eylhW5/LY9bwFBhvjGj?= =?us-ascii?Q?E7FEDXPai5d4/mLZKSyY0LXT532P3uhF/O2Z4pzywNcp/Q59lEfNQBoFL1lU?= =?us-ascii?Q?nGEI7Qf0e4AqXyq3pdkDASOazex0e8CxidaPQuC5pVU+4w0mhCQqrZj0fUTK?= =?us-ascii?Q?wXSpQbRrV9bnMLtXq3bjPXztNgAaV/N4dGOQWMKUhqnd5sKzD3uTM1nIltpf?= =?us-ascii?Q?xf3r+HzngHxCVAutjX3w8m3uECf3wssgshfpvjcxN2lihagoG7IMSNISz54w?= =?us-ascii?Q?RR+Ax1969DxR8VxtvYyK6sg/FuAYWbTUlonaAs4dRoCetDW04/kthMqZUGwr?= =?us-ascii?Q?ZmqbxpiawrRNA7txjrQ2JxT0iebjRpEQZGNzbw/mtadVU3qKMKmlpROCM/he?= =?us-ascii?Q?z/Khy2HmCom9wZ/gh/Uu5goL9DwpBHZWo1jTtjFAi8RQaCl6k0mhVXl6jF4B?= =?us-ascii?Q?bSlVf3hv6AdiMzODb7w+cYYOz4Ac8oWLjzb/IngHLOEoex+I/X4CVc9WIuqg?= =?us-ascii?Q?u+U4mMJW1HfsnWjlSfOAOsXu4wWkEz3CC85IOS1NUeKBsmaRfp7OXM2lVXxW?= =?us-ascii?Q?rFqJFu9aMKt3ES4G/EEaRinbRgkdxEypQN3EOfZ4oA7mMi1coR656wVV6qwS?= =?us-ascii?Q?okw/OK7Men5pz89Ux1qnzsDPwZUFyHR4q+qyEXyjUEO0m35/3mMctwJy0+lL?= =?us-ascii?Q?6yLSFav3sRJrlbYSNZBfrFxjhOhR6WaI8H8LJbfRf6dR2vxBNL1V9+o7uQcq?= =?us-ascii?Q?c2qvvF+7kezz6gs2XXr26GK5QsyjR2wG6/O+N+BbFVMWFlgmDVuxfMHwED3O?= =?us-ascii?Q?1pirf82NRni4+NpGSx76YvdifKumD5E0NTmPhAXpdvvjvSvvpbqQ16AvCww6?= =?us-ascii?Q?4l9i/YvRf6dHYyHcCZK60Rc0b5S1WJklmkW4j4+NFFz/LnaebOaIq9XRTx2c?= =?us-ascii?Q?mFThZFRsu1oBFbi1p/mzZ9G/inghRYcbvbB01LbRmwaoVCjeTuiW3a8XBJOO?= =?us-ascii?Q?au2AglhdojtRYmZjilC8q3/SAms5PPW9IoATUmXmbG2l0cNI31V9k1sv+ZDU?= =?us-ascii?Q?WKSs27eMLN8AQTyRbcwBg2GCwf5iN7l7PAFCmtTQts8cpmGDHHU4kbNggNGM?= =?us-ascii?Q?iDnLvY+20a/YLH6WC81l8QsN2cY1U0IdQfE4PArf7tV60/6Px+fRh9ZO1SDV?= =?us-ascii?Q?4tlrisfbkEbFLQQl+BbSPPbSI3K5WC5fwvtVsJ2F5wbu0vM6fBQUZunEBtYA?= =?us-ascii?Q?9VWbYXcsHBQW9yCe68oxzp6X69rDF3Ky7Zr8b9epgxR5jNXSKzANNHdn/LeN?= =?us-ascii?Q?JfDhfPM/Vq4H4jEnxULQ11Zwn9BPm7jHvT61WTKo7HcJuEflByWmjhYjNXik?= =?us-ascii?Q?fmUmAKNyM7diOJkkryI+6+TOTACudc9dowdZPx4KOCSfT8cIbyAfQppIwvEb?= =?us-ascii?Q?Fe9CVoh0tXmWM9a/4H2Mm2XwSBff6OPXOIA0H4qlgU+tk4E6E+XLOloxRP1o?= =?us-ascii?Q?P3Qmf1qyGg=3D=3D?= Content-Type: multipart/alternative; boundary="_000_DM4PR84MB2310C421882AFE0D1BBCBEDDF4C22DM4PR84MB2310NAMP_" MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: kLg2ZdYVjFc/+bh6vWb/wir3cNLLynsMREzRzY96v0Zr7HQ5aldH9yUXrnbc1TbVDlITZiFvVrynNethJwnMuGoRyQ2kqhGjFnT3f8QndClUxHAr6Y2kcKiZJ3XXHnxoshURgc6Qs6charDlM9RMm9J0rI5/pmA9jtuqYsjDijdMiU9qnk2bYjWXAf4AiMgnQvucuQFzKm5uRwDcpb23ATlDO1V0xX5MUBDxbGyFQVaZDS18QC2oT4VjAYXbdPyQAZj42ET5GLF4P5zN4h7CjQKk+h16+E32KBh1oZslEEwp9tlpxGkTHYGRnarluGGaUpeiGClDLUx6qtUI+F6p5w== X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR84MB2310.NAMPRD84.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: f235cfcd-ccb3-4639-2a30-08dee75d4731 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2026 19:21:34.5109 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 34GYDfyIpZDqHWOJOlwwItocCMT6VuqBseetD4xeYjR4yFJTy76Fl532mqR5ZxFOZ7Rt3KBCWhsWvpaahK2cWw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR84MB3040 X-OriginatorOrg: hpe.com X-Proofpoint-Spam-Info: AW1haW4tMjYwNzIxMDIwMyBTYWx0ZWRfX9AlVT5u26OWb CrLqN89vgeok4bw+KIZCbYlc8ciiUaWlDZKWGMOiz9uylyWwN/9BDzKsm7M/nNNfOeF/hMOwAIe GtB7jSmQzTmxC+ncn/E1Qr/ZlAcJw/o= X-Proofpoint-GUID: AyHcb7xXN3wivrtcPUsxtxOz95uPVkl8 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNzIxMDIwMyBTYWx0ZWRfXyD47cMe2f1Eo S1H6z785ynCJ4sh7pj4v8teQGf0JqFR0ToB77Xa9hTTEgeNWmfu74Z7lveDEVKql6ccB+5WrRjW 1eqYOpbAGNOq7ov9iqCXe6e5nOSXzjUzFVtltmmfg4qn9bRu6mUSz4cb/zn/9pe7AhkE4pCs3oF 8ORGn0DXvxhmbkTHyYMk5h7RltPq05m54Chx7+jK9fX110RxzVEUQfHn85hk895hEky8OnKxVXz r/X4NW+ZUir8nQGsAae1VDFO0xF+Z1tE2djmTk5eWgnWXdGw2/cSauiXV5R+EXRJz910YaCGnlc TXvrIvJBpmpPz30rFyaVYRjr3BQhxvpnbwBUNC0e54DuFVVXKB7/qlDeiQHIn//R76sW8omqbAY 2G1z6hDeYulTa8bzH+Y4ua1z8GVq5IaAlMsN8X8Rt/f4mpPJNMwxLIZwjb7jEhVB6mr7iF5oRkN s4apaZZaxkgrWfRAG8w== X-Proofpoint-ORIG-GUID: AyHcb7xXN3wivrtcPUsxtxOz95uPVkl8 X-Authority-Analysis: v=2.4 cv=G7ss1dk5 c=1 sm=1 tr=0 ts=6a5fc6e8 cx=c_pps a=5jkVtQsCUlC8zk5UhkBgHg==:117 a=5jkVtQsCUlC8zk5UhkBgHg==:17 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=RAioF0-LDSMA:10 a=VkNPw1HP01LnGYTKEx00:22 a=gQcMVamqm3wCPoSYhaRC:22 a=6XKncaru_qjgLvANlS_8:22 a=48vgC7mUAAAA:8 a=1XWaLZrsAAAA:8 a=pGLkceISAAAA:8 a=47ieck3WT0IBEOIFdAUA:9 a=CjuIK1q_8ugA:10 a=KbKa6UiSfse0_B8W:21 a=frz4AuCg-hUA:10 a=_W_S_7VecoQA:10 X-HPE-SCL: -1 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-07-21_03,2026-07-21_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1011 bulkscore=0 spamscore=0 adultscore=0 malwarescore=0 phishscore=0 suspectscore=0 priorityscore=1501 impostorscore=0 lowpriorityscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2607210203 Message-ID-Hash: XAH7G3TPKHUEDRHUALBIZI2LLV6KYVOL X-Message-ID-Hash: XAH7G3TPKHUEDRHUALBIZI2LLV6KYVOL X-MailFrom: ronald.bonica@hpe.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tcpm.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Michael Tuexen , Brian Weis , "secdir@ietf.org" , "draft-ietf-tcpm-tcp-ao-algs.all@ietf.org" , "tcpm@ietf.org" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Btcpm=5D_Re=3A_draft-ietf-tcpm-tcp-ao-algs-05_early_Secdir_revie?= =?utf-8?q?w?= List-Id: TCP Maintenance and Minor Extensions Working Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --_000_DM4PR84MB2310C421882AFE0D1BBCBEDDF4C22DM4PR84MB2310NAMP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Regarding the first issue, Eric and Brian have much more expertise than I. = I will ask them to reach consensus and I will do whatever they recommend. Regarding the second issue, HMAC-SHA256 satisfies the requirement. When TCP= -AO uses HMAC-SHA256, it consumes 36 of the 40 option bytes available in th= e TCP headers. So, TCP support for HMAC-SHA256 will require extended TCP op= tions. Since we will have extended the TCP option field already, is there a reason= why we shouldn't skip ahead to HMAC-SHA384 or HMAC-SHA512. Is the increase= d computational cost significant? = Ron ________________________________ From: Eric Biggers Sent: Tuesday, July 21, 2026 7:09 PM To: Bonica, Ron Cc: Michael Tuexen ; Brian Weis ; secdir@ietf.org ; draft-ietf-tcpm-tcp-ao-algs= .all@ietf.org ; tcpm@ietf.org Subject: Re: [tcpm] Re: draft-ietf-tcpm-tcp-ao-algs-05 early Secdir review On Tue, Jul 21, 2026 at 08:50:29AM +0000, Bonica, Ron wrote: > Hello Brian, > Thanks for your careful review. > Two questions: > > 1. > Do you recommend that we replace the contents of draft-ietf-tcpm-tcp-ao-a= lgs-05, Section 3.1.1 with the contents draft-nayak-tcp-sha2-03, Section 3.= 1.1? Should we also replace the section title? If so, I would be happy to d= o that. FYI, earlier I recommended the separate entropy extraction step (which was concretely implemented as HKDF-SHA256-Extract + HKDF-SHA256-Expand) because TCP-AO explicitly allows the Master_Key to be an ASCII string. TCP-AO's support for ASCII strings was a mistake in my opinion, but it's perhaps too late to fix. I am however recommending that the new RFC require that the Master_Key length be at least 256 bits and give clearer guidance about choosing Master_Keys (https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/tcpm/EG9= q7Eylk2G09nMUNJ_GkYwxGWs/__;!!NpxR!isVfuwoo3Oyl_CO4fRHGZRs-NsDtqD1nzkLqSlI5= A1tfhO9P7XmZutP8gWGdbhKLbWYNNxVSvtrUg3V1hQ$ ), especially emphasizing that they should be high-entropy keys rather than human-readable passwords. Regardless, considering that it could be an ASCII string, the Master_Key might not have full entropy for its length, and the entropy might not be distributed uniformly. An entropy extraction step is the usual way to handle that and turn it into a proper cryptographic key (though sufficient entropy still needs to be present). The caveat here is that in practice HMAC seems to act as both an entropy extractor and expander simultaneously (assuming a non-adversarial entropy source, which has to be assumed here anyway, since no independent salt is available). So in practice, just doing the one-step HMAC is *probably* fine. But as I've said before, I'm just concerned that this is an informal argument and it effectively amounts to a criticism of the standard KDF design practice. Standard security proofs for HMAC assume the key is chosen uniformly at random, which isn't the case with an ASCII string. If you want to do it anyway as an optimization and for consistency with how TCP-AO uses HMAC-SHA1, I recommend finding some citations for the approach of using one-step HMAC as an extract+expand KDF. Alternatively, the support for ASCII strings could be reconsidered... Maybe it's not too late to fix? Note that support for ASCII strings in the configuration files of TCP-AO software does *not* require that the protocol itself support ASCII strings. The hex decoding, base64 decoding, etc. can be a user interface implementation detail, with the actual TCP-AO protocol implementation being passed a binary key. > 2. If we implement HMAC-SHA256 instead of HMAC-SHA384, TCP-AO will sti= ll consume 36 bytes, leaving only 4 bytes for other options. So, we will st= ill need to implement draft-bonica-tcpm-extended-options. Given that, shoul= d we implement hmac-sha256 or skip ahead to hmac-sha384 or even hmac-sha512= ? There's no cryptographic need for a 384-bit or a 512-bit MAC, though sometimes people like to use HMAC-SHA512 anyway for the (perceived) higher internal security strength. Has anyone asked for that here, though? - Eric --_000_DM4PR84MB2310C421882AFE0D1BBCBEDDF4C22DM4PR84MB2310NAMP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Folks,

Regarding the first issue, Eric and Brian have much more expertise than I. = I will ask them to reach consensus and I will do whatever they recommend.

Regarding the second issue, HMAC-SHA256 satisfies the requirement. When TCP= -AO uses HMAC-SHA256, it consumes 36 of the 40 option bytes available in th= e TCP headers. So, TCP support for HMAC-SHA256 will require extended TCP op= tions.

Since we will have extended the TCP option field already, is there a reason= why we shouldn't skip ahead to HMAC-SHA384 or HMAC-SHA512. Is the increase= d computational cost significant?

                     = ;                     &nb= sp;                     &= nbsp;                   Ron


From: Eric Biggers <ebig= gers@google.com>
Sent: Tuesday, July 21, 2026 7:09 PM
To: Bonica, Ron <ronald.bonica=3D40hpe.com@dmarc.ietf.org>
Cc: Michael Tuexen <michael.tuexen@lurchi.franken.de>; Brian W= eis <bew.stds@gmail.com>; secdir@ietf.org <secdir@ietf.org>; dr= aft-ietf-tcpm-tcp-ao-algs.all@ietf.org <draft-ietf-tcpm-tcp-ao-algs.all@= ietf.org>; tcpm@ietf.org <tcpm@ietf.org>
Subject: Re: [tcpm] Re: draft-ietf-tcpm-tcp-ao-algs-05 early Secdir = review
 
On Tue, Jul 21, 2026 at 08:50:29AM +0000, Bonica, = Ron wrote:
> Hello Brian,
> Thanks for your careful review.
> Two questions:
>
>   1.
> Do you recommend that we replace the contents of draft-ietf-tcpm-tcp-a= o-algs-05, Section 3.1.1 with the contents draft-nayak-tcp-sha2-03, Section= 3.1.1? Should we also replace the section title? If so, I would be happy t= o do that.

FYI, earlier I recommended the separate entropy extraction step (which
was concretely implemented as HKDF-SHA256-Extract + HKDF-SHA256-Expand)
because TCP-AO explicitly allows the Master_Key to be an ASCII string.

TCP-AO's support for ASCII strings was a mistake in my opinion, but it's perhaps too late to fix.  I am however recommending that the new RFC require that the Master_Key length be at least 256 bits and give clearer guidance about choosing Master_Keys
(https://urldefense.com/v3/__https://mailarchive.ietf.org/= arch/msg/tcpm/EG9q7Eylk2G09nMUNJ_GkYwxGWs/__;!!NpxR!isVfuwoo3Oyl_CO4fRHGZRs= -NsDtqD1nzkLqSlI5A1tfhO9P7XmZutP8gWGdbhKLbWYNNxVSvtrUg3V1hQ$ ),
especially emphasizing that they should be high-entropy keys rather than human-readable passwords.

Regardless, considering that it could be an ASCII string, the Master_Key might not have full entropy for its length, and the entropy might not be distributed uniformly.  An entropy extraction step is the usual way to=
handle that and turn it into a proper cryptographic key (though
sufficient entropy still needs to be present).

The caveat here is that in practice HMAC seems to act as both an entropy extractor and expander simultaneously (assuming a non-adversarial
entropy source, which has to be assumed here anyway, since no
independent salt is available).  So in practice, just doing the one-st= ep
HMAC is *probably* fine.  But as I've said before, I'm just concerned<= br> that this is an informal argument and it effectively amounts to a
criticism of the standard KDF design practice.  Standard security proo= fs
for HMAC assume the key is chosen uniformly at random, which isn't the
case with an ASCII string.

If you want to do it anyway as an optimization and for consistency with
how TCP-AO uses HMAC-SHA1, I recommend finding some citations for the
approach of using one-step HMAC as an extract+expand KDF.

Alternatively, the support for ASCII strings could be reconsidered...
Maybe it's not too late to fix?  Note that support for ASCII strings i= n
the configuration files of TCP-AO software does *not* require that the
protocol itself support ASCII strings.  The hex decoding, base64
decoding, etc. can be a user interface implementation detail, with the
actual TCP-AO protocol implementation being passed a binary key.

>   2.  If we implement HMAC-SHA256 instead of HMAC-SHA38= 4, TCP-AO will still consume 36 bytes, leaving only 4 bytes for other optio= ns. So, we will still need to implement draft-bonica-tcpm-extended-options.= Given that, should we implement hmac-sha256 or skip ahead to hmac-sha384 or even hmac-sha512?

There's no cryptographic need for a 384-bit or a 512-bit MAC, though
sometimes people like to use HMAC-SHA512 anyway for the (perceived)
higher internal security strength.  Has anyone asked for that here, though?

- Eric
--_000_DM4PR84MB2310C421882AFE0D1BBCBEDDF4C22DM4PR84MB2310NAMP_--