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

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

Return-Path: <trevp@trevp.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B8E1A00BE for <tls@ietfa.amsl.com>; Fri, 8 Aug 2014 14:55:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 d1s0OmFGOFtj for <tls@ietfa.amsl.com>; Fri, 8 Aug 2014 14:55:20 -0700 (PDT)
Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B247C1A00B0 for <tls@ietf.org>; Fri, 8 Aug 2014 14:55:20 -0700 (PDT)
Received: by mail-ie0-f171.google.com with SMTP id at1so7220758iec.30 for <tls@ietf.org>; Fri, 08 Aug 2014 14:55:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=h4Nz9OQyQ8CeI0ORYw6LJynClBE3tfYfT2T/2Y0leH8=; b=cr/DAcWQYchVuGBEHHWdvoP+GoFBBnXWoGJsWGcTVJq+sA6ArnDx4ut/Urpxj7DJ1j q5s7PsACwuGAqHcc8iUepkX/NMNRyPHQUmxXeaE0GaOZo72z0eWD51cfsXa5wTiiUPW/ NtwMVwhIpjNvi6KblR9UAT8UaGusUjt0mupslQFFcmCSOzGkE9s0HeTf02YD/J2SOnBG ANbdtPs23bfICJCdaR15DFK9+QAORuOhMw/lOThGZdUKafuESFrcNQz7neVlbdPvhB2A Kk4PaP3ezFQ/341DqHQ+0nKlJ6UGCJAl9gk9HY/9g6dhInsh50yovTZvHPNka0c1Lt1E 35hA==
X-Gm-Message-State: ALoCoQk7oLjHXupSLzv4S3Gza+BsXCf/SD+YNWVUMyoYWCSrSEU57yAFm/Ywo/vtr93pFWaBnUHa
MIME-Version: 1.0
X-Received: by 10.42.109.79 with SMTP id k15mr16109592icp.42.1407534919908; Fri, 08 Aug 2014 14:55:19 -0700 (PDT)
Received: by 10.107.133.154 with HTTP; Fri, 8 Aug 2014 14:55:19 -0700 (PDT)
X-Originating-IP: [70.36.227.134]
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, 8 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)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 08 Aug 2014 21:55:22 -0000

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