Re: [TLS] TLS Extensions: Omitting Handshake Messages

[Martin Thomson <[e-mail]>]

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 <[e-mail]> 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-mail]> wrote:
>>
>>
>>
>> On Tue, Nov 7, 2017 at 6:15 AM, Illya Gerasymchuk <[e-mail]>
>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>