Re: [TLS] draft-ietf-tls-ticketrequests-05

Hannes Tschofenig <Hannes.Tschofenig@arm.com> Fri, 03 July 2020 07:52 UTC

Return-Path: <Hannes.Tschofenig@arm.com>
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 A72203A03F2 for <tls@ietfa.amsl.com>; Fri, 3 Jul 2020 00:52:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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=IiaURm+E; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=IiaURm+E
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 TLLtsauGvCY9 for <tls@ietfa.amsl.com>; Fri, 3 Jul 2020 00:52:47 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150087.outbound.protection.outlook.com [40.107.15.87]) (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 C88843A011B for <tls@ietf.org>; Fri, 3 Jul 2020 00:52:46 -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=q8AuVpmBN3wvucn3yDwpdzQmr10tavTcOmu0gFKUY3E=; b=IiaURm+Euym2m3JD4UbYTPzjpeBrHdyD+0DvhTtp8IOICR4lAjsQgD5LdEAYQ3G8MHc56HQVMuWoiS3WDpzdORC1rGkXIeF0NfXHH4sYxfQWL9QcIFB8CsukKw25pnRmtvZrfYFOBNo8kQyc0qXArbptbKvbZk8GHhMCB/sb/II=
Received: from AM6P192CA0021.EURP192.PROD.OUTLOOK.COM (2603:10a6:209:83::34) by AM6PR08MB5287.eurprd08.prod.outlook.com (2603:10a6:20b:b0::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.24; Fri, 3 Jul 2020 07:52:44 +0000
Received: from VE1EUR03FT058.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:83:cafe::79) by AM6P192CA0021.outlook.office365.com (2603:10a6:209:83::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.22 via Frontend Transport; Fri, 3 Jul 2020 07:52:44 +0000
X-MS-Exchange-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 VE1EUR03FT058.mail.protection.outlook.com (10.152.19.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.24 via Frontend Transport; Fri, 3 Jul 2020 07:52:43 +0000
Received: ("Tessian outbound a4b10e5b482d:v62"); Fri, 03 Jul 2020 07:52:43 +0000
X-CR-MTA-TID: 64aa7808
Received: from 182144b66872.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 477344E0-A38F-47AC-ACEB-5967FE3F6D04.1; Fri, 03 Jul 2020 07:52:38 +0000
Received: from EUR01-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 182144b66872.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 03 Jul 2020 07:52:38 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RaL4n8uRnw7tcbsudmjFj0ImQ3GsRQuBqHUUM/5hbG2QpNSTRLiDyyNP110pKgQ2oUgzQnZaWuXJgmU8Kce6Z59OZ/JR7ip2uvUDeM0i+l3ZSY2idBSl5Nd4741C5r4BZZwXDk+D5D20AXk1dOUsceH2NAjE971ROKRYALUN2jKxi5r4PcZWx8Mplvvo5SxEjvsgvXFTsj71bCes/eIvt+L0JYZhxVlarjnf2JS47xjCkXbaS1Z+/SEuWd49atVmPiE5BLWpc2qD/uMS+Wu5VYr5pX/PEA9ilFW6Q8BD75aWPP1iil9RFgTiTxeCSbUaGWlMqpGZcRwL9DyE4dqa3A==
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=q8AuVpmBN3wvucn3yDwpdzQmr10tavTcOmu0gFKUY3E=; b=a9BrKjzTb7omRnOZIUAgHjp+ffr3rByM+FqqOXwOEFMQSJefKnpe4Je4FIG5x1nSAln/fUB9wrXEw6RMZKRRK0hNcm7d5OcvSmX6hdAIBKE/yWN1ugwxYeQLqDBeJevUlykitwDpAr91h1aAU16lzzNcg8WWgnp9vzuiT4Q7ZtmEd9gvpXQz4Aj7EAihPtystwNQ0GW6MY67bIN5+AUbhi9afUky0xh14DG5A8CpwEBhDmCEqOz63Mtky21orQwQeoa1Jw9ju+ihbaJeAdYrJSN5bmuOeSSRXqZLKFGaIyizHUOrzf/XJqWwxooRNTXyh1vTkEpzU/YzVVU6KShOEg==
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=q8AuVpmBN3wvucn3yDwpdzQmr10tavTcOmu0gFKUY3E=; b=IiaURm+Euym2m3JD4UbYTPzjpeBrHdyD+0DvhTtp8IOICR4lAjsQgD5LdEAYQ3G8MHc56HQVMuWoiS3WDpzdORC1rGkXIeF0NfXHH4sYxfQWL9QcIFB8CsukKw25pnRmtvZrfYFOBNo8kQyc0qXArbptbKvbZk8GHhMCB/sb/II=
Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.23; Fri, 3 Jul 2020 07:52:36 +0000
Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae%7]) with mapi id 15.20.3153.024; Fri, 3 Jul 2020 07:52:36 +0000
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
To: "ilariliusvaara@welho.com" <ilariliusvaara@welho.com>
CC: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] draft-ietf-tls-ticketrequests-05
Thread-Index: AdZPwyuzW8DO++UhTr2C4GnWMXxBhgAFRRUAAB7G07A=
Date: Fri, 3 Jul 2020 07:52:36 +0000
Message-ID: <AM0PR08MB3716E1617FDD468DD9F492C5FA6A0@AM0PR08MB3716.eurprd08.prod.outlook.com>
References: <AM0PR08MB3716F0A25D726E5F57CA6525FA6C0@AM0PR08MB3716.eurprd08.prod.outlook.com> <20200701184846.GA41980@LK-Perkele-VII>
In-Reply-To: <20200701184846.GA41980@LK-Perkele-VII>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ts-tracking-id: 1773523c-15ed-4a06-81b9-c249d6ff61a2.0
x-checkrecipientchecked: true
Authentication-Results-Original: welho.com; dkim=none (message not signed) header.d=none;welho.com; dmarc=none action=none header.from=arm.com;
x-originating-ip: [80.92.121.249]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: 54efdc1f-99c2-4983-df15-08d81f2611a8
x-ms-traffictypediagnostic: AM0PR08MB3716:|AM6PR08MB5287:
X-Microsoft-Antispam-PRVS: <AM6PR08MB5287DF3394A2577F3D5341A5FA6A0@AM6PR08MB5287.eurprd08.prod.outlook.com>
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000;
x-forefront-prvs: 045315E1EE
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: QFW1Z/xfNnGZlFhuSoZ/Qjw90chfgWjy4o5bwp/iVnED5c1UhYfgmANf23ik+DtS9RRnWee0CNGhWUnf5RaAzq+rnwaQuyJ4H/M6t8K7yVkCdRYlaMZAm4KPkmxbd9uGhL47TO8Psa+avMoq/uKaO/SHPrtZZURTgfrTdBW8lxikvwPy21CHeiBf8foMi9LEKLU5GzRRpAU7oHH6nYDraOK1T7gwiUd4ocP67Xb7XJm9Tp1/CVEBuHVT5ghPOc/H7YMmN9tbYcIAPMycrNbU8jYgXCBc4MhvM5eacww1YH8ZTWo8HC1FxqDRcC+4Flwl8V4JVQIlsk+uD6N9ulZ46DRUyiai4Vee0eWrAY6F1SXbhIxeLkyIrmQvcEL/tGTAq978NcLc3vFtaiBd36WsNg==
X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(376002)(136003)(39860400002)(346002)(366004)(9686003)(71200400001)(478600001)(26005)(186003)(8936002)(2906002)(66446008)(86362001)(66946007)(53546011)(5660300002)(64756008)(316002)(66476007)(6506007)(66556008)(83380400001)(33656002)(6916009)(8676002)(4326008)(76116006)(55016002)(52536014)(966005)(7696005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: TRB6X594xfxxRfJqVwAUTAEIiuo4FXmvzOTLesr9GT8p79E/OUD9QT9u0auQJzrPNJfIujVXDZahgzaV7Q4gDtOpPpu1jU1O0YH9N5lQNcleUzL585AgCFaU3qa/u8w9++8WLRFKjvYjntApSCAE8ed5oGXfsn8ywhE3i3asDJMs/l3CfkkpvWpYIHYinSczuMDwBDGbiPEJK+MdpkZT/RaO7elAbSsKXVDLVd+KO5XvusYMwnu/caKX6kpOuIpRqzZfaPBQ817cznyZZC/3LrmuHFo5jSXfP68Wl+tJMkhgPgEl6jpjOeZR+QgkLdoPaCPYtN003Xh3hZcKY3vuY8qOjXOlcmCP7z5rXbIfaAOi58WV+Bnz6kAa/Xx69S59AN9u2c15AL0fQ1LlBUZ/w1aoUij8SjB0DevkCvFPoV0bBbW8C0dyqoTVtfRyOsQeTQe8g3dDu/+ByVQmGF0a7kiPwybeETz6ltRYlNHuowTQpRiP89DbV+my6cMhfn6x
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3716
Original-Authentication-Results: welho.com; dkim=none (message not signed) header.d=none;welho.com; dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT058.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)(39860400002)(396003)(376002)(346002)(46966005)(70206006)(5660300002)(6862004)(356005)(2906002)(186003)(26005)(55016002)(86362001)(81166007)(8936002)(336012)(82310400002)(8676002)(36906005)(33656002)(82740400003)(966005)(47076004)(316002)(9686003)(53546011)(6506007)(4326008)(52536014)(7696005)(70586007)(478600001)(83380400001); DIR:OUT; SFP:1101;
X-MS-Office365-Filtering-Correlation-Id-Prvs: f670c16a-d0d5-4090-ec5c-08d81f260d66
X-Forefront-PRVS: 045315E1EE
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: uaxiQQeQ00DeLhCBshWxccJDi8cHB9Kd2k3BQt3sVybRaq+2rbDKMTAJ2XCfZcKCwOdMQYyoZYjGyTvRz6bA7aDHR+Fw+8BMhFG5nZjIMLadBQiQ/buFa2IfMYTeW1lkxT44gxgJHnuBQf+MwYC+PKFtU0UXoW6TeOgOUk2NUlSf/fGCclMJ1qrezM1gaVe5WyaLZfPq2UOwIbgMOKdKkJ6eunPBih3RsR76Xrt3gYMuy+VllWAmMP73ryF51AabGPf/cwSaqiJ3FqsQKqFirl4YsQtg/fmSi5s7r62iUtG9+mtoWPyVto/xJTBzcXd3V2o2iJoNpmoZB6pLYom3izHWSFP9tFmG/3KyonJTMt6Yw0ExAY4g5WAegoj271Pjqx0eHbBYXKMK+UyFhWlFWuIHzg/CTXCBO8MdnO7wBA6dnc3zCPxd+s0Am9xpaBDR/BG66hMhaGOr31bG5zSgNRy0wcy5YxhO/9nTRRTbuoU=
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jul 2020 07:52:43.7013 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 54efdc1f-99c2-4983-df15-08d81f2611a8
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-AuthSource: VE1EUR03FT058.eop-EUR03.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB5287
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/2qXzyldkaYloo75mHY_9GKomNoY>
Subject: Re: [TLS] draft-ietf-tls-ticketrequests-05
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Jul 2020 07:52:50 -0000

