Re: [Secdispatch] [Lake] LAKE next steps

Phillip Hallam-Baker <phill@hallambaker.com> Tue, 27 August 2019 20:23 UTC

MIME-Version: 1.0
References: <20190820155006.GE60855@kduck.mit.edu> <161a5af2-b357-e1bf-44dc-cc3198e3b939@gmail.com> <20190826202430.GL84368@kduck.mit.edu> <1ffee1b1-7cd5-67ea-e411-90dc2c72bfb4@gmail.com> <5713907E-48A8-4C6E-A7CC-19D7772ADC11@gmail.com>
In-Reply-To: <5713907E-48A8-4C6E-A7CC-19D7772ADC11@gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Tue, 27 Aug 2019 16:22:55 -0400
Message-ID: <CAMm+LwjHYfg_=rW3JB8DdpZv7b6PSpbf_X70nqOaY9OXtNDE=g@mail.gmail.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Cc: Rene Struik <rstruik.ext@gmail.com>, lake@ietf.org, IETF SecDispatch <secdispatch@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>
Content-Type: multipart/alternative; boundary="0000000000005a4dcf05911f0ae4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/jXhqxLF-2v2mBrb_8KwB-AWcjKE>
Subject: Re: [Secdispatch] [Lake] LAKE next steps
Precedence: list

On Tue, Aug 27, 2019 at 12:46 PM Yoav Nir <ynir.ietf@gmail.com> wrote:

> Hi, Rene
>
> On 27 Aug 2019, at 6:21, Rene Struik <rstruik.ext@gmail.com> 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.

[Secdispatch] LAKE next steps Benjamin Kaduk
Re: [Secdispatch] [Lake] LAKE next steps Rene Struik
Re: [Secdispatch] [Lake] LAKE next steps Göran Selander
Re: [Secdispatch] [Lake] LAKE next steps Benjamin Kaduk
Re: [Secdispatch] [Lake] LAKE next steps Rene Struik
Re: [Secdispatch] [Lake] LAKE next steps Yoav Nir
Re: [Secdispatch] [Lake] LAKE next steps Phillip Hallam-Baker
Re: [Secdispatch] [Lake] LAKE next steps Rene Struik
Re: [Secdispatch] [Lake] LAKE next steps Benjamin Kaduk
Re: [Secdispatch] [Lake] LAKE next steps Benjamin Kaduk