Hi Illya,
You are actually describing TLS 1.3, especially with recent (proposed)
changes. It uses an extension to negotiate version, looking like TLS
1.2 otherwise. It has the ability to use lighter-weight algorithms,
etc...
On Wed, Nov 8, 2017 at 9:40 AM, Illya Gerasymchuk <giluxonc...@gmail.com> wrote:
> Thank you very much for your answer. So just to be clear, hypothetically, it
> would be possible to define an extension for TLS 1.2 that converts it to TLS
> 1.3 completely, correct? For example, would it be possible, to have an
> extension called TLS_1.2_TO_TLS_1.3 that would define the full handshake to
> be the following, and still be TLS 1.2 compliant? (I just copied the full
> hadshake from the TLS 1.3 draft and added the text in bold):
>
> Client Server
>
> ClientHello
> + TLS_1.2_TO_TLS_1.3
> + key_share -------->
> <-------- HelloRetryRequest
> +
> TLS_1.2_TO_TLS_1.3
> + key_share
>
> ClientHello
> + key_share -------->
> ServerHello
> + key_share
> {EncryptedExtensions}
> {CertificateRequest*}
> {Certificate*}
> {CertificateVerify*}
> {Finished}
> <-------- [Application Data*]
> {Certificate*}
> {CertificateVerify*}
> {Finished} -------->
>
> [Application Data]
> <--------------------------------------> [Application Data]
>
> To give you a little more background for my motivation behind this, the
> topic for my master thesis is "TLS For IOT", the goal of which is to define
> a new version of TLS protocol, which would be usable on low-power,
> low-energy devices, while remaining backwards compatible with regular TLS.
> My idea is to define this new protocol through various extensions (even
> though I had't had a chance to discuss this with my supervisors, since they
> seem to be away). Considering the extension above, I know that I could
> easily define a new protocol that would do something like:
>
>> if TLS_1.2_TO_TLS_1.3 extension present in ClientHello:
>> use my custom protocol (with new messages and some omitted)
>> else:
>> use regular TLS 1.2
>
>
> But would that still be considered TLS Extension Compliant? (if I can remove
> some of the messages not marked as optional in the spec, such as
> ServerHelloDone, then the answer would be yes). The answer to this question
> conditions whether I would need to define 2 separate protocols: one for TLS
> 1.2, one for TLS 1.3 or if I potentially can just define the same protocol
> that could be used by clients and servers supporting both: TLS 1.2 and TLS
> 1.3, by the means of an extension. My main goals would be to limit the
> number of messages sent, the amount of transmitted data, as well as use
> lighter algorithms. Quite a few of the ideas I had initially are already
> implemented in TLS 1.3, so I wanted to migrate a lot of those to clients and
> servers that only support TLS 1.2. I've been reading a lot of RFC's and
> papers about the work done on this topic, but I haven't found any of them
> that does such a thing specifically (removing any of the messages not marked
> as optional).
>
> I'm well aware that I need to be extremely careful when removing messages or
> making any significant changes to the protocol.
>
> Thank you,
>
> - Illya
>
> On Tue, Nov 7, 2017 at 5:56 PM, Eric Rescorla <e...@rtfm.com> wrote:
>>
>>
>>
>> On Tue, Nov 7, 2017 at 6:15 AM, Illya Gerasymchuk <giluxonc...@gmail.com>
>> wrote:
>>>
>>> Greetings,
>>>
>>> I've been reading though various RFCs and couldn't find a definite answer
>>> to my question: can a negotiated TLS extension skip some of the TLS
>>> Handshake messages and still be compliant with the TLS specification? My
>>> goal is to develop a new version of TLS (as part of my Master Thesis work),
>>> while preferably, staying backwards-compatible.
>>>
>>> Here, I will be specifically talking about TLS 1.2, defined in RFC 5246.
>>> Below is a message flow for the full handshake (taken directly from RFC
>>> 5246):
>>>
>>> Client Server
>>> ------ ------
>>>
>>> ClientHello -------->
>>> ServerHello
>>> Certificate*
>>>
>>> ServerKeyExchange*
>>>
>>> CertificateRequest*
>>> <-------- ServerHelloDone
>>> Certificate*
>>> ClientKeyExchange
>>> CertificateVerify*
>>> [ChangeCipherSpec]
>>> Finished -------->
>>>
>>> [ChangeCipherSpec]
>>> <-------- Finished
>>> Application Data <-------> Application Data
>>>
>>>
>>> * (asterisk) Indicates optional or situation-dependent messages that are
>>> not always sent.
>>> Now, I do know that it's perfect legal for a TLS extension to modify the
>>> structure of some message or add a new message, but I'm not sure if one of
>>> the messages, not defined as optional/situation-dependent can be omitted.
>>>
>>> Let me give you a concrete example. Let's say I create a new extension
>>> called XYZ. The client and the server negotiate that extension in the their
>>> extended hello messages. Would it be legal for the XYZ extension to mandate
>>> the server not to send the ServerHelloDone message? As far as I understood,
>>> this is not legal.
>>
>>
>> You certainly can use extensions to indicate that a new message is to be
>> sent, so I don't think it would be necessarily be prohibited to have it
>> remove a message, though I can't offhand think of an example of where we do
>> so.
>>
>>
>>> RFC 5245 Section 4.4.1.4 states that:
>>>
>>> "it would be technically possible to use extensions to change major
>>> aspects of the design of TLS; for example the design of cipher suite
>>> negotiation. This is not recommended; it would be more appropriate to
>>> define a new version of TLS -- particularly since the TLS handshake
>>> algorithms have specific protection against version rollback attacks based
>>> on the version number, and the possibility of version rollback should be a
>>> significant consideration in any major design change"
>>
>>
>> To be honest, this mostly seems aspirational :)
>>
>>
>>> I would assume, however, that those major aspects do no include omitting
>>> messages not marked as optional/situation-dependent in the spec.
>>>
>>> Both, TLS 1.2 and TLS 1.3 draft specs mention REQUIRED/MUST in the
>>> section describing the ClientHello. There are no REQUIRED mentions in other
>>> messages though. You do have the following for the Finished: "A Finished
>>> message is always sent immediately after a change cipher spec message to
>>> verify that the key exchange and authentication processes were successful."
>>> , so things like these lead me to believe that the messages not explicitly
>>> marked as optional, are in fact, required.
>>
>>
>> They're required absent some extension and you would have to be pretty
>> careful with changes which moved them.
>>
>> -Ekr
>>
>>>
>>>
>>>
>>> Thank you.
>>>
>>>
>>> _______________________________________________
>>> 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
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
