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