Hi Ilari,

Please see my comments below.

-----Original Message-----
From: ilariliusvaara@welho.com <ilariliusvaara@welho.com>
Sent: Wednesday, July 1, 2020 8:49 PM
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: <tls@ietf.org> <tls@ietf.org>
Subject: Re: [TLS] draft-ietf-tls-ticketrequests-05

On Wed, Jul 01, 2020 at 04:52:18PM +0000, Hannes Tschofenig wrote:
> Hi Tommy, Hi David, Hi Chris,
>
> I read through the draft and have a few questions.
>
> 1) Is it really necessary for the client to use two values to
> differentiate the tickets it wants with a new session and with
> resumption. It feels a bit over-designed. I would just have one value
> and that alone would be super useful already.

Consider a client that does:

- Parallel connections
- Does not reuse tickets

Such client needs enough tickets to cover the multiple connections in case of fresh handshake (might be 5-10 or so), but only needs to replace the tickets for current connection (1 or 2) in case of resumption. So any single value will result in oversupply or undersupply.

[Hannes] The client is probably in the best position to know how many tickets it wants. I don't see the case where it is necessary to distinguish two types of tickets with this extension. I want this to be as simple as possible.

> 2) This sentence confuses me:
> "
>    Servers SHOULD NOT send more tickets than requested for the handshake
>    type selected by the server (resumption or full handshake).
>    Moreover, servers SHOULD place a limit on the number of tickets they
>    are willing to send, whether for full handshakes or resumptions, to
>    save resources.
> "
>
> Shouldn't the sentence say:
> "
>    Servers SHOULD NOT send more tickets than requested for the handshake
>    type (resumption or full handshake) indicated by the client.
> "

