Re: [TLS] draft-ietf-tls-dtls13 - sequence number encryption

Pascal Van Leeuwen <> Fri, 26 July 2019 15:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D432F12007A; Fri, 26 Jul 2019 08:11:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4eEx-ke_ZN5S; Fri, 26 Jul 2019 08:11:35 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6F8C5120108; Fri, 26 Jul 2019 08:11:27 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=XiDQp6oGzOlJgZcG47s6CH66KMgg2McJbOi1YoFhbcWUs+JueZwmSzekjFyXQetKut4wP45y3uFWX+8tJnZElKjfG4NogRGNmwSyNs4ejHcXwe7BATN7azK2tVMfriMW/DQjs+DbyjTWtjySzyEkpTLBlsU8ryKEALO2up2vuzYDAwIg0W5MqDj3bSR+f8mNax5cWRziaADSnzsR3iX3nZshKupd4M9BVsqMZI6iawNCoo38p+Aj7HWwZKZFSQwlLMCD1XCsrXmFB3H1327+zdj17AizmSYZCXojrWFHhV1qLTgLZdeJPHTcu5aEYOstpqv6QwkMuK8E1VDWj14AXA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xxjxptuILPp0j4CttPyAYa6YUqNRY16WYCCoFuXG2hw=; b=Pg19qDt9WmQaGtIgpRThh5D6Pq0Nygw3NQxlV+Tm1l7ynnLdMStbjPIioGHgUF4gw5WLv+SSkyBmYD/nO2InukR5+VaQi/48asMJVTIfiApPuAOEIJ1OO9hO7kWT/fy365/1G/kYYXYFcFl3z1V5q1KjJlv7jWZi8SYbA6HUCNTaEOEedvXJoWzycy5GQUWJiOcLZGBQcwYj8rMk6rVq1MiDs80zYw2lAunlGxo7I7+UbV1kWbI0ZWlYzOi8nYcanCSdXVXACmBFdIEPhi2kQT9dXfy5buo7KvAfVLTtZqslXDmM9T1nEqMwUs3PxCsJcEEJCVWtXinb8AnFiWqs7Q==
ARC-Authentication-Results: i=1; 1;spf=pass;dmarc=pass action=none;dkim=pass;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xxjxptuILPp0j4CttPyAYa6YUqNRY16WYCCoFuXG2hw=; b=DmQ4ychV/7+ir+yFmJ2boqMIf1/pTXKKRPo8KrS7BqejqTjopUatWlQjnS4a3NujaO9z42cIZuARtEjQLpRDpy5dwNBqKIqjXv2W9r/DNi6NeW2HW5MsYHSNCWG0BKCNoQwXrPiulXHPfnT69v8PbU5/+xzunQKQCd/M8iNFyyY=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.10; Fri, 26 Jul 2019 15:11:24 +0000
Received: from ([fe80::68d7:2bbb:af61:2e69]) by ([fe80::68d7:2bbb:af61:2e69%6]) with mapi id 15.20.2094.017; Fri, 26 Jul 2019 15:11:24 +0000
From: Pascal Van Leeuwen <>
To: Eric Rescorla <>
CC: "" <>, "" <>
Thread-Topic: draft-ietf-tls-dtls13 - sequence number encryption
Thread-Index: AQHVQ701vwAluI2xUUC+WEoQohWEn6bc+GCg
Date: Fri, 26 Jul 2019 15:11:24 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0e1e1994-b8ae-4e1c-7a2e-08d711db864f
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR20MB3053;
x-ms-traffictypediagnostic: MN2PR20MB3053:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01106E96F6
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39840400004)(376002)(346002)(136003)(366004)(199004)(189003)(51914003)(476003)(186003)(71200400001)(71190400001)(8676002)(9686003)(446003)(11346002)(7736002)(26005)(486006)(5660300002)(66476007)(66556008)(64756008)(66446008)(76176011)(81156014)(229853002)(76116006)(66066001)(86362001)(305945005)(14454004)(81166006)(6246003)(102836004)(66946007)(256004)(14444005)(6506007)(99286004)(7696005)(53546011)(3846002)(6116002)(966005)(53936002)(478600001)(68736007)(6436002)(74316002)(2906002)(52536014)(6306002)(8936002)(25786009)(55016002)(54906003)(316002)(4326008)(33656002)(6916009)(18886065003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR20MB3053;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: obyeejDs7bfv3a8CtNOkbRj/WfdIqJ/CVcsfbHAF/8l/6r3xFSMtG6Z/iiT9Y1VAD9RAxJZBbkaYADtVRgA0D30E7qYabDCUSTBa8bIdcrz4Woip6LfGPWYwLlMot0flyzHAlWTrOcksPPYc6WM+hkaUiCUI2mOaT3CXrvOMEsBGaRiZgcMfTs5JTZfI0TkBIW2xNEBcJRztyBGG34Iy3Ei3x83IJoLG8GcSEWoyijNB4XwQpjeeMsyQU9WJaCd8lbLxJLbeB+uVVwjh6MrD7FHYkMnZacz4gYjzcwQJAnvvJXFSTRHSSj4dhJ7maOtZJRdTmqBWrpNRDbubtfAe1uTKw3wBott3/v9ywwvrUWaGXoUsqmq33uCKBERKk3Fee1Cmx1D4FXnm1Zf2nK4AgQYhNZr7kVYDMRqQL/lTrVw=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 0e1e1994-b8ae-4e1c-7a2e-08d711db864f
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2019 15:11:24.3850 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: dcb260f9-022d-4495-8602-eae51035a0d0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR20MB3053
Archived-At: <>
X-Mailman-Approved-At: Fri, 26 Jul 2019 08:42:38 -0700
Subject: Re: [TLS] draft-ietf-tls-dtls13 - sequence number encryption
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: Fri, 26 Jul 2019 15:11:39 -0000

Hi Eric,

Thanks for the response!

> From: Eric Rescorla <> 
> Sent: Friday, July 26, 2019 4:19 PM
> To: Pascal Van Leeuwen <>
> Cc:
> Subject: Re: draft-ietf-tls-dtls13 - sequence number encryption
> Hi Pascal,
> Thanks for your note. I would encourage you to send it to the TLS WG (this alias just goes to the authors). With that said, some comments below
I guess I clicked the wrong emai button - sorry about that. I added the WG email to the cc list.

>> On Fri, Jul 26, 2019 at 1:53 AM Pascal Van Leeuwen <> wrote:
>> In draft 29, sequence number encryption was added. Now I can't find any rationale for 
>> doing so in the draft (tampering with it was already detectable as it's authenticated), 
>> and I don't know of any other protocol encrypting the sequence number, but the way 
>> that that's currently specified makes HW implementation very difficult and costly, 
>> so some proper cost-benefit analysis would be appropriate IMHO.
>> The current specification calls for encrypting the sequence number by XOR-in it with
>> the output of encrypting part of the ciphertext. From a hardware perspective, this 
>> means either taking the output of your encryption pipeline and feeding it back into
>>  the input (killing performance!) -or- adding another full encryption pipeline behind
>> the already existing one, which is very costly (and not useful for anything else).
> Yeah, we're aware of that. It's kind of unfortunate, but we didn't really have another option.
Sounds like that, from the rest of the response. Although I still wonder why this is so 
important. The RFC does not say much about the why at the moment.

>> I would propose the following options to be considered (in the order from most
>> desirable to least desirable, from a HW implementation point of view):
>> 1) Making the sequence number encryption optional, to be negotiated, to
>> allow trading off between performance/cost and the added security which
>> is also not provided by any existing alternatives either
> This was discussed and rejected, but it's certainly somethign you could raise again
Would that help? I suppose it was rejected for a good reason ...

>> or
>> 2) Encrypt the sequence number as part of the normal data stream
>> (Or am I missing some security implications for doing it that way? I guess 
>> it would add some known and/or easy to guess plaintext but the encryption
>> algorithm used (AES or Chacha20) should be strong enough to resist that.
>> I understand you don't want to decrypt the full packet before you do the 
>> anti-replay check, but that can still be done even if you do it this way by
>> just doing the sequence number check after decrypting sufficient data
>> to access it, but before decrypting the rest of the payload)
> I don't believe that this will work, because the sequence number is used to
> generate the AEAD nonce, so you will not be able to decrypt.
Ah yes, for TLS 1.3 the IV is now implicit and taken from the sequence number.
I didn't realise that for a second, my bad . I guess that's a good reason and having 
the nonce encrypted complicates the HW design even further, unfortunately :-(

>> 3) Use some other alternative way to obtain the sequence number 
>> encryption keystream that doesn't depend on the ciphertext output,
>> e.g. by encrypting the/some nonce with some other secret key.
> We were unable to find a way to do this that didn't have a lot of data expansion.
Using input that's NOT the input or output to the main cipher would already help a lot ...
but with the nonce itself out of the picture there's indeed not a whole lot you can use
without having to add it to the encapsulated packet. Not having any bright ideas at
the moment.

> Incidentally, QUIC has exactly the same design, so you may want to raise this
> issue there as well.
Ok, good to know,  although we don't do anything with QUIC at the moment.

> -Ekr
>> or
>> 4) At the very least, don't make the sequence number encryption depend
>> on the main ciphersuite but e.g. always make it use AES-ECB. Or ...
>> make it seperately negotiatable so you can at least always select AES-ECB.
>> Why? Because then at least that 2nd encryption engine only needs a 
>> single algorithm instead of 2 (or more), saving precious chip area ...

Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Verimatrix