Re: [TLS] Key Control Vulnerability in SRP (Triple Handshake Variant)

Trevor Perrin <trevp@trevp.net> Fri, 08 August 2014 21:55 UTC

MIME-Version: 1.0
In-Reply-To: <184302E9-0674-49FE-B0E5-3D356404573F@inria.fr>
References: <79E82046-616E-4179-8CF6-12126DDE4640@inria.fr> <DB3BE984-3839-4681-97B2-C874C5154DC1@inria.fr> <CAGZ8ZG3=xE5xv1oVAaL1Yxc-sm4ZuA+N++E5xt_QrMLYqR+Edw@mail.gmail.com> <184302E9-0674-49FE-B0E5-3D356404573F@inria.fr>
Date: Fri, 08 Aug 2014 14:55:19 -0700
Message-ID: <CAGZ8ZG36jYHnV7kUatU5aYKUxLhLwpX1fZ_6=sp01Hd+87aaPQ@mail.gmail.com>
From: Trevor Perrin <trevp@trevp.net>
To: Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uQ7WYry02-29JYbsigmVv2wYuHQ
Cc: "TLS@ietf.org (tls@ietf.org)" <tls@ietf.org>
Subject: Re: [TLS] Key Control Vulnerability in SRP (Triple Handshake Variant)
Precedence: list

On Fri, Aug 8, 2014 at 2:11 PM, Karthikeyan Bhargavan
<karthikeyan.bhargavan@inria.fr> wrote:
>
> The observation here is meant to document that TLS-SRP (not just TLS-RSA and TLS-DHE) also
> allows key control, but that this can be easily avoided by some cheap implementation checks.

Maybe, but you said yourself this would "require more analysis".

I think if a protocol like TLS is going to reuse a session key, it's
the protocol's job to ensure this is safe.  There are generic ways to
do so (e.g. hashing the transcript into session key).

So I'm not convinced we should be going through the math of all key
agreements and trying to tweak them for an unusual property like "key
control".

Trevor

[TLS] Key Control Vulnerability in SRP (Triple Ha… Karthikeyan Bhargavan
Re: [TLS] Key Control Vulnerability in SRP (Tripl… Trevor Perrin
Re: [TLS] Key Control Vulnerability in SRP (Tripl… Karthikeyan Bhargavan
Re: [TLS] Key Control Vulnerability in SRP (Tripl… Trevor Perrin