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

To obtain your multi-certificate guarantee as an extension to the standard TLS 1.3 (EC)DHE exchanges, you do not need multiple pre-master secrets. The server could send multiple Certificate and CertificateVerify messages, all of which sign the same handshake, that is, the same client and server keyshares. So, unless all the signing keys were compromised, the attacker cannot hijack the connection (since he cannot tamper with the server’s keyshare).

So a single PMS = KDF(g^xy + …..(handshake hash)….) 
but multiple server signatures over the handshake with different signing keys.

However, I would be wary of changing the TLS state machine in so substantial a way without sufficient formal analysis.

On 06 Feb 2015, at 18:07, Karthikeyan Bhargavan <karthik.bhargavan@gmail.com> wrote:

> This scheme seems to assume an RSA key exchange which no longer exists in TLS 1.3.
> 
> To adapt the multiple PMS design to (EC)DHE would require more work, and it is not clear what the benefit would be.
> 
> -Karthik
> 
> 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