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

Patrick Kelsey <pat.kelsey@notforadio.com> Mon, 05 August 2019 15:23 UTC

Return-Path: <pat.kelsey@notforadio.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 9558E120162 for <tls@ietfa.amsl.com>; Mon, 5 Aug 2019 08:23:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=notforadio.com
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 rWtCtj41TSBF for <tls@ietfa.amsl.com>; Mon, 5 Aug 2019 08:23:53 -0700 (PDT)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 0E79C1200F3 for <tls@ietf.org>; Mon, 5 Aug 2019 08:23:53 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id m8so46035454lji.7 for <tls@ietf.org>; Mon, 05 Aug 2019 08:23:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=notforadio.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=voZD3V6aaL4eDkUBibmIwPwCzqgGa89auwXeR1bBcKU=; b=biDNF+ATpMY1lPOqP7rB8S0nsfqlPhrjlGlx4fZQgSKj8G5S76U4J0wea90WeoBGlh S3Y4SqwZjHZVOZPT0LHwmDAkk4DlgEaa6qna/hOUKUHIb5Hd9I9TqcfWByu4rsJ3d6wa VXBDusWXyh0kCrEfbt4roxGKqZSP9BvFXOmDk=
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=voZD3V6aaL4eDkUBibmIwPwCzqgGa89auwXeR1bBcKU=; b=NiEFV5Ykj4Inl+COCJ7DpL9s6+QY0UrfAVO+KOKzV8iPZPJPk5twk/AMRzxzc6CZSA 8fDfMjewb0fr9SOtDQ88Ikyv48IdwE854y0joMg8NhEIp8s4tavt6K7UTIkgTUgmUst3 ku0Yxs0MiLR3QBzvuIRk5jFZ9U5tl8Izy3CwUfBiXQI6RL/gwBCBAaEzr5ZJywOU+V9S HyZt3eZHsIPuenWMX1mfsJuNh/Szj8BRPMUIrgzyXOqYy38Ck6tTLLed5xq0hUZ/CQja bOYyxi7z6EYyB6y+sC9YUdxix8nFRhZ4pMf9ASF8zUIVc4/Ovch1XiQEH7sARqL4/xbX eL8g==
X-Gm-Message-State: APjAAAULy2CuC/tJkcGIV0yk5AjVNQZOlPVs3iK5ZWjyrXFiETNZBQIS r0rooKr4JjbiAIX7RaBl2JR5eJ8uZbaa8oDlRDb/nQ==
X-Google-Smtp-Source: APXvYqzzvpxHz0m+ATd0UicqKwZCEBYFtkFF4sig8GMbzp71CzDq0er1wD8Sotw0oK+cCgXGSUAQ6gOvv215mLsInrw=
X-Received: by 2002:a2e:89ca:: with SMTP id c10mr63127279ljk.106.1565018630984; Mon, 05 Aug 2019 08:23:50 -0700 (PDT)
MIME-Version: 1.0
References: <20180828032952.70F7CB81122@rfc-editor.org> <CAOCq7P=AUwY+-YKXvRjKrfZJavY09O0ynrJdWbc8nJ5NUbDxbA@mail.gmail.com> <CAF8qwaA4-t_y9uX06HVF7AKjfY-kjaf35d_g_kjnaE0VAJKEgA@mail.gmail.com>
In-Reply-To: <CAF8qwaA4-t_y9uX06HVF7AKjfY-kjaf35d_g_kjnaE0VAJKEgA@mail.gmail.com>
From: Patrick Kelsey <pat.kelsey@notforadio.com>
Date: Mon, 5 Aug 2019 11:23:39 -0400
Message-ID: <CAOCq7P=Pf9koGOY-Ks2GD9p1PZCjMkfX95Q7hmogx9LeM9UEKA@mail.gmail.com>
To: David Benjamin <davidben@chromium.org>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000912db3058f604b4a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/bjSOpGaEkwPp3j9BP_OwQmyyq3M>
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 15:23:56 -0000

Fair point that there are two scalar multiplications involved on either
endpoint in the course of the exchange, that what is being referred to in
this section of RFC8446 is the first one, and that some readers might find
ambiguity with respect to this that could be addressed with a different
approach to the correction than I suggested (in my reading of RFC7748, I
found 6.1 clear in establishing that it is the results of the first scalar
multiplication that are transmitted).

If an approach like the one you are suggesting is taken, I recommend
replacing "are the K_A and K_B values" with "is the K_A or K_B value", as
the content of the public value is one of those and not both.

-Pat

On Mon, Aug 5, 2019 at 10:46 AM David Benjamin <davidben@chromium.org>;
wrote:

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