[TLS] How tight can the TLS 1.3 freshness check be?
Christian Huitema <huitema@huitema.net> Mon, 09 August 2021 03:49 UTC
Return-Path: <huitema@huitema.net>
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 2C1573A2575 for <tls@ietfa.amsl.com>; Sun, 8 Aug 2021 20:49:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 2znPeurmnAAy for <tls@ietfa.amsl.com>; Sun, 8 Aug 2021 20:49:18 -0700 (PDT)
Received: from mx36-out20.antispamcloud.com (mx36-out20.antispamcloud.com [209.126.121.68]) (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 F25213A2573 for <tls@ietf.org>; Sun, 8 Aug 2021 20:49:17 -0700 (PDT)
Received: from xse258.mail2web.com ([66.113.197.4] helo=xse.mail2web.com) by mx133.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1mCwHm-000kGi-Rc for tls@ietf.org; Mon, 09 Aug 2021 05:49:15 +0200
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4GjhsJ661PzLsw for <tls@ietf.org>; Sun, 8 Aug 2021 20:49:08 -0700 (PDT)
Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1mCwHk-0004Is-Na for tls@ietf.org; Sun, 08 Aug 2021 20:49:08 -0700
Received: (qmail 19394 invoked from network); 9 Aug 2021 03:49:08 -0000
Received: from unknown (HELO [192.168.1.104]) (Authenticated-user:_huitema@huitema.net@[172.58.46.189]) (envelope-sender <huitema@huitema.net>) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for <tls@ietf.org>; 9 Aug 2021 03:49:08 -0000
To: "tls@ietf.org" <tls@ietf.org>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <1bded1d4-cb56-7f08-46c9-f609df3f0f34@huitema.net>
Date: Sun, 08 Aug 2021 20:49:07 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Originating-IP: 66.113.197.4
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.197.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5y+TdELUc3IPXxOn6N6uGoCj3CSdYahsEhiizd3WfZtETnY uN7ArBzAQHvSodqCKnvlYLLlWSy3OGfGBNeqx2anHyJxjDLo4/ugN15VVJm4KWrxEaaKeSxe0Wrx 6M4G5/Wm4Zd53xWOh54QqC5fJ2uRkPQNIL4vgWmCSFfr3DzBuVxh7hoyMoWHMkqYfQEaAmvclDTL kOhHCeGceZEJ+YQspbt3W3gfNnuKkqGP09ZKLP25Cgscc2Nqd9azmDa4ZbYxn04qRLKGrOrEzQDq o2Fe5e0H1p2YD3fIDgqE3F/hSENKwnAR2oVisY+bnEqWCKi5klmK1va3wJScg92pg//jdNpXP/ul EV6DIUDLc0Yd6iTlYE+Zcn8p1rPpG64P1y7nVrUQfxkYoV3jt7fqlPgR0kaOEXLuWd+6zLg4wp8u X1nsyWu8Q0HDoORE+fy5gr3LgKffTIgl7nuGO/IJU1342OUMeHyTpNN0eXybX/w7/4a+Zyc1sUYl ckMDbruAhxfaTSRjFdfhbaOt3LLrhebQANd9wwprddzmEKEwWMj4JV36Zf8qesR4SGfjopzoh0F7 r6Nnh6rmOMhCUNjPwAqGEnFzsC48bTEFY06/YbB87Ww8G0LoS8V3Mt1pta8qAcLtCB3G1CwpaI3Z 4ESkMWDVJEenxBoIht3V0nekAoxXAhubaqn6Fk9KeqhZcLQ2couyuLfHqAnAj7rgKH7+eCmmGm4h NdiAxrBgwAoWnpXbC1ShcA6Xvva2QAVEjpqzANZUmhRJvFbdO1XaKeBsEtPNNv8imjx8UPgLxSHt EuQKlB0sl4OFxBT1d23OUWLVuGpBtL9ewJnoHKUNLZpf7DfZK/JdWvgd2/FibEdMM0Jnxu/VcARR JJg0CPVGXFYA7xCx7SWZBpdAUArn/St00aGa08t44IPL25P8DLNzMDIRDLdvK/cKOEqlCIPGIfYQ DNLcNVwigJ23suxKKQl6t4RW
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Z_oQVdNxNzv4fd6PMKwSX_p251U>
Subject: [TLS] How tight can the TLS 1.3 freshness check be?
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: Mon, 09 Aug 2021 03:49:23 -0000
Some context. I am working on DNS over QUIC (https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/). From a performance point of view, using QUIC and 0-RTT is pretty compelling. The 0-RTT packets can only carry DNS queries, which do not change the long term state of the DNS servers. However, the queries do change the state of the server cache. Attackers might be able to assess the state of the cache by replaying 0-RTT packets, possibly finding out what encrypted queries the packets contained. These attacks can be mitigated somewhat by using the TLS 1.3 freshness check, so that 0-RTT packets can only be replayed for a short time after being sent by the client. The shorter the time, the stronger the mitigation. Hence the question, how short can the delay of the TLS 1.3 freshness check be? -- Christian Huitema
- [TLS] How tight can the TLS 1.3 freshness check b… Christian Huitema