Subject: [TLS] TLS Extensions: Omitting Handshake Messages

From: Illya Gerasymchuk <[email-masked]>
Date: Tue, 7 Nov 2017 14:15:42 +0000

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.

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"

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.

Thank you.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 Nov 2017 09:56:48 -0800

On Tue, Nov 7, 2017 at 6:15 AM, Illya Gerasymchuk <[email-masked]>
wrote:

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

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Illya Gerasymchuk <[email-masked]>
Date: Tue, 7 Nov 2017 22:40:16 +0000

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 <[email-masked]> wrote:

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 Nov 2017 14:46:37 -0800

On Tue, Nov 7, 2017 at 2:40 PM, Illya Gerasymchuk <[email-masked]>
wrote:

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

> 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

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 8 Nov 2017 09:47:23 +1100

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 <[email-masked]> 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             -------->
>                                                             +
> TLS_1.2_TO_TLS_1.3
> low-energy devices, while remaining backwards compatible with regular TLS.
> My idea is to define this new protocol through various extensions (even
>> 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
>
>>> 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.
>>
>>
>>> "it would be technically possible to use extensions to change major
>>> aspects of the design of TLS; for example the design of cipher suite
>>> 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"
>>
>>

---

From: Illya Gerasymchuk <[email-masked]>
Date: Tue, 7 Nov 2017 23:07:30 +0000

Okay, thank you very much, this clears it all up!

Can I make a suggestion of making the section that describes the extension
mechanism to mention that extensions can, in fact, choose to omit messages
not marked as situation-depended/optional? Maybe this is already covered by
the "it would be technically possible to use extensions to change major aspects
of the design of TLS" part, but neither reading RFC 5246, nor the TLS 1.3
draft, nor the RFC 4366 (and other related ones), makes it clear, in my
opinion. I'm talking from a perspective of someone who studied  SSL 3.0,
TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3 and related RFCs in detail in the last
2-3 months, but only knew the basics before (not basics cryptography and
other constructs that TLS uses, only the basics of the TLS protocol
itself). I've asked the same question I posted here to some friends and on
the internet and everyone said that, from what they understood from the
spec, *extensions could not remove *messages marked as non-optional. Having
such information presented explicitly would be of great help to anyone who
is working on changes/extensions to/for TLS.

Thank you,

- Illya

On Tue, Nov 7, 2017 at 10:46 PM, Eric Rescorla <[email-masked]> wrote:

> Well, this is effectively the syntax that TLS 1.3 with PR 1091 uses,
> except that it's called "supported_versions".
>
>
>
>>> On Tue, Nov 7, 2017 at 6:15 AM, Illya Gerasymchuk <[email-masked]
>>> > wrote:
>>>
>>>> Greetings,
>>>>
>>>> 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*
>>>> * (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.
>>>>
>>>> called *XYZ*. The client and the server negotiate that extension in
>>>> the their extended hello messages. Would it be legal for the *XYZ*