[TLS] DTLS 1.3 epochs vs message_seq overflow

David Benjamin <davidben@chromium.org> Thu, 11 April 2024 23:12 UTC

Return-Path: <davidben@google.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 C02F0C14F70B for <tls@ietfa.amsl.com>; Thu, 11 Apr 2024 16:12:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.297
X-Spam-Level:
X-Spam-Status: No, score=-11.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-2.049, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3QW7WqbsRGE for <tls@ietfa.amsl.com>; Thu, 11 Apr 2024 16:12:31 -0700 (PDT)
Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7413C14F705 for <tls@ietf.org>; Thu, 11 Apr 2024 16:12:31 -0700 (PDT)
Received: by mail-yb1-xb30.google.com with SMTP id 3f1490d57ef6-dcbd1d4904dso346068276.3 for <tls@ietf.org>; Thu, 11 Apr 2024 16:12:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1712877150; x=1713481950; darn=ietf.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=00xqiDRovlKLm32rVWJ15q5MT9LPICkOHkAehhR2nCk=; b=j3al2rkfTk7RAXN/oEXUInDCYiVYPAM9OGT7EsRAeI3jojqiGiToRxofbMOVaaem0j xCD70ZjoMzY8bZKndOHjvGx9TvbMOs6dx/UZ32zdDmsypHXkRfbHDLqBE/Suyur+MdZW e2uyMOukk1Jfm+vcLqWluT7JfOTxxQ8Bo+nSE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712877150; x=1713481950; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=00xqiDRovlKLm32rVWJ15q5MT9LPICkOHkAehhR2nCk=; b=qcTzaTDzaLiJnN7cxbtkIRR3/MJxU2pb2di/auGZwVFou1JRt0SL268MQfNbExGCNk x0SSrzQuwtgDCfEzW3YweNwf0hNI1uVoFWA1PzBtnG+gA31foGFDka9ZyCs4FfaGHhob 6xc/XCSYjgea4dYkWuqgZnGMdrciV53Rt4fXhgloAQQuIjX4Tjfg1HoNe7RK1AFniYBc XKEGCgIcF3wJxn6XORZsUnuLb0K3B1sBv3FEXBHdzinzEVHyvBbFm70CbpX3O8jc9fa7 JCLmHdH9cfkmB26PLrVGUys+1wd1NeiDbD8f7eHGH55gZTC/DXuxA0Zjxla9tDSe35gk ryug==
X-Gm-Message-State: AOJu0Yz+RAJ0jDJlBM7sKoHJaHfRox3uSh20pUmvlRxf6iMsSHvie8zP xT1yvJ/p8J/oflZ4rInvOidSN8YrwoNPICd3cy5HqfSNAdkLDnkVlx5u3SW0yjMUM5UHdrbDVtP SSbSUJcfoub+BOb6dSTNBp0DwP3Mlh8OPIa8R4ttcVimCpuljEf0=
X-Google-Smtp-Source: AGHT+IGzDQac467n6s0L2wpSqpXflw7DQw56LxcnOZDMUf3wrxcl3esKJ3tegjntCQl2pTV48r6/F9ptza1MGIk/Bmc=
X-Received: by 2002:a25:6905:0:b0:dcd:b034:b504 with SMTP id e5-20020a256905000000b00dcdb034b504mr1005436ybc.27.1712877150218; Thu, 11 Apr 2024 16:12:30 -0700 (PDT)
MIME-Version: 1.0
From: David Benjamin <davidben@chromium.org>
Date: Thu, 11 Apr 2024 19:12:11 -0400
Message-ID: <CAF8qwaCr=FJU6TbqXscxQ5ezCVxREU_iiSQ5fO+UMsUEV_W1tA@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Cc: bbe@chromium.org, Nick Harper <nharper@chromium.org>
Content-Type: multipart/alternative; boundary="00000000000015fe200615da4ad1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/6y8wTv8Q_IPM-PCcbCAmDOYg6bM>
Subject: [TLS] DTLS 1.3 epochs vs message_seq overflow
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 11 Apr 2024 23:12:35 -0000

Hi all,

In reviewing RFC 9147, I noticed something a bit funny. DTLS 1.3 changed
the epoch number from 16 bits to 64 bits, though with a requirement that
you not exceed 2^48-1. I assume this was so that you're able to rekey more
than 65K times if you really wanted to.

I'm not sure we actually achieved this. In order to change epochs, you need
to do a KeyUpdate, which involves sending a handshake message. That means
burning a handshake message sequence number. However, section 5.2 says:

> Note: In DTLS 1.2, the message_seq was reset to zero in case of a
rehandshake (i.e., renegotiation). On the surface, a rehandshake in DTLS
1.2 shares similarities with a post-handshake message exchange in DTLS 1.3.
However, in DTLS 1.3 the message_seq is not reset, to allow distinguishing
a retransmission from a previously sent post-handshake message from a newly
sent post-handshake message.

This means that the message_seq space is never reset for the lifetime of
the connection. But message_seq is a 16-bit field! So I think you would
overflow message_seq before you manage to overflow a 16-bit epoch.

Now, I think the change here was correct because DTLS 1.2's resetting on
rehandshake was a mistake. In DTLS 1.2, the end of the previous handshake
and the start of the next handshake happen in the same epoch, which meant
that things were ambiguous and you needed knowledge of the handshake state
machine to resolve things. However, given the wider epoch, perhaps we
should have said that message_seq resets on each epoch or something. (Too
late now, of course... DTLS 1.4 I suppose?)

Does all that check out, or did I miss something?

David