Re: [TLS] Comment on draft-sullivan-tls-opaque-00

steve@tobtu.com Fri, 30 April 2021 03:43 UTC

Return-Path: <steve@tobtu.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 9FD643A0BAA for <tls@ietfa.amsl.com>; Thu, 29 Apr 2021 20:43:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 mQXbWosM0PAc for <tls@ietfa.amsl.com>; Thu, 29 Apr 2021 20:43:03 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 079C53A0BA5 for <tls@ietf.org>; Thu, 29 Apr 2021 20:43:02 -0700 (PDT)
Received: from oxusgaltgw04.schlund.de ([10.72.72.50]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0LjYVi-1l13Mb0EcS-00bdyN; Fri, 30 Apr 2021 05:43:01 +0200
Date: Thu, 29 Apr 2021 22:43:00 -0500 (CDT)
From: steve@tobtu.com
To: "tls@ietf.org" <tls@ietf.org>
Message-ID: <990284223.270884.1619754180584@email.ionos.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v7.10.4-Rev20
X-Originating-Client: open-xchange-appsuite
X-Provags-ID: V03:K1:611MEfwcrAYsx5SpycCLtzd12BSW2+Q7SAcyFhdkBwleaDwEJzF f+GNBuvPy4t1R8cCssP+1yfslCedOMGK30eSOcl2p/C3Fk4Ih1vbpw0M1TnBZjCmrpDur7L Z4hsCyXOwvObQNi0DGH9EOybVY5a0A16IlTrEhR+wWatGBlnSHXiapGCHqqnSzg8fg8r6Rv jwY7VteqRyBdE8oe1JYTQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:DattTHC5j60=:1OPyoeHAXu0R4j4SVDbLcD xgLfo2mNMc4OftAwMX9OXW+32SbEw4XjO+61tP80qAz1vSP7vV2HpSnIxL9LCPnR0SJlH37Lw WOzi6NF6O6kq0kfvobxVQkDiDx64CsRwrhMZ1XPBQXaCM8ROkVJBgx38amZZaiwf6OCPihIIh 4ChmbEn3JH4LiIYGWdW46fJjnaWXxpH7mM9mJu173Xq+k/yWKlKt/xZo2rB/NpOKKGONp3CIo RpsWnqEXmMmGb+xHq2617MuRtLApu4Rj7F2H8+ZAk9S2n6pu76gHKUYI/lFEycVS92dGhkSts YZCvVw++ZjVkYX1nm2Xfsa6FQ8cbZZTxEp8yLe5wZC1m4RE6/2yEp8+HHy3TMPeAa/Zfmo9QV nuXqQOXf3yHFftflG7g9wRjk8IOR8YSp2ajEDdmMPz4gaew43aHpnS4g4fLZajS3j7wPq8P0F Besej80cXI++P7+iptNMlkilUthfAqiVp9lY/qq7gTdCpO4VBgRNkh+3L4sE0GDMPb5ZZvPEr Rcv6HQCVZIbyK8/8outiLs=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/fXIV3B-ANDEef63Vvyi_ZLhxZ6w>
Subject: Re: [TLS] Comment on draft-sullivan-tls-opaque-00
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: Fri, 30 Apr 2021 03:43:08 -0000

On 04/08/2021, 14:43, "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com> wrote:
> 
> I am glad that someone in the working group is looking at this.  However, as I reviewed this before the wg meeting, I was completely puzzled by this text (from section 6.1):
> 
> 3DH
> 
>    C computes K = H(g^y ^ PrivU || PubU ^ x || PubS ^ PrivU || IdU || IdS )
>    S computes K = H(g^x ^ PrivS || PubS ^ y || PubU ^ PrivS || IdU || IdS )
> 

There are three errors in this the two you pointed out and the third term. The correct K calculations for 3DH are:

C computes K = H(g^y ^ PrivU || PubS ^ x    || g^y ^ x || IdU || IdS)
S computes K = H(PubU ^ y    || g^x ^ PrivS || g^x ^ y || IdU || IdS)

Where C has x, g^y, PubS, PrivU and S has y, g^x, PubU, PrivS. Which are calculated like:
g^x = g ^ x        (yes I know it's bad to name it like
g^y = g ^ y         this, but that's how they did it)
PubS = g ^ PrivS
PubU = g ^ PrivU

Although the terms can be in any order and I don't speak for them, but those are the correct terms with matching counterparts.

> Obviously these needs to be the same for an honest client-server pair.  I can't see where the above variables are defined in the doc; I would assume that the meanings are:
> 
> 
>   *   x, y are the private values from the ephemeral DH operation, and are randomly selected for each exchange.
>   *   PrivU, PubU, PrivS, PubS are static values from the Opaque record.
> 

That's how I read it.

> However, if that's the case, I can't see how that could work; for one, g^y ^ PrivU and g^x ^ PrivS would be different values, and so differing values would be stirred into the Master Secret.  In addition, I can't see how PubU ^ x (where PubU and x would appear to be client specific) could be expected to be the same as PubS ^ y (as both those values would be server specific).
> 
> What am I missing?
> 

Those are actual problems. As a side note 3DH looks like this where each straight line is a DH calculation (hopefully those two lines look like they make an "X"). i_* being their identity public-private key pairs (PrivU, PubU, PrivS, PubS) and e_* being their ephemeral public-private key pairs (x, g^x, y, g^y).

i_c       i_s
   \     /
     \ /
     / \
   /     \
e_c ----- e_s