[TLS] AD evaluation of draft-ietf-tls-ticketrequests-05
Benjamin Kaduk <bkaduk@akamai.com> Wed, 28 October 2020 22:27 UTC
Return-Path: <bkaduk@akamai.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 688B83A0969; Wed, 28 Oct 2020 15:27:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
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 XmT9hT2E7N0Z; Wed, 28 Oct 2020 15:27:53 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 748383A0976; Wed, 28 Oct 2020 15:27:50 -0700 (PDT)
Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 09SMNqV6015943; Wed, 28 Oct 2020 22:27:50 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : mime-version : content-type : content-transfer-encoding; s=jan2016.eng; bh=cGQ0KEWlUqeCHn7tPKVA9/JBcWwHNWz8o8VkdoveiCY=; b=TpGDTlD0j+2Mkyovs0vU1gohWp655fI0SCDwZy5C87yrhM4dpxquIM5DirokHKMo/9Hp 1mVWVkOSzpKzzkq/lWsLlisIp4TMcuKRBe52rfRhUZ/eWac7Ob4DzX27qn36fTC4966C V/ekVA8YbaA3gh7620wzbtgrZeGkwPfMe6OY5RHyiXh2eoSX2BUuCJzbx0D5yemnjVBt 5y30JfbWwAaT1yhEBGU4jtXVTRaQtVha2FdmO+icWzwlmbmKQEIVx7yqj5t1dVaXupk8 wLSBh2kCBLeGh4eissoCQ6249T0tmsrVSS4TlY8oTli2k6b8HgL0EjuNUgZT4zSA1U2n lw==
Received: from prod-mail-ppoint4 (a72-247-45-32.deploy.static.akamaitechnologies.com [72.247.45.32] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 34cce7xse0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Oct 2020 22:27:49 +0000
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 09SMJMYC000674; Wed, 28 Oct 2020 18:27:49 -0400
Received: from prod-mail-relay18.dfw02.corp.akamai.com ([172.27.165.172]) by prod-mail-ppoint4.akamai.com with ESMTP id 34f2457bwk-1; Wed, 28 Oct 2020 18:27:48 -0400
Received: from akamai.com (unknown [172.19.16.134]) by prod-mail-relay18.dfw02.corp.akamai.com (Postfix) with ESMTP id 5F8E0293; Wed, 28 Oct 2020 22:27:48 +0000 (GMT)
Date: Wed, 28 Oct 2020 15:27:47 -0700
From: Benjamin Kaduk <bkaduk@akamai.com>
To: draft-ietf-tls-ticketrequests.all@ietf.org
Cc: tls@ietf.org
Message-ID: <20201028222746.GF3403@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.9.4 (2018-02-28)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-10-28_09:2020-10-28, 2020-10-28 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 bulkscore=0 suspectscore=0 adultscore=0 spamscore=0 phishscore=0 malwarescore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010280137
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-10-28_09:2020-10-28, 2020-10-28 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 suspectscore=0 mlxlogscore=999 mlxscore=0 impostorscore=0 spamscore=0 phishscore=0 malwarescore=0 bulkscore=0 lowpriorityscore=0 priorityscore=1501 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010280138
X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.32) smtp.mailfrom=bkaduk@akamai.com smtp.helo=prod-mail-ppoint4
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/FyMEMIe1sKfcyTW-G0tNLkK9ICA>
Subject: [TLS] AD evaluation of 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: Wed, 28 Oct 2020 22:27:56 -0000
Hi all, Thanks for everyone who contributed to this one; I think we ended up in a pretty good place with it. Sorry to have taken so long to get around to processing it; on the plus side, the only document now in my publication-requested queue is DTLS 1.3, and that will be entering AD Evaluation shortly! I think there's enough here that is reader-unfriendly that we should wait to start the IETF LC until there's a new revision out, but hopefully the needed changes will be fairly straightforward. I made a few editorial suggestions and nit fixes at https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/21 . We have some level of duplication between the Introduction text describing limitations of the stock 8446 mechanism, and the detailed use cases in Section 2, but I think it's probably acceptable. We talk about avoiding ticket reuse being a goal (e.g., explicitly so in the "Parallel HTTP connections" use case), but we don't really say why. I think the introduction could probably do with a paragraph on this that references https://tools.ietf.org/html/rfc8446#appendix-C.4 for the default behavior being to attempt to avoid reuse of tickets (without implying that it is required behavior, of course). Section 2 * Connection priming: In some systems, connections can be primed or bootstrapped by a centralized service or daemon for faster connection establishment. Requesting tickets on demand allows such services to vend tickets to clients to use for accelerated handshakes with early data. (Note that if early data is not needed by these connections, this method SHOULD NOT be used. Fresh handshakes SHOULD be performed instead.) This doesn't seem to paint a very clear picture of the use case. It doesn't even seem to be clear about whether the "centralized service or daemon" is a helper on the TLS client or server side! I also want to check my understanding here, in that the recommendation for only doing this when early data is needed is due to the fact that you need to have an initial handshake with which to negotiate the ability to use early data in the subsequent handshake, and having the central service do a bunch of full handshakes just to get a ticket for use on a subsequent connection that does user early data is a lot of overhead, whereas if you don't need early data then you only do as many full handshakes as you need connections (vs 2x that number to get a ticket and then do early data) and get fully independent keys. Since you have this central service the extra latency for a full handshake is irrelevant because you're priming connections in advance, not on-demand. * Less ticket waste: Currently, TLS servers use application- specific, and often implementation-specific, logic to determine how many tickets to issue. By moving the burden of ticket count to clients, servers do not generate wasteful tickets. As an example, clients might only request one ticket during resumption. Moreover, as ticket generation might involve expensive computation, e.g., public key cryptographic operations, avoiding waste is desirable. (I assume we have a particular case in mind that does use public-key crypto when issuing a ticket, or we wouldn't have mentioned it.) When a client presenting a previously obtained ticket finds that the server nevertheless negotiates a fresh session, the client SHOULD assume that any other tickets associated with the same session as the presented ticket are also no longer valid for resumption. This Unfortunately, RFC 8446 does not seem to be consistent about "session" (persists across multiple resumption handshakes) vs "connection" (a single handshake) terminology. We may want to consider just discussing "full handshake" and "initial full handshake" instead of trying to use the "session" shorthand. and the number requested. Servers MAY send additional tickets, up to the same limit, if the tickets that are originally sent are somehow invalidated. (nit) pedantically, the server can send whatever tickets it likes whenever it likes. The current "up to the same limit" looks a little bit like it's trying to restrict the server's behavior, so "typically using the same limit" might be better. Servers MUST NOT send the "ticket_request" extension in ServerHello or HelloRetryRequest messages. A client MUST abort the connection with an "illegal_parameter" alert if the "ticket_request" extension is present in either of these messages. I note that we do have other messages (Certificate, CertificateRequest, NewSessionTicket itself, maybe soon ClientEncryptedExtensions) that can carry extensions, so in that sense it's strange to only explicitly prohibit these two. That said, they are the two that would be most tempting to (inadvertently) put this extension in, so I don't particularly mind leaving it this way. Section 6 I suppose there is perhaps some risk of traffic analysis leaking how many tickets were issued at the start of the connection (and thus the value that the client requested), but this is neither terribly interesting nor terribly novel, so I don't propose that we add text about it. Despite ticket lifetime hints provided by servers, clients SHOULD dispose of pooled tickets after some reasonable amount of time that mimics the ticket rotation period. While this is true and good advice, I note that §4.6.1 of RFC 8446 already has "MUST NOT cache tickets for longer than 7 days". It does not look like this advice is fully duplicating the 8446 advice, so perhaps an additional sentence like "As specified in Section 4.6.1 of [RFC8446], 'clients MUST NOT cache tickets for longer than 7 days'."
- [TLS] AD evaluation of draft-ietf-tls-ticketreque… Benjamin Kaduk
- Re: [TLS] AD evaluation of draft-ietf-tls-ticketr… Christopher Wood
- Re: [TLS] AD evaluation of draft-ietf-tls-ticketr… Benjamin Kaduk
- Re: [TLS] AD evaluation of draft-ietf-tls-ticketr… Christopher Wood