Re: [TLS] TLS Extensions: Omitting Handshake Messages

[Eric Rescorla <[e-mail]>]

On Tue, Nov 7, 2017 at 2:40 PM, 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?
>

Well, this is effectively the syntax that TLS 1.3 with PR 1091 uses, except
that it's called "supported_versions".



> 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):
>

This seems like a philosophical question.




> 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.*
>

Well, backward compatible here typically would mean "you can send a
ClientHello to the server and it won't choke", and this would be true for
both your proposal and TLS 1.3. Any other questions about compliance kind
of seem like standards lawyering.

-Ekr




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
>>>
>>>
>>
>