Re: [TLS] the idea of using multiple keys with multiple certificate authorities in a TLS session.

Russ Housley <housley@vigilsec.com> Sat, 07 February 2015 02:22 UTC

Return-Path: <housley@vigilsec.com>
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 976BE1A1A38 for <tls@ietfa.amsl.com>; Fri, 6 Feb 2015 18:22:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.773
X-Spam-Level:
X-Spam-Status: No, score=-97.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, FRT_BELOW2=2.154, USER_IN_WHITELIST=-100] autolearn=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 pSPo2yrRrRwH for <tls@ietfa.amsl.com>; Fri, 6 Feb 2015 18:22:15 -0800 (PST)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id D00B91A038D for <tls@ietf.org>; Fri, 6 Feb 2015 18:22:14 -0800 (PST)
Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 2CFB19A41CD; Fri, 6 Feb 2015 21:22:04 -0500 (EST)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id 5PejcZNLtxNd; Fri, 6 Feb 2015 21:21:43 -0500 (EST)
Received: from [5.5.33.218] (vpn.snozzages.com [204.42.252.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 98EDC9A4044; Fri, 6 Feb 2015 21:21:40 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset="us-ascii"
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <CADrAmL6xOMOauSHuTR8BUK7i4NG2Zx3H90dA6k36YMu81pVW0A@mail.gmail.com>
Date: Fri, 06 Feb 2015 21:21:18 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <F4A20E09-130D-4FCB-8763-E85055B763A6@vigilsec.com>
References: <CADrAmL6xOMOauSHuTR8BUK7i4NG2Zx3H90dA6k36YMu81pVW0A@mail.gmail.com>
To: Shahin Noursalehi <mixoftix@gmail.com>
X-Mailer: Apple Mail (2.1085)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/RvhKS09Zm6i6cuZVJ0AQoS1mGpg>
Cc: IETF TLS <tls@ietf.org>
Subject: Re: [TLS] the idea of using multiple keys with multiple certificate authorities in a TLS session.
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: Sat, 07 Feb 2015 02:22:16 -0000

You ideas seem to be based on TLS 1.2 and earlier.  In TLS 1.3, Ephemeral DH or Ephemeral ECDH will be used to produce the session key.  The ephemeral key will be signed, and a public key from the certificate will be used to validate the signature.  This approach offers much better forward secrecy.

Russ


On 05 Feb 2015, at 10:17, Shahin Noursalehi <mixoftix@gmail.com> wrote:

> Dear Sir/Madam,
> 
> Refer to discussions around TLS 1.3 in Linkedin group "Cryptographers
> and Cryptanalysts", contributor experts agree on the idea of using
> multiple keys with multiple certificate authorities in a TLS session.
> So if one certificate authority is compromised hopefully the others
> are not. The suggested solution would be like the process bellow:
> 
> Refer to the way that TLS generates the *master_secret*:
> 
> master_secret = PseudoRandomFunction(pre_master_secret, "master
> secret", ClientHello.random + ServerHello.random)
> 
> We could generate multiple peer-to-peer pre_master_secret(s) for each
> public-key that we receive from the server and XOR them all together.
> So, our offered method of calculation of master_secret will convert
> to:
> 
> master_secret = PseudoRandomFunction(multiple_pre_master_secret,
> "master secret", ClientHello.random + ServerHello.random)
> 
> where:
> 
> multiple_pre_master_secret = XOR(pre_master_secret_1,
> pre_master_secret_2, .. pre_master_secret_n)
> 
> and aim at preventing basic attacks that are known against
> one-time-pad, we could add a circular-bit-rotation(m) to the
> calculation above - each time we do an XOR:
> 
> multiple_pre_master_secret = ROT(XOR(pre_master_secret_1,
> pre_master_secret_2, .. pre_master_secret_n), m)
> 
> Please let us know about your point of views, then we could continue
> discussing the TLS.
> 
> With best regards
> 
> Shahin Noursalehi
> 
> 
> Reference:
> 
> https://www.linkedin.com/groups/what-are-new-methods-attack-3901854.S.5958888203401314306
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls