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

[Shahin Noursalehi <[e-mail]>]

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 <[e-mail]> 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)....)
> 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
> <[e-mail]> 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 <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tls
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>
>