The server might not want to actually honor request to send 255 tickets.
Even if ticket minting is a fast operation, 255 of them might take non- trivial time (and bandwidth).

[Hannes] I was trying to point out that there appears to be a bug in the sentence.
(at least that's my understanding as a non-English native speaker)

> Even then, I believe the sentence should actually say MUST NOT instead
> of SHOULD NOT. If the client is already taking the effort to indicate
> that it does not want more than a certain number of tickets then it
> might have a reason. I am thinking about the case where the client
> indicates that it does not want any tickets then it would be strange
> for the server expressing support for the extension and still send
> tickets.

If the client signals 0 tickets for handshake and 0 tickets for resumption, then reasonable interpretation is that client does not support resumption at all, and it is waste of resources to send it any tickets.

[Hannes] Correct. This is what I am saying. Currently the text allows the server to still send a ticket even though the client says "don't send it".

But how should server interpret client saying it wants 1 ticket for full handshake and 0 tickets for resumption? A reasonable interpretation is that client does support tickets and is is willing to reuse tickets.
So if the server is not willing to reuse tickets, the most reasonable action is to send 1 ticket to the client on resumption (if server is willing to reuse tickets, the most reasonable act is not send any tickets on resumption).

[Hannes] If the client says it only wants one ticket then he should only get one ticket. If it wants another ticket when it resumes the session then the client can ask for another ticket.

Basically, there can be good reasons to send more tickets than requested. Just that most of the time, sending more tickets will lead to oversupply.

[Hannes] It would be good to decide who makes the decisions in this process. If we want to give the client the possibility to indicate how much it wants to receive and you can still give the server the ability to send less. Currently, the authors did not decide what they want.

> 4) I believe it would make sense to define a ticket flag for the case
> where the client does not want to receive any tickets.

