IETF Logo Mail Archive

Re: [Dance] TLS extension in Certificate (in TLS 1.3)

Shumon Huque <shuque@gmail.com> Mon, 10 July 2023 15:06 UTC

Return-Path: <shuque@gmail.com>
X-Original-To: dance@ietfa.amsl.com
Delivered-To: dance@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CF0C1595FD for <dance@ietfa.amsl.com>; Mon, 10 Jul 2023 08:06:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 NPcaUx-Qr6u6 for <dance@ietfa.amsl.com>; Mon, 10 Jul 2023 08:06:37 -0700 (PDT)
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 A8504C1527A6 for <dance@ietf.org>; Mon, 10 Jul 2023 08:06:37 -0700 (PDT)
Received: by mail-io1-xd32.google.com with SMTP id ca18e2360f4ac-785ccf19489so227703039f.3 for <dance@ietf.org>; Mon, 10 Jul 2023 08:06:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689001597; x=1691593597; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=bPYbnvKhE+zcbNQtz4IglOjeKmiUt97CopYwVMuMFvQ=; b=I3ZdaamvqkSwRZ9xsPV+DtS+4pBWvEYhYlTS0FxhHL9e0DJ4U1eZj2sJCKRV3SRM5Q B3FwIsWfnwvw54MhAwa0CtcxXMmYyRsibJfsZD8J2kfkqMH32lyzn5ZeKUloubgJEJeL hPfvTAowIgKAy30nCteWqFi+IgW1Tdl/xdFyKzQMFVMiIQfZV0t3MwUZ1AXusAArAJfF NUGPlh6bpostKkD1EKhOL7ANfJEp4dTMUVxKTkYMggJMqMvlBFFHGEIbhYhudC/as4nb vBpSO3+p0R65l466sUlR0qLAkGIVv4mrT60z3Et9DiT0djj3QUGIO6vVfcv+2b+pMLkS jXSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689001597; x=1691593597; h=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=bPYbnvKhE+zcbNQtz4IglOjeKmiUt97CopYwVMuMFvQ=; b=h2j/Ec1JZkvTaMtKziK3HtasJqpOrUr/wWpbXibn/3HOKeCOg279txaQWbHZUv+/kF swAiUyQeXhJqckyiqoJ4uE+5aJp1u8rBMpRCHeJnK4Epin55QU3sJlmdVbVNpbyok1qM 1O1oBF1hkZSwmPQw0TFGYDkIFzPMrNQQxQmXA7nEKNLg5cMMySLO77LcIKYcoL+3wxqr 0SXOvy5ybX5+b0B4qfsq1s4LuXx8lOTJGuF502fsJqqwkiEiZWQbZXLwc+ubMqPyRVq9 7vjnwzFCqN1RsamJheONXagc4MFy5tdSN1Nlmbg9K2UHVcLKTA6H07HyfYg90MLVCY2D SV9g==
X-Gm-Message-State: ABy/qLbZXH6g75n+k34BmFagumMGHnieP2/t0+lsrFAUaTZVUI16Bh9y /+hlgtShQ75K7E48YaSnFdnjb0FcPEvOv0zf8cA=
X-Google-Smtp-Source: APBJJlGfE2co6lQGBjAGVy3F3XZRhCIYkltzMk6z8ZpS7yh4GJ1EJReYCiQjSTQOWKn+PHL2d+rgvFp7xR7s2Mk5O+8=
X-Received: by 2002:a6b:e30c:0:b0:785:d0d7:3304 with SMTP id u12-20020a6be30c000000b00785d0d73304mr12803253ioc.14.1689001597012; Mon, 10 Jul 2023 08:06:37 -0700 (PDT)
MIME-Version: 1.0
References: <20221113204902.GB31968@openfortress.nl> <816150.1668386158@dyas> <20221114083400.GB1156@openfortress.nl>
In-Reply-To: <20221114083400.GB1156@openfortress.nl>
From: Shumon Huque <shuque@gmail.com>
Date: Mon, 10 Jul 2023 11:06:25 -0400
Message-ID: <CAHPuVdUkN9M_W=6yhc6w_x2Fh=t9ytcgjaVZ6Nc9MPZ7+Mu8yw@mail.gmail.com>
To: Rick van Rein <rick@openfortress.nl>, Michael Richardson <mcr+ietf@sandelman.ca>, dance@ietf.org
Content-Type: multipart/alternative; boundary="000000000000370fe20600235406"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dance/rWEB1ErWXfA6M4mRRTIUgL1JSJI>
Subject: Re: [Dance] TLS extension in Certificate (in TLS 1.3)
X-BeenThere: dance@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DANE Authentication for Network Clients Everywhere <dance.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dance>, <mailto:dance-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dance/>
List-Post: <mailto:dance@ietf.org>
List-Help: <mailto:dance-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dance>, <mailto:dance-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Jul 2023 15:06:38 -0000

On Mon, Nov 14, 2022 at 3:34 AM Rick van Rein <rick@openfortress.nl> wrote:

> Hi,
>
> > I thought we sent the dane_clientid extension in the Hello.
>
> The current lyrics state
>
>     In TLS 1.2, the client extension is sent in the ClientHello
>     message. In TLS 1.3, it is sent in the Certificate message.
>
> The next sentence is a syntactic impossibility,
>
>     Additionally, in TLS 1.3, the client is only permitted to
>     send the extension if it sees the corresponding empty
>     extension in the server's CertificateRequest message.
>
> -Rick
>

Rick,

I think you've misunderstood.

In TLS 1.3 the extension from the client side is sent in the Certificate
Message (not the ClientHello) which comes *after* the CertificateRequest
message from the server side. So the client will have seen the
advertisement of this extension from the server before deciding to send it.
This behavior is required by the spec. See RFC 8446, Section 4.4.2, which
says "Extensions in the Certificate message from the client MUST correspond
to extensions in the CertificateRequest message from the server."

Shumon.

v2.23.0 | Report a Bug | By Email