On Tue, Nov 7, 2017 at 6:15 AM, Illya Gerasymchuk <giluxonc...@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 > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