The sensible way to indicate that is to send (0,0) as requested ticket count.

[Hannes] I am suggesting to use the newly defined flags extension draft (see https://tools.ietf.org/html/draft-ietf-tls-tlsflags-02) for this purpose.


> 5) If a client sends the ClientTicketRequest extension during the full
> handshake is there an expectation that it sends it again in the
> resumption exchange? Would you assume that the server memorizes how
> many tickets the client wanted across the resumption handshakes?
> For example, in the full handshake I use the extension and indicate
> that I want 5 tickets. I get two tickets from the server. Then, I run
> a resumption handshake without transmitting the extension. Is the
> server expected to remember to still send 3 more tickets till the
> quota is exhausted?

I expect each connection to have its own ticket request counts.

[Hannes] I don't think I have read this in the draft.

In general, it is unsafe to cache extension values across connections in session.

[Hannes] Is it unsafe? In general, resumption is a mechanism to cache data across connections.

Sure, one probably can not cause anything bad with this extension, but with things like server_name, very bad stuff can happen if those are not taken from connection handshake.

[Hannes] But I am not talking about server_name but instead about how many tickets are left to be sent to the client.

> 6) The topic of when to send the tickets is something you mention in
> the document and it is indeed an issue. Have you thought about
> allowing the client to signal to the server when to send the tickets?
> Even making a distinction between "send me all tickets in a batch" and
> "send one after the other with some reasonable time in between" would
> be helpful.

What usecases would there be in spreading tickets in time?

[Hannes] If you want to open parallel connections quickly then it makes sense to obtain the tickets in batch.
If you do not want to open parallel connections but rather want to use the ticket mechanism to reduce the computational overhead and you are working on a low bandwidth connection then it is better to spread the transmission  in time. The latter case would be an IoT scenario while the former is a web scenario.

Ciao
Hannes


-Ilari
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please 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.