Re: [TLS] [Technical Errata Reported] RFC8446 (5483)

David Benjamin <davidben@chromium.org> Mon, 05 August 2019 14:46 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 1F2DD12022C for <tls@ietfa.amsl.com>; Mon, 5 Aug 2019 07:46:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.298
X-Spam-Level:
X-Spam-Status: No, score=-9.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.201, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 iW6Ium9HIr-i for <tls@ietfa.amsl.com>; Mon, 5 Aug 2019 07:46:45 -0700 (PDT)
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAD5C120230 for <tls@ietf.org>; Mon, 5 Aug 2019 07:46:44 -0700 (PDT)
Received: by mail-qk1-x730.google.com with SMTP id r6so60302339qkc.0 for <tls@ietf.org>; Mon, 05 Aug 2019 07:46:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sozGV2/Fgur+GyPwkTKu/IYobJaOWeN5dT313+hpp7I=; b=mZZH0JLmK0pJlIYy2Y78cawJS8Pvbxz4lESUO1TwULDMDi17TYYb8yjsp5OObvflCP dIDj8YB6sQh9rJrrV7TxU9ij30Yre3hUs28LAwK5WYtthrTwXcRpyP4w3dyZOt5h/IMi i+pOGGgdOVkZDTRVgC5mPCzYViP2rHfmjt1wk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sozGV2/Fgur+GyPwkTKu/IYobJaOWeN5dT313+hpp7I=; b=U8vriT5QzDD9y5YbxIU9tS74cDpcFt35h51pmyP6DFAZOdCCFm1m5h+kA46HXIu3Qq xf+upZSta+HiFU0EXSYpiz9UTnEVt27dfj4gzhGJoDuEM/fas1eXp7TZPv2TfayFglIf o6hbmq6TKaIdroOCAcZiXRYKhmDyw1FXBUsbJPXlmd642F26Snor2Hilw83XUMWIVmwx kbVNWtnGNKx5pZPtyFSwRlH7vZOodUCZjZDoTzJP1WByo1YzmIujX4u7Q08MJH+2OsyC Qn299NdTn0iZQN/DKDhUd38EAPYM6eXfUPfAwJ8gclTnbUwZGSgAGqfmQtAY9pP3lfQd d3qg==
X-Gm-Message-State: APjAAAXu9GvoupYzIaJsep53W8Q0+vwwZRf4tbIKm6/Qs6XMOwcEx4Sb NYL5/p58FXJOmyqoNlzUqc+NgiTk90ormgHBSbVmrZlp+Txq
X-Google-Smtp-Source: APXvYqzTRJHbzWQwh9aWB84hvFCTAjZQtSySLhsH0LNyRYsUAzalVBCrdQrDiZkmyp6j0+SkI8qevW3Rgi1HviGJJKk=
X-Received: by 2002:a37:7704:: with SMTP id s4mr101667040qkc.310.1565016403684; Mon, 05 Aug 2019 07:46:43 -0700 (PDT)
MIME-Version: 1.0
References: <20180828032952.70F7CB81122@rfc-editor.org> <CAOCq7P=AUwY+-YKXvRjKrfZJavY09O0ynrJdWbc8nJ5NUbDxbA@mail.gmail.com>
In-Reply-To: <CAOCq7P=AUwY+-YKXvRjKrfZJavY09O0ynrJdWbc8nJ5NUbDxbA@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Mon, 5 Aug 2019 10:46:27 -0400
Message-ID: <CAF8qwaA4-t_y9uX06HVF7AKjfY-kjaf35d_g_kjnaE0VAJKEgA@mail.gmail.com>
To: Patrick Kelsey <pat.kelsey@notforadio.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000cf98ba058f5fc6b2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/fkiv9vN2iyanhw0UOXXSbyBClic>
Subject: Re: [TLS] [Technical Errata Reported] RFC8446 (5483)
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, 05 Aug 2019 14:46:47 -0000

There are two scalar multiplications involved. The first, as part of key
generation, indeed passes in a known constant to the u value and outputs
the byte string that goes into the key share. The second, the ECDH
operation itself, passes in the peer key share and results in the shared
secret. In the first call, the key share is the output. In the second, the
key share is the input.
https://tools.ietf.org/html/rfc7748#section-6.1

But I agree it's not particularly clear. Perhaps it should have said
something like:

For X25519 and X448, the contents of the public value are the K_A
and K_B values described in section 6 of [RFC7748]. This is 32 bytes
for X25519 and 56 bytes for X448.

On Mon, Aug 5, 2019 at 9:43 AM Patrick Kelsey <pat.kelsey@notforadio.com>;
wrote:

> I brought this up to Ekr at IETF 105, and he said he hadn't seen this
> particular errata, so here's a bump to the top of the list.
>
> As it's now been about a year that this errata has remained in the initial
> state, I think it might be worth having a look at and advancing to the next
> state, if for no other reason than avoidance of the mistaken external
> impression that there is longstanding uncertainty about a report that part
> of the document says that a private key is to be put on the wire.
>
> -Pat
>
> On Mon, Aug 27, 2018 at 11:30 PM RFC Errata System <
> rfc-editor@rfc-editor.org>; wrote:
>
>> The following errata report has been submitted for RFC8446,
>> "The Transport Layer Security (TLS) Protocol Version 1.3".
>>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata/eid5483
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Patrick Kelsey <pat.kelsey@notforadio.com>;
>>
>> Section: 4.2.8.2
>>
>> Original Text
>> -------------
>> For X25519 and X448, the contents of the public value are the byte
>> string inputs and outputs of the corresponding functions defined in
>> [RFC7748]: 32 bytes for X25519 and 56 bytes for X448.
>>
>> Corrected Text
>> --------------
>> For X25519 and X448, the contents of the public value are the byte
>> string outputs of the corresponding functions defined in [RFC7748]: 32
>> bytes for X25519 and 56 bytes for X448.
>>
>> Notes
>> -----
>> Per Section 7.4.2 of this RFC and Section 6 of RFC7748, the byte string
>> inputs to the corresponding ECDH scalar multiplication function are the
>> private key and the u-coordinate of the standard public base point, the
>> former of which of course must not be transmitted and the latter of which
>> is a known constant.
>>
>> >From another perspective, including the byte string inputs in the
>> contents of the public value would contradict the resulting content sizes
>> given at the end of the cited paragraph as well as the statement in Section
>> 7.4.2 that the public key put into the KeyShareEntry is the output of ECDH
>> scalar multiplication function.
>>
>> Instructions:
>> -------------
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party
>> can log in to change the status and edit the report, if necessary.
>>
>> --------------------------------------
>> RFC8446 (draft-ietf-tls-tls13-28)
>> --------------------------------------
>> Title               : The Transport Layer Security (TLS) Protocol Version
>> 1.3
>> Publication Date    : August 2018
>> Author(s)           : E. Rescorla
>> Category            : PROPOSED STANDARD
>> Source              : Transport Layer Security
>> Area                : Security
>> Stream              : IETF
>> Verifying Party     : IESG
>>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>