Re: [TLS] TLS Extensions: Omitting Handshake Messages

Illya Gerasymchuk <giluxonchik@gmail.com> Tue, 07 November 2017 23:07 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 BD30512953B for <tls@ietfa.amsl.com>; Tue, 7 Nov 2017 15:07:34 -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 Xqajyo7YsuHW for <tls@ietfa.amsl.com>; Tue, 7 Nov 2017 15:07:32 -0800 (PST)
Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 C1D9E129478 for <tls@ietf.org>; Tue, 7 Nov 2017 15:07:31 -0800 (PST)
Received: by mail-oi0-x22c.google.com with SMTP id r128so666112oig.9 for <tls@ietf.org>; Tue, 07 Nov 2017 15:07:31 -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=2o7aqFcLFl7xx6AiOuF3AXIkm1Q3zoRBOpE5mlCSFL0=; b=c86NmUPpqy8X5mVi22mEjlgScLJok9xlhu9/H1Brw8DZN9iGi6bNxw2Oyk7qASydLQ 6IQgFcZPx7a2cqqQ9cDdNiG2bmfgvqsfKOlc+UVyRa6rKcspui2YXSdQd8jsXRiLgxbB VQ50zbwRPsj2cUQaFXIbft/f3a6l78R2QhbHw5HQ4PDqxH12W5LKFhx0iN67j+iwKJpu kCIAmnyPrqZ2AZLE7xotRuDvnLQ1hNVMZlGB1rhgRP6fYnRG40K6LeALSGUvweOYpC5U AlUG8trOAM83M9U1yUW+SVFDFMFgGmb97YpLJZPyJ6Yun4XpkQyE3Ocgw/iS/OKIA1QP LTJw==
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=2o7aqFcLFl7xx6AiOuF3AXIkm1Q3zoRBOpE5mlCSFL0=; b=K0WJl5DlnnJxl14md/H8obclglxa7afNqjN8zU7LuUMr7vRGKMAAAanDovMJyLP38Z 3+WogCMQfIflgifXYsI8k3b9syFhrkR4x+ylQ2u0Y+69Ba3bb2Z+XwNLoRwHuuN86Lht hMtJQzcYs2B8k1/jF0Yg6O0PX2C1k+FEWPFdFUQ0XPjPwA1GtcihpVzb8qA5NAs1+9MN M2gRXWN3ciWerU74/q/w++fHAlbheKYs/zd4tOHb+6UP1Pg3zHVqk6Mf0l3S/Uy+ef2i KCBmwbz38f8JfEH+t+evm3QA1QDk8C+fC1lPE0gxD2+YqOu5eMrYowgE6S1XXYIWvrut iB5w==
X-Gm-Message-State: AJaThX6EnkFUyxV+zQRPsTcxjZjgNa3kgjPhqXn07ckQsOaSsYcFCJZH xi4yGIpfYLAuret/xJZ+JN8jIzJ8nMZXG31cIPQ=
X-Google-Smtp-Source: ABhQp+Sm+ZUPYfl/aAmZW7sRE+0+14RahQM89SaQF86T7mCTr0lEQBVhU3nsA9krSZ5ZCtn+dPWnZN3n0SSIR4v9li0=
X-Received: by 10.202.4.19 with SMTP id 19mr192555oie.69.1510096051072; Tue, 07 Nov 2017 15:07:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.168.183.193 with HTTP; Tue, 7 Nov 2017 15:07:30 -0800 (PST)
In-Reply-To: <CABcZeBMVMiP7xwjOw5TeReq4v6C2ewGTUX-r6iFGjPeB5cnbfw@mail.gmail.com>
References: <CAGbWB+hddVX5sNFdjRCia84X2h29acMbfjeM1fapOQk2TvEDCA@mail.gmail.com> <CABcZeBOepA9J8GPZZHPXRv5rUPmeZ8TXFhe7gJGaeWvEi+41Zw@mail.gmail.com> <CAGbWB+hJ6y4KAh=6fAKJTU3v0coN1RWDqweh8ZwCPh1vmO_RmA@mail.gmail.com> <CABcZeBMVMiP7xwjOw5TeReq4v6C2ewGTUX-r6iFGjPeB5cnbfw@mail.gmail.com>
From: Illya Gerasymchuk <giluxonchik@gmail.com>
Date: Tue, 07 Nov 2017 23:07:30 +0000
Message-ID: <CAGbWB+jTSc=J0NZUCb7UmXrtHfoCL_EKk-7RE7aHe5TTGxjz3A@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a113c2a02b3735d055d6ca213"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/EDnzmv58jpjcjSv7RXgGsmPBPac>
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 23:07:35 -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 <ekr@rtfm.com> wrote:

> On Tue, Nov 7, 2017 at 2:40 PM, Illya Gerasymchuk <giluxonchik@gmail.com>
> 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 <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
>>>>
>>>>
>>>
>>
>