Re: [TLS] DTLS 1.3 epochs vs message_seq overflow

David Benjamin <davidben@chromium.org> Thu, 11 April 2024 23:16 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 BF749C14F710 for <tls@ietfa.amsl.com>; Thu, 11 Apr 2024 16:16:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.297
X-Spam-Level:
X-Spam-Status: No, score=-16.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_HI=-5, 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 21g8FTRuqFWY for <tls@ietfa.amsl.com>; Thu, 11 Apr 2024 16:16:18 -0700 (PDT)
Received: from mail-yw1-x1129.google.com (mail-yw1-x1129.google.com [IPv6:2607:f8b0:4864:20::1129]) (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 B6CDAC14F5E6 for <tls@ietf.org>; Thu, 11 Apr 2024 16:15:54 -0700 (PDT)
Received: by mail-yw1-x1129.google.com with SMTP id 00721157ae682-617d4797d9bso2733847b3.1 for <tls@ietf.org>; Thu, 11 Apr 2024 16:15:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1712877353; x=1713482153; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=52dRS7jO0ubE7ti7yhZJdgZceW6lHejNjBYsGpT6Ha8=; b=JiioAgUy3TOICpudqwhuZpFC4DB+Mr/B91drT7K2yt1zkM1Ay/h6wtVJ7i+uqTBspA +Q0kgojx7xe5VJIzb0y6HbtMg/QE+dB5riT19CSy5G9GYCW/CIiUIcOv0PZMgS+qrQrT VAU60Ay0tXO8JvbK+APmyZzzO1Cgn8+xlrn10=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712877353; x=1713482153; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=52dRS7jO0ubE7ti7yhZJdgZceW6lHejNjBYsGpT6Ha8=; b=g1AvP+xC7jrrPvWqoND14v6r+HWmFRAf5HfDQ7cvnP6nl5Lm47gg1tiWr+XV7eXM37 zG9/B646haivKPU8GRaEnh5eWIlVuD4ShU2vTrqvp5X6gkcI6yD7asI6rSENHKHHENz/ YzDa99dCeFi7NVYeW8c6LXJuoKVetCK3wuA9TWue9wuyclyC/j5OltEHEZlPgrNyBLD5 VJx1JotYIgTtbe2VxoNGI6PI6/cuJdHQZokpERj1hx1zUReNP/iMtnbFUxXe/1/hIYPO +5AyWeHBZSk6Cgwr1BjM9IbTSK/V+SS+KQLoDP4a+rpA+0PKE3n4nxUwoMpLXEDY96Od D24g==
X-Gm-Message-State: AOJu0YzjW1YHf/Bhi1N84x343i2ce51y3TPl6O8J2DYnWZKX3oi+VvRn QeRkRCQdk5N9WXgelF+KjcbKY3Sk9VFAxAZnaDeHwVET7TtToPytZrsvzYbj7RNUBi5KJnn3fxo LlHyK/4mkKC0qaEksYKwFwO3F0gHATJvBe5eWYKW2pV5rKP7w
X-Google-Smtp-Source: AGHT+IEwhXKwvWYOiL6AZ3+P1nQI3SbWb11Fc+47jLjLWE8jh20hgZKtG7MG3k9HwS5rQHV8HsyFpcd12v5spVaUY4w=
X-Received: by 2002:a25:6884:0:b0:dcc:2da:e44e with SMTP id d126-20020a256884000000b00dcc02dae44emr884484ybc.61.1712877353055; Thu, 11 Apr 2024 16:15:53 -0700 (PDT)
MIME-Version: 1.0
References: <CAF8qwaCr=FJU6TbqXscxQ5ezCVxREU_iiSQ5fO+UMsUEV_W1tA@mail.gmail.com>
In-Reply-To: <CAF8qwaCr=FJU6TbqXscxQ5ezCVxREU_iiSQ5fO+UMsUEV_W1tA@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Thu, 11 Apr 2024 19:15:37 -0400
Message-ID: <CAF8qwaB1trnvAX7DXH94QHq9ZjyPz-YpqSgK5Rn9Jq2Qig_CVA@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Cc: bbe@chromium.org, Nick Harper <nharper@chromium.org>
Content-Type: multipart/alternative; boundary="0000000000002cc01d0615da569b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/UFGXSY8VxYgCRmCVzdhjs-rlvfI>
Subject: Re: [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:16:22 -0000

On Thu, Apr 11, 2024 at 7:12 PM David Benjamin <davidben@chromium.org>
wrote:

> 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?)
>

Alternatively, if we think 65K epochs should be enough for anybody, perhaps
DTLS 1.4 should update the RecordNumber structure accordingly and save a
few bytes in the ACKs. :-)


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