[TLS] TLS Extensions: Omitting Handshake Messages

Illya Gerasymchuk <giluxonchik@gmail.com> Tue, 07 November 2017 14:15 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 4CF9913FB96 for <tls@ietfa.amsl.com>; Tue, 7 Nov 2017 06:15:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-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 AnNx3p5SYPGx for <tls@ietfa.amsl.com>; Tue, 7 Nov 2017 06:15:44 -0800 (PST)
Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (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 AC40113FB17 for <tls@ietf.org>; Tue, 7 Nov 2017 06:15:43 -0800 (PST)
Received: by mail-ot0-x22f.google.com with SMTP id n74so12114254ota.8 for <tls@ietf.org>; Tue, 07 Nov 2017 06:15:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=nrnSSUpLxKY7Z/JKw8fDcBrAIulWE4GoOvIQNrSBv88=; b=FlI/BmTjF6qtUpc8Q9tg/EsxmCk+Kh1onSlaYZ4TJkFg4q3r9s/p6JkWzYyIMQQNVh kupa4O11n+FL2WK8MklLaKql6Tml8WeGUFvAxuBUlM7jp5bnKMxcpxPgFKpri8Ru6bBv jfgGIuq04tkICWEX+UvvAswFj1jskfqootby4e7r/pRe/WOHIqNkLHL3U8sbPd5cgVr/ s2JkccBEH7VRF5XzpC2aLJbWksxXWBb22rbk7sfyNW1y1wnPlewNwV8xrtidvS4I6l2L SLL9nwjtBhEowSktKCZnbn379u++hEYXTGgPPIxgdaHFJTo3tUqeEXYSlJiD3bXiFvn5 uhyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=nrnSSUpLxKY7Z/JKw8fDcBrAIulWE4GoOvIQNrSBv88=; b=sNsrvGBBKUAyn5i9BPjwqWwK5ZoVygO6T6giTaA82cvcoXZF/wzKA2PJX+whL2k1dv BHn+xcyFq/Tt3trp5l42Fs0Ed0tA/3V5Q0I5qB37jOshbBV1bi/Mq1+pJVXP+fjYcOTe EpBdnb+iDxJNE9ANaubVRA7T1/rVlkqZel1+s8j2Eq3pnjtyGbPstwbGKUv4GI7P6hCz gXwG+RfzgKkrj7GCbKRPZYhOAmJ5mA1SASPKywmKR+9SRmfn6q2gsfjvuG+ufnV40oEk sIFJx4mDknWRmDrYYMVR99YtTjOoFKrpLosqdtt6NYe+FkZC84T1F06M2BVg7fDwCzmH EquA==
X-Gm-Message-State: AJaThX58Oai+LtkXF/h2Nsx566k3X0q5++fV2SK/vQnPEUzaGGn7sqxw DOBi8MYxMUTRy1nPda4sFjQNye8LZm/rZuvqDt0VgA==
X-Google-Smtp-Source: ABhQp+T4jh9KxDmeGjl5tPvvxStk8MvMwgeXgHekZVEZwp2mSvdBHqvjVje5vKBneqjVKrLmCFjnaWcxzRUkg+12roE=
X-Received: by 10.157.64.8 with SMTP id m8mr12637180ote.387.1510064142782; Tue, 07 Nov 2017 06:15:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.168.183.193 with HTTP; Tue, 7 Nov 2017 06:15:42 -0800 (PST)
From: Illya Gerasymchuk <giluxonchik@gmail.com>
Date: Tue, 07 Nov 2017 14:15:42 +0000
Message-ID: <CAGbWB+hddVX5sNFdjRCia84X2h29acMbfjeM1fapOQk2TvEDCA@mail.gmail.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary="f403043e1568d196d9055d65341f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/hxdy9rqSneSO9enY2R6CxSrXpsQ>
X-Mailman-Approved-At: Tue, 07 Nov 2017 09:47:27 -0800
Subject: [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 14:17:11 -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.