Re: [TLS] Servers respond with BadRecordMac after ClientFinished, sent when PSK+EarlyData

Nick Harper <ietf@nharper.org> Tue, 09 August 2022 15:05 UTC

Return-Path: <nharper@nharper.org>
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 39287C13C50E for <tls@ietfa.amsl.com>; Tue, 9 Aug 2022 08:05:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.923
X-Spam-Level:
X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 NJQpgZqToFrL for <tls@ietfa.amsl.com>; Tue, 9 Aug 2022 08:05:25 -0700 (PDT)
Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) (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 92BD8C13C50D for <tls@ietf.org>; Tue, 9 Aug 2022 08:05:25 -0700 (PDT)
Received: by mail-pl1-f173.google.com with SMTP id 17so11572969plj.10 for <tls@ietf.org>; Tue, 09 Aug 2022 08:05:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RGVNXJwwrrr4AOw7SuufLCWP+HaFIaJsi/Fh2vG0Ue4=; b=BGhgJuT84iE3HKIWro6FwQrSCO5AuD/aLc5oD4k4VsH+0Fz4azthXCJRxLnI7+seNV fOYvaK1wdpQg58noeAgr01/HhFTa5uCUdYgqQWLBFKdzkpUZLQP+L6PsNaaSefL6Wg9F bhnegHK0Ohe8DZAdw2prj/9f2wS6smZZeoR3uRgb9jWSOXbIb7NHoiCjEla2JzrjQ3Dh gw+JQ1ZFLvHp+U+FH6+14AzzIvxikzleSMNS2nHdrO/njVeduhSa5RZsQ+YBs2XNa8Xx r9fN+6/xbTW1J/W6tAKJqQrkdfxOaVLeIWEx/ma6voYH/74q+pfnyF8O/UqlqKAkOkr/ PW2g==
X-Gm-Message-State: ACgBeo0rJFzMMAUeHRpqPvf0c9srrG3ebmD0NUL6YvWsDBSH+ZBMfMnd 82ON6XdYi6rH1UBYlWETochIQG7V+MTaWzlGYlRx6g==
X-Google-Smtp-Source: AA6agR7sulxGMES0YStIA7yintMKUsK8aepTU+pxCpNST4qyLhKVeBFX5q5tUggOcfmFxSHV90Wz90H6cD1mTRpQdhU=
X-Received: by 2002:a17:90b:3b8a:b0:1f5:1df2:1fff with SMTP id pc10-20020a17090b3b8a00b001f51df21fffmr26985702pjb.169.1660057524697; Tue, 09 Aug 2022 08:05:24 -0700 (PDT)
MIME-Version: 1.0
References: <987212E5-9A26-4408-9BD5-2D26FA106D3F@gmail.com> <YvID85L+ICWVh9gi@LK-Perkele-VII2.locald> <311E53EC-C6D0-44F2-BA8E-ED15939ACEF1@gmail.com> <CD226CA9-E0E9-4D7D-80E8-E1F4F9AABD57@gmail.com>
In-Reply-To: <CD226CA9-E0E9-4D7D-80E8-E1F4F9AABD57@gmail.com>
From: Nick Harper <ietf@nharper.org>
Date: Tue, 09 Aug 2022 08:05:13 -0700
Message-ID: <CACcvr=kiajj6Kt0Ek29k9gVAA5D-6M92AHdov06xaVMsf4NJcA@mail.gmail.com>
To: Kristijan Sedlak <xpepermint@gmail.com>
Cc: Ilari Liusvaara <ilariliusvaara@welho.com>, tls@ietf.org
Content-Type: multipart/alternative; boundary="0000000000001111ce05e5d04396"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/a2ojR8yX2ehObK_Leh6avdI3KgE>
Subject: Re: [TLS] Servers respond with BadRecordMac after ClientFinished, sent when PSK+EarlyData
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: Tue, 09 Aug 2022 15:05:26 -0000

That is not the expected behavior. Likely what is happening is the server
(at the http layer) sees the Connection: close header, and goes to close
the socket for the underlying transport (in this case, the tls stack). The
server’s tls stack, when getting that signal, closes the tls connection,
and since it does that before receiving the erroneous client Finished, it
sends Alert(0) and closes the connection on its end.

On Tue, Aug 9, 2022 at 00:55 Kristijan Sedlak <xpepermint@gmail.com> wrote:

> After some sleep, I went playing with the content of the EarlyData sent to
> the server and it turned out that the "Connection: close" header must be
> present in the HTTP1.1 request. After adding it, the error was gone and the
> connection closed with Alert(0).
>
> Is this the expected behavior and Keep-Alieve is not allowed when
> EarlyData is used or it's just the remote server implementation specific?
> If I understand the spec correctly, the behavior of the EarlyData part is
> mostly up to the implementor, and you must know the rules up front, right?
>
> Best,
> Kristijan
>
> On 9 Aug 2022, at 09:05, Kristijan Sedlak <xpepermint@gmail.com> wrote:
>
> Hey Ilari,
>
> thank’s for replying. I did verify the transcript as well. Everything
> seems to be correct. I bet if it wasn't the 1-RTT and 0-RTT(no-early-data)
> would fail too. Something weird is going on only in 0-RTT(early-data) case.
>
> Can you maybe point me to an URL with the correct TLS1.3 implementation
> where I could safely test the client?
>
> Best,
> Kristijan
>
>
> On 9 Aug 2022, at 08:51, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
>
> Ilari
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>