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

From: Shahin Noursalehi <[email-masked]>
Date: Thu, 5 Feb 2015 12:47:17 +0330

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 6 Feb 2015 18:32:31 +0200

> secret", ClientHello.random + ServerHello.random)

TLS 1.3 fixed a mistake (security problem) in this, it is now:

master_secret = PRF(pre_master_secret, "handshake master secret",
hash(handshake))

> So, our offered method of calculation of master_secret will convert

You don't need multiple premaster secrets. One could just end the
certificate chains in common host key. This way one only needs a
new certificate format and no other changes to TLS. It would also
work in earlier versions.

Of course, it seems doubtful to me that multiple certificate
chains are useful.

-Ilari

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Fri, 6 Feb 2015 18:07:57 +0100

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 <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Russ Housley <[email-masked]>
Date: Fri, 6 Feb 2015 21:21:18 -0500

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

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Sat, 7 Feb 2015 08:45:08 +0100

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.

---

From: Shahin Noursalehi <[email-masked]>
Date: Sat, 7 Feb 2015 11:59:20 +0330

sorry, I am new in ietf. it seems I should reply-all.

Thanks for all valid comments & updates,,

about migration from TLS 1.2 to 1.3 and higher, while we focus on the
value of "pre_master_secret", the idea is still valid:

master_secret = PRF(multiple_pre_master_secret, "handshake master secret",
hash(handshake))

I think this could simply makes itself compatible with old versions of
TLS too. new versions of TLS in client side could understand it from the
amount of received public keys (from server) after beginning the
handshake phase and then run the proper routines. I have implemented
this idea in lab. I only see an over-load in key-exchange phase.

The goal of getting multiple certificate authorities involved in a TLS
session is *mitigating the problems of implementation* - not more
privacy by improvement in maths behind TLS. as you know better, human
mistakes/ attacks based on social engineering always threatens a good
implementation.

Anyway, this would be an optional process - so abides by the policies
of QoS too. After 2014, enterprises may look for a method that reduces
the risk of being victim of "fake SSL certificate issuers" or those
who "put a backdoor in RSA key-pairs". When we have sensitive data,
the cost among benefits is nothing. Sometimes a simple email in
internet among a patient and a physician that contains some critical
health information may jeopardize his/her life style and can not
roll-back.

~ Shahin

On 2/7/15, Karthikeyan Bhargavan <[email-masked]> wrote:
> 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)....)
> However, I would be wary of changing the TLS state machine in so substantial
> a way without sufficient formal analysis.
>
>
>> To adapt the multiple PMS design to (EC)DHE would require more work, and
>> it is not clear what the benefit would be.
>>
>> -Karthik
>>

---

From: Hanno Böck <[email-masked]>
Date: Sun, 8 Feb 2015 10:43:57 +0100

On Sat, 7 Feb 2015 11:59:20 +0330

> health information may jeopardize his/her life style and can not

I don't understand how your proposal makes "fake ssl certificate
issuers" less likely.

You propose to use two keys signed from different CAs. However, in what
way does this make it less likely that a completely different CA may
issue a rogue cert for the same domain? The attacked user will never
see your two keys.

If you want to make fake ssl certificates less likely you should use
key pinning (right now only available for https, unfortunately not for
other protocols) and certificate transparency. I don't see what your
proposal adds to that.

Also I don't understand your threat scenario "put a backdoor in RSA
key-pairs". What do you mean by that? I know that there are some CAs
that provide to create the key for you. If you are worried about that
just don't do that. Use CSRs and create the key yourself.

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: [email-masked]
GPG: BBB51E42