Re: [Secdispatch] [Lake] LAKE next steps

Phillip Hallam-Baker <> Tue, 27 August 2019 20:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 827C2120129; Tue, 27 Aug 2019 13:23:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Irzkd0m5g89a; Tue, 27 Aug 2019 13:23:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F12FB1200DE; Tue, 27 Aug 2019 13:23:07 -0700 (PDT)
Received: by with SMTP id p23so485841oto.0; Tue, 27 Aug 2019 13:23:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2IZBtl3JbKpyWVg2eAwnY2e34foPJIal/OkoVxOuiGs=; b=D3TrZcwLv6qDj+M2DpqZY2lAq6bTeEYly0MZupvVKpCC2dujyGwzB3lHzFn1AwWSs/ QwKqaGozRKb7XOb65+ryCSO3v7RgoE14V7Pd1os3/AEB13GfF4OUpkESc2zq0ixHcaau nYWERHkbq44q3vPXeQ2F3cO+dmzkvYJ4ZhVxDjSFLsZI1zkixi6X0Pq8PB5YskluIsFf ehCMmr76qoQLeSHwOeHPYWiBVsKNP5hs0QCEx0lzbBnK3zpf3aAkaKY8Z5+3ez8DElom SZFGYhspe2BWHg4a2lpQqt6llufiFCG9Z7ddqmDj/MyPVS8SnX7Na6F2+e76MHHfZIbM +YUQ==
X-Gm-Message-State: APjAAAWgL55bjGYBoeVdWw3mZDYhkKQTrYU1fOVN7bbV+zIKPMk+wXDu 2ly1ZL08s9Yg8LIsYzaRnc3EGJyZxvKmtzlmKBs=
X-Google-Smtp-Source: APXvYqxVpXQRX2OYGSnNVEmwZx1CM7zKW7yaMGWNyfid08nPTt8hOBojVXLVkqazBiQOY3CC/2wUS04QbHgncr+OHDg=
X-Received: by 2002:a9d:4a3:: with SMTP id 32mr376753otm.37.1566937387253; Tue, 27 Aug 2019 13:23:07 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Phillip Hallam-Baker <>
Date: Tue, 27 Aug 2019 16:22:55 -0400
Message-ID: <>
To: Yoav Nir <>
Cc: Rene Struik <>,, IETF SecDispatch <>, Benjamin Kaduk <>
Content-Type: multipart/alternative; boundary="0000000000005a4dcf05911f0ae4"
Archived-At: <>
Subject: Re: [Secdispatch] [Lake] LAKE next steps
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Aug 2019 20:23:10 -0000

On Tue, Aug 27, 2019 at 12:46 PM Yoav Nir <> wrote:

> Hi, Rene
> On 27 Aug 2019, at 6:21, Rene Struik <> wrote:
> RS>> (Technical.) It would be prudent for IETF not to put too many eggs in
> the same basket and, thereby, not have most protocols share the same crypto
> design philosophy, protocol flow framework, and instantiation. While
> arguably convenient, this is contrary to algorithm agility requirements
> (since results in in-tandem vulnerabilities and easily ossified code).
> I disagree with this.  It is not the IETF that is putting many eggs in one
> basket, but the market. It is the market that is protecting every piece of
> privacy-sensitive information using TLS: financial transaction, bank
> statements, credit cards, school transcripts, medical appointments and test
> results, email in transit to name but a few.
> If TLS is compromised, all of that is compromised, and the fact that SSH
> or IPsec or some new OSCORE thing exist does not help me or anyone else
> whose personal information is now exposed.  If TLS is compromised we’ll
> have to fix TLS.  So regardless of what we decide at the IETF, a whole lot
> of our eggs are already in one basket. It’s a better use of our resources
> to make sure that basket is protected than to spend them on making a new
> basket that hardly anyone will use.

My problem with using the TLS exchange is that we are still doing key
exchange using a signature for authentication like we did in SSL when the
whole protocol was predicated on use of RSA.

We have got rid of the RSA but we still demand that we use a signature to
authenticate the exchange which means that we leave non-repudiable evidence
that an exchange took place. Maybe not significant in TLS (I think it is
though) but certainly a concern in other areas.

There is another approach which is to make the exchanged secret dependent
on the supplemental information that we want to authenticate. So that the
key exchange will succeed if and only if both sides get the same
information. I believe this is what is done in Signal.