Re: [TLS] TLS Extensions: Omitting Handshake Messages

[Eric Rescorla <[e-mail]>]

On Tue, Nov 7, 2017 at 6:15 AM, Illya Gerasymchuk <[e-mail]>
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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>