Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBAE3A16C2 for ; Thu, 23 Apr 2020 01:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=6JdRXv0M; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=6JdRXv0M Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b13mlElJDcxb for ; Thu, 23 Apr 2020 01:11:33 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2049.outbound.protection.outlook.com [40.107.22.49]) (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 8A8FE3A16C4 for ; Thu, 23 Apr 2020 01:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3DMa9lqRmQtZvNWDjHMU83fpcZbL5SIEXhQWGqVMvmk=; b=6JdRXv0MXq5sTrxfa2J2KPCcPqKW0jWcEdAeiBr8/u9rtH+HFJgf8KBEY+5KR8pwqGgffiZk+1ZSjMHekwZ/dpxnfnehu0Ll0HgzErIVRxIJlzb02HxOiZvrHGShCjzD86HQrsBvHTJH9g94j0HSqwz+ZwwShcZdMqCnJMVTFTY= Received: from AM6PR08CA0040.eurprd08.prod.outlook.com (2603:10a6:20b:c0::28) by AM7PR08MB5461.eurprd08.prod.outlook.com (2603:10a6:20b:10e::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Thu, 23 Apr 2020 08:11:30 +0000 Received: from AM5EUR03FT010.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:c0:cafe::1c) by AM6PR08CA0040.outlook.office365.com (2603:10a6:20b:c0::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Thu, 23 Apr 2020 08:11:30 +0000 Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT010.mail.protection.outlook.com (10.152.16.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.18 via Frontend Transport; Thu, 23 Apr 2020 08:11:29 +0000 Received: ("Tessian outbound 43fc5cd677c4:v53"); Thu, 23 Apr 2020 08:11:29 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: d4784a29477cc743 X-CR-MTA-TID: 64aa7808 Received: from 2bc1dac5af49.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 5B4F2047-CEBB-4B7D-BC87-FEF12BB408ED.1; Thu, 23 Apr 2020 08:11:24 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 2bc1dac5af49.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 23 Apr 2020 08:11:24 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=feZmwZA/890uz6SbkutT7oYHX1F3nV6HxZUMIaCBlaoZlivqPiIfgkVxZbO8ajWVkLbiPW84QBwO4eoA0Y2GRzBX58Q3fuJ6a8CUZ6t4krf8/UiXXRYa9K7uQLexTjmZblyCbWYTGex7DmhWfcUgmPOHLP8f084XG9dJRBVr6HH8Pl21mvfPFBWVA3aUZU4M+FBzk1dGaorEHMo4FGsSWYDoGfdugNGMeuwpr0g4te7QNZdoQdu2ZFlvtRZySkKNlfMXABtVIXfnW500NV4V4xKIp7Fj8KhKeH5IxToel2IQoML0/6hDTgoX8mGzUUtie68I5ByMkZpfSw/wTYCdhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3DMa9lqRmQtZvNWDjHMU83fpcZbL5SIEXhQWGqVMvmk=; b=a6NoAieY/9V9CEf+qwQboNMa9My+ZbFIlTserr+tcHMpFPHmPBdRxPKENu9sOTJM/LAQoQ2Jk8TDoITJ27ZjZVY0z9vniNJdqNLmoTw4gwGEY/5+G4ulx9rK46zotgkmSUrP4meavl8/hv7RHH/k1Q2kNs/MsDLBHackvyz7qjPJWcif8CU8Tttyb/vpgvWk/G2mes9Cppb8qgC0nsxLnCBVd3VFrkPlJCTuEo9F7XQ3rAZr9bfxFChksto2pxMmIwon94EticFNMVypUkA4mJO4RWu44xl8TnwGilDTMWjC8x8OV9d7J0KYeSc4M+WQ+TCmYgq3XAMO2Lxf4mO8qQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3DMa9lqRmQtZvNWDjHMU83fpcZbL5SIEXhQWGqVMvmk=; b=6JdRXv0MXq5sTrxfa2J2KPCcPqKW0jWcEdAeiBr8/u9rtH+HFJgf8KBEY+5KR8pwqGgffiZk+1ZSjMHekwZ/dpxnfnehu0Ll0HgzErIVRxIJlzb02HxOiZvrHGShCjzD86HQrsBvHTJH9g94j0HSqwz+ZwwShcZdMqCnJMVTFTY= Received: from AM6PR08MB3318.eurprd08.prod.outlook.com (2603:10a6:209:45::15) by AM6PR08MB3735.eurprd08.prod.outlook.com (2603:10a6:20b:81::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.25; Thu, 23 Apr 2020 08:11:23 +0000 Received: from AM6PR08MB3318.eurprd08.prod.outlook.com ([fe80::1579:b7d9:f543:200d]) by AM6PR08MB3318.eurprd08.prod.outlook.com ([fe80::1579:b7d9:f543:200d%5]) with mapi id 15.20.2937.012; Thu, 23 Apr 2020 08:11:23 +0000 From: Hanno Becker To: Martin Thomson , 'Eric Rescorla' CC: "" Thread-Topic: [TLS] DTLS 1.3 AEAD additional data Thread-Index: AQHWF+iN1gKILcDltkmRr5OfopCaAaiD3VMAgAB8FQCAAE7VmIAAawyAgAAHdS6AAB8+AIAACQCRgACPx4CAABkpAIAABDCAgAAC0ICAAEL8/IAAHxqAgAAFja4= Date: Thu, 23 Apr 2020 08:11:22 +0000 Message-ID: References: <8371994b-799c-4196-a3cd-4b0f71e24b5e@www.fastmail.com> <5b74a840-a1cd-4b5b-a0c5-65320b851325@www.fastmail.com> , <1e6201d6-a078-4137-898d-d1554c22aa10@www.fastmail.com> In-Reply-To: <1e6201d6-a078-4137-898d-d1554c22aa10@www.fastmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com; x-originating-ip: [86.177.220.146] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 88eef4a2-50ad-43ab-0038-08d7e75ded58 x-ms-traffictypediagnostic: AM6PR08MB3735:|AM7PR08MB5461: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:10000; x-forefront-prvs: 03827AF76E X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB3318.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(39860400002)(376002)(346002)(136003)(366004)(19627405001)(5660300002)(9686003)(55016002)(478600001)(966005)(33656002)(52536014)(7696005)(86362001)(4326008)(186003)(81156014)(6506007)(2906002)(64756008)(316002)(66946007)(66556008)(66446008)(66476007)(8676002)(8936002)(71200400001)(76116006)(110136005)(26005); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 8S8CKwbucnk+zWnME5n99R7UN4hs9VojJw0t4BbU+vUSYB6lxITnLwl46UDWsMSTv77mOIo6LmaAH16iHfHNRPOaBWjDbJhtiYSFNiF4N1ElhNrE9OVDmSH0uU6fyGkHJVhm0PT6XqtOmg9PmLLlcbxalBGD335CsDvwoZWW4mrkL0Zx5PjAT46MU76yPiRG710SXmZX7ne07kD8f+Fw6unju/P51xFxDz5rz9AuD635IqQwLycn1wmsmjpUXqZcj4S75EeaMNpqIqqGoCWd3stUVC4mt4Cp/5+yUDZx7TOGcbPBaQYo8h+IdjWNNedqkAWAYlSFpcidsa8sQ8iLKxdZ4qD/LO3Uz4QTVnieKhJgIwbRJ+91KGzQSK9Dm936zkzGcngOeXSHLeG4S6i5pIzwunnJ7CbtLwRllkm1gnYXRs3T050miwkGriN7N8fkPzq/THIj2flUQbvJsqxk2ptY0V4hm5AQtNJmJMFevE/RJ68Jl5KObSuE0rRgGQeiC7UmorooM3YoBSqkd7nrKg== x-ms-exchange-antispam-messagedata: Dd5+6OJaXRJM8l9H+rOzg0y2ILO2dLhM8oB9EPX6LR61jdxxYRhMQCqiWNUM6/Zg0FeSj5KLDlql5fMBZajlt9nq4DwLuYYkl+ZVd7KQQvNqevHhfmXL8EhgXr2J5HDA/NPVyPLVNCeciMSTc1oY+A== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM6PR08MB33189D58D3342BCD68D91F299BD30AM6PR08MB3318eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3735 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT010.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(39860400002)(346002)(376002)(46966005)(186003)(47076004)(7696005)(9686003)(966005)(81156014)(336012)(5660300002)(8936002)(19627405001)(55016002)(26005)(33656002)(6506007)(478600001)(316002)(110136005)(2906002)(82310400002)(356005)(81166007)(82740400003)(86362001)(4326008)(52536014)(70586007)(36906005)(70206006)(8676002); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 9f72befe-ab95-4862-52ad-08d7e75de96a X-Forefront-PRVS: 03827AF76E X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ZTG3OHwZ/OCEvWjDjD2buL7R3FVqX367HEvL+4/99Kd/ahZBhkhTIlbphHLYMvj1tT8bHsDNU0wIB1tKRtMbW8Vxy2ruikH7j3W1G55/9iuRl11c8maF+bmFqJHlA4wxEeCO+Xd0e4g1aQG4txFgxNTSLJfFUMaTifowX/5+w094bx5YdxDJ17gi0X9P6TvbRcpsrrhDwQrmGEl1pxv51EZxYf6JiIxFJJf6+0VLgCte4eXR+v1JT8Dco9yXE6ixV/3t4nsrbxm+kMRhDzyssHnrkeUHyUdkSv0pwi0LaxLJuRYauN+jwOAYlDXvx6T3hIqcBearFDYuDKPlNYdI5ew7YQ7VrSpIh6+XICESHaYv0eYHEyx1KjXSjHXL6MQWtceVQQ14q5RRd/L+8TdoMiO9hhZ0kPcHAK82vKk+yJCKttNXhNHAgTsSTfE5zEsYpQBPs6CfTJp0suHq+Y8r3Q5/M3M45mYAn4pIph3Cym9CEcbiwONQ9XZm/gh7pJ9+KFJUwvmb4KuxpSUzn/gl/b5qO07Sc4/jrH54jAHnp/MeH3a2PHCuhP6mDKwrC9jgCS1sCdnPVHIhgfN5AqToEg== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Apr 2020 08:11:29.5286 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 88eef4a2-50ad-43ab-0038-08d7e75ded58 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR08MB5461 Archived-At: Subject: Re: [TLS] DTLS 1.3 AEAD additional data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 08:11:36 -0000 --_000_AM6PR08MB33189D58D3342BCD68D91F299BD30AM6PR08MB3318eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Martin, On Thu, Apr 23, 2020, at 16:43, Hanno Becker wrote: > > But Hanno's proposal is a terrible thing to have to implement. You > have to assume that there is some way to recover which CID to use in > decrypting any record. You might save some datagram-local state, but > that's awkward. Stacks that I've worked on try very hard not to have > state transmission between records for good reasons. So this would be a > fairly bad complication. Separately, I hope that no one would be > contemplating trial decryption for this, which would be terrible. > > Yes that's a fair point and also applies to Ekr's proposal > https://github.com/tlswg/dtls13-spec/pull/143. I don't see how. If you are talking about marshaling costs, that's a const= ant problem, but we haven't found that to be an issue in practice. From my= perspective, it's the old DTLS records with a pseudo-header that are hard = to construct; the new format is far easier to construct for sending (assumi= ng that you don't try to shave the sequence number length down dynamically,= but that's a new option our stack doesn't try to use). You criticize that an implicit CID which is still included in the AAD requi= res state on the receiver when processing multiple records within a single = datagram, which is true. I'm saying that the same holds for the PR 143 whic= h adds the implicit CID to the AAD even if it's not in the header. In that = sense, this (valid) issue exists on both cases. Yours is a sending-side concern, and that seems to be subjective, because I= think that sending is easier without a pseudo-header. My concerns were ab= out receiving. There is nothing subjective here: You cannot make full use of the compressi= on features such as length omission independently of the underlying datagra= m layer, because you have to know that the record you're sending will be th= e last. So clearly sending is _harder_ if you have to decide on the header = format already during record protection, while if you can protect the recor= d on the basis of the logical header data alone, choice of header format an= d choice of packing into datagrams can be handled entirely independently. > The CID maintenance for incoming records can be avoided when forbidding > CID elision, as suggested by Ekr. > Comparing the state maintenance complications this avoids to the > increase in header size it introduces, maybe > that's the way to go, as the state maintenance indeed seems to be the > bigger pain. > However, even if CID elision is removed, I maintain the proposal to > always use the logical presentation of the header > for AAD, for all the mentioned reasons: (a) No interleaving of record > and datagram layer, (b) conceptual clarity and > independence of [header] compression methods from cryptographic > computations, as e.g. in cTLS, (c) dynamic > choice of header depending on network paths. All those issues persist > when sticking to the on-the-wire AAD. > What are your reservations towards this? I'm sorry, I don't follow your argument. What exactly? The authenticated logical header being different than what is sent on the w= ire is a bug in my opinion. Authenticating all the bytes you send makes th= e protocol simpler and less error prone. So far, there hasn't been any substance to the claim that authenticating th= e logical header is a "bug" or "defect", while in (a)-(c) above I provide m= ultiple reasons why it is in fact beneficial. Cheers, Hanno IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_AM6PR08MB33189D58D3342BCD68D91F299BD30AM6PR08MB3318eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Martin,

On Thu, Apr 23, 2020, at 16:43, Hanno Becker wrote= :
>  > But Hanno's proposal is a terrible= thing to have to implement. You
> have to assume that there is some way to reco= ver which CID to use in
> decrypting any record. You might save some da= tagram-local state, but
> that's awkward. Stacks that I've worked on tr= y very hard not to have
> state transmission between records for good r= easons. So this would be a
> fairly bad complication. Separately, I hope t= hat no one would be
> contemplating trial decryption for this, whic= h would be terrible.
>
> Yes that's a fair point and also applies to E= kr's proposal
> https://github.com/tlswg/dtls13-spec/pull/143.

I don't see how.  If you are talking about ma= rshaling costs, that's a constant problem, but we haven't found that to be = an issue in practice.  From my perspective, it's the old DTLS records = with a pseudo-header that are hard to construct; the new format is far easier to construct for sending (assuming that you d= on't try to shave the sequence number length down dynamically, but that's a= new option our stack doesn't try to use).

You criticize that an implicit CID which is still = included in the AAD requires state on the receiver when processing multiple= records within a single datagram, which is true. I'm saying that the same = holds for the PR 143 which adds the implicit CID to the AAD even if it's not in the header. In that sense, thi= s (valid) issue exists on both cases. 

Yours is a sending-side concern, and that seems to= be subjective, because I think that sending is easier without a pseudo-hea= der.  My concerns were about receiving.

There is nothing subjective here: You cannot make = full use of the compression features such as length omission independently = of the underlying datagram layer, because you have to know that the record = you're sending will be the last. So clearly sending is _harder_ if you have to decide on the header format alr= eady during record protection, while if you can protect the record on the b= asis of the logical header data alone, choice of header format and choice o= f packing into datagrams can be handled entirely independently. 

> The CID maintenance for incoming records can = be avoided when forbidding
> CID elision, as suggested by Ekr.
> Comparing the state maintenance complications= this avoids to the
> increase in header size it introduces, maybe =
> that's the way to go, as the state maintenanc= e indeed seems to be the
> bigger pain.
> However, even if CID elision is removed, I ma= intain the proposal to
> always use the logical presentation of the he= ader
> for AAD, for all the mentioned reasons: (a) N= o interleaving of record
> and datagram layer, (b) conceptual clarity an= d
> independence of [header] compression methods = from cryptographic
> computations, as e.g. in cTLS, (c) dynamic
> choice of header depending on network paths. = All those issues persist
> when sticking to the on-the-wire AAD.
> What are your reservations towards this?

I'm sorry, I don't follow your argument.

What exactly?

The authenticated logical header being different t= han what is sent on the wire is a bug in my opinion.  Authenticating a= ll the bytes you send makes the protocol simpler and less error prone.

So far, there hasn't been any substance to t= he claim that authenticating the logical header is a "bug" or &qu= ot;defect", while in (a)-(c) above I provide multiple reasons why it is in fact beneficial.

Cheers,
Hanno
IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_AM6PR08MB33189D58D3342BCD68D91F299BD30AM6PR08MB3318eurp_--