Re: [TLS] TLS Extensions: Omitting Handshake Messages

Illya Gerasymchuk <giluxonchik@gmail.com> Tue, 07 November 2017 22:40 UTC

Return-Path: <giluxonchik@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0768C1294BC for <tls@ietfa.amsl.com>; Tue, 7 Nov 2017 14:40:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Kn2JhGY0loX for <tls@ietfa.amsl.com>; Tue, 7 Nov 2017 14:40:17 -0800 (PST)
Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A30B31294B9 for <tls@ietf.org>; Tue, 7 Nov 2017 14:40:17 -0800 (PST)
Received: by mail-oi0-x22d.google.com with SMTP id f66so635083oib.2 for <tls@ietf.org>; Tue, 07 Nov 2017 14:40:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZDpIKM88jbym5TT9+Mij0joLlj8pz1rV/eEx7iYaIxc=; b=dPeKzOyFiHLjJ4551fvYiRlWTRkLVn9K4yiQOOi7Vgkyg0EdJ/zqrm4Hsi/bF+dfWC flRiLOdGMy/eKODpeM55X3OzjgHcgUiBX6+GoDSd+UIXZjVUSndtJSTvJh+157y4vLSX erWypg2EBnRRXpchFo/Yo6+4gFGSk7wMXk0YQD5ksec9yJ14LuM+N/zPlAtGhdWAoc0Q aSPqaZst9uA0A0ju0XIs3P6m0gG/8qjrvRTbfMae7FQEmklp3JAdOZNsL70X8MOnsq8D qqMIfANLrCJ04g3CP0KN0LDNZ4fxhoSeMVzs3e5Uj5E9ZhS0pvdSKnXH8NnZQBCEoLbN N6LQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZDpIKM88jbym5TT9+Mij0joLlj8pz1rV/eEx7iYaIxc=; b=Hwa0jfdQg2ee73fnsff0WPmVb/Jba//dT5ppdpwpEihRYnyWd9Q4bsrNlfAzBslKLg ok4zl7z4h9Tv0x1y9e6P+u5I7TB9mQun4HlHlvjxtO2EChPm3ZMWvIoEknXXR3JZ+R2z dCVRIa8wyhzh/b3bgaCF3aPOOkGyp3PlS3u9d0A6G/NxtY7+RvnqnTvjg1h7gP20vBD9 J8TwhjhLbKbFdW9rlyG5vQueKoU2V5LhgIvFKvPvfRdJel7o2kPSRTfS9guHRg3Gfojp 2z/41VOp3fzRcvfyFW18k1roq3jiqcKe5LPYvkqJtCYAQFXCby+5IV4RNPZHa7DykfAT 60lQ==
X-Gm-Message-State: AJaThX5gz+RL6OXXRq+ufIVzNWOinIGRJQVCsktpwqojgMwdxmOYtAje viYtwsEmMLNFs2/mMz4Yg3sY/S5O6LFwxfX6Mr8=
X-Google-Smtp-Source: ABhQp+TLHzQbtIuwecHD+pqd9gB0/+hnVBo99udTJdob77muRrf8Znmv6RIDzEkVuU/K/aitAnC3VEA7h+VZaNdi0zE=
X-Received: by 10.202.108.201 with SMTP id h192mr168508oic.378.1510094416872; Tue, 07 Nov 2017 14:40:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.168.183.193 with HTTP; Tue, 7 Nov 2017 14:40:16 -0800 (PST)
In-Reply-To: <CABcZeBOepA9J8GPZZHPXRv5rUPmeZ8TXFhe7gJGaeWvEi+41Zw@mail.gmail.com>
References: <CAGbWB+hddVX5sNFdjRCia84X2h29acMbfjeM1fapOQk2TvEDCA@mail.gmail.com> <CABcZeBOepA9J8GPZZHPXRv5rUPmeZ8TXFhe7gJGaeWvEi+41Zw@mail.gmail.com>
From: Illya Gerasymchuk <giluxonchik@gmail.com>
Date: Tue, 07 Nov 2017 22:40:16 +0000
Message-ID: <CAGbWB+hJ6y4KAh=6fAKJTU3v0coN1RWDqweh8ZwCPh1vmO_RmA@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a1142dd2e4b89b0055d6c4136"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/UKo762HA-2qtaIa4FLktnQXGZqs>
Subject: Re: [TLS] TLS Extensions: Omitting Handshake Messages
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Nov 2017 22:40:21 -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 <ekr@rtfm.com> wrote:

>
>
> On Tue, Nov 7, 2017 at 6:15 AM, Illya Gerasymchuk <giluxonchik@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
>>
>>
>