Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3

From: Rene Struik <[email-masked]>
Date: Tue, 24 Mar 2015 09:08:54 -0400

Hi Hugo:

In your email of October 31, 2014 (see below), you introduced the OPTLS 
protocol to TLS. At the time, you omitted some details, since you simply 
wished to socialize the ideas. You did emphasize, though, that details 
matter and put forward that you were working on flashing out the full 
details of the protocol and security proof.

After a few months of radio silence (to me), the protocol seems to be on 
the radar screen for discussion with TLS again. It would therefore be 
good to have a stable reference that describes this in full technical 
detail and makes this a stable and solid source for the cryptographic 
community to look at and reference.

I do think that OPTLS has interesting features, perhaps also outside 
TLS, but would like to give this a thorough and critical look first (and 
invite others to do so as well). For this, it would help to have 
something beyond some emails on the TLS list and some "flashed out" 
draft spec Eric Rescorla worked on earlier this week (which, although 
useful, may change over time).  Having a stable document would make this 
more appealing to study and discuss in a wider audience, esp. for 
important potential use cases.

If you have a paper (e.g., one you could post on the IACR ePrint 
server), that would be great. {Rest assured, this does not have to have 
the same size as your 2005 paper on HMQV for it to be useful.}

Best regards, Rene

==
"The presentation is sketchy and omits the exact procedure for key 
derivation. The latter is a crucial component for the security of the 
protocol, but before getting into these details we want to get a sense 
of whether the WG is interested in this approach. In the meantime, 
Hoeteck Wee and myself are working on the details of the protocol and 
the security proof."

On 10/31/2014 8:54 PM, Hugo Krawczyk wrote:
> During the TLS interim meeting of last week (Oct 22 2014) I suggested 
> that TLS
> 1.3 should abandon signature-based authentication (other than for 
> certificates)
> and be based solely on a combination of ephemeral Diffie-Hellman for 
> PFS and
> static Diffie-Hellman for authentication. This has multiple benefits 
> including
> major performance gain (by replacing the per-handshake RSA signature 
> by the
> server with a much cheaper elliptic curve exponentiation), 
> compatibility with
> the mechanisms required for forward secrecy, natural accommodation of 
> a 0-RTT
> option, and a simple extension without signatures for client 
> authentication.
>
> Below I present a schematic representation of the proposed protocol 
> referred
> to as OPTLS where OPT stands for OPTimized and/or for One-Point-Three.
> The presentation is sketchy and omits the exact procedure for key 
> derivation.
> The latter is a crucial component for the security of the protocol, but
> before getting into these details we want to get a sense of whether 
> the WG is
> interested in this approach. In the meantime, Hoeteck Wee and myself are
> working on the details of the protocol and the security proof.
>
> We describe a setting with optional 0-RTT and server-only authentication.
> Client authentication can be added as a further option or as an extension
> (similar to the current 1.3 proposal) - see below.
>
> NOTATION AND TERMINOLOGY:
>
> [K] symbols represent pointers to key material whose exact derivation 
> is not
> included here except for specifying the basic DH values from which the 
> key is
> derived (actual derivation will include further information similar to the
> extended hash mechanisms or SessionHash proposal considered for 1.3).
> Asterisks represent optional fields that the WG can decide to leave as 
> optional,
> mandatory, or simply remove without changing the core cryptographic 
> security of
> the protocol. All references to encryption mean "authenticated encryption"
> using the encrypt-then-mac paradigm (or any other secure AEAD mechanism).
>
> KeyShare's represent ephemeral Diffie-Hellman values exchanged by the 
> parties.
> All the public key and Diffie-Hellman operations are assumed to happen 
> over a
> cyclic group with generator g of order q (typically implemented by an 
> elliptic
> curve group). We use multiplicative notation where ^ denotes 
> exponentiation as
> in g^x, g^{xy} (here xy denotes multiplication of the scalars x and 
> y), etc.
> Omitted from the current high level description is a mechanism for 
> testing group
> membership of DH values or cofactor exponentiation (the specific mechanism
> depends on the group type and is typically very efficient for elliptic 
> curves).
>
> SERVER PUBLIC KEY AND CERTIFICATE:
>
> The server has a long term private-public key pair denoted by (s,g^s) 
> where
> s is uniform random in [0..q-1] (we refer to s and g^s as "static keys").
> We assume that the server has a certificate that includes the server's 
> public
> key g^s and a CA-signed binding of this key to the server's identity.
> We discuss the implementation of such certificates below.
>
> PROTOCOL OPTLS:
>
> ClientHello
> ClientKeyShare
> ClientData* [K0]       -------->
>                                            ServerHello
>                                            ServerKeyShare
>                                            ServerCertificate* [K1]
>                                            ServerFinished [K2]
>                        <--------           ServerData* [K2]
> ClientFinished* [K2]   -------->
>
>
>             Protected Application Data [K3]
>                        <------->
>
>
>
> 1-RTT CASE:
>
> The basic 1-RTT case omits the ClientData* field. It includes a 
> ClientKeyShare
> g^x and a ServerKeyShare g^y and an optional (encrypted) server 
> certificate.
> If the certificate is sent (it can be omitted if the client has 
> indicated that
> it knows the server key as in the case in the 0-RTT scenario) and is 
> encrypted,
> the encryption key K1 is derived from g^{xy}.
>
> Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It is 
> used to
> authenticate-encrypt the ServerFinished and ClientFinished messages (which
> include a hash of the previous traffic) and to encrypt data from the 
> server if
> such data is piggybacked to the second message.
>
> Key K3 is the "application key" used to derive key material for 
> protection of
> application data.  This key material will include (directional) 
> Authenticated
> Encryption keys and, possibly, keys for derivation of further re-key 
> material.
> K3 is computed from  both g^{xs} and g^{xy} similarly to K2, but its 
> derivation
> will be different than K2, e.g., using a separating key expansion 
> technique.
>
> SUPPORT FOR 0-RTT:
>
> The above protocol is compatible with a 0-RTT protocol such as QUIC. 
> In this
> case, the client is assumed to have information about the server's 
> public key
> and other security parameters. The server is assumed to have some 
> mechanism in
> place for detecting replay (e.g., via timestamps, stored client 
> nonces, etc.).
> The resulting protocol is as described above where the ClientData 
> field is sent
> encrypted under key K0 derived from g^{xs}.
> The rest of the protocol is identical to the above.
> Note: In this case, ServerCertificate is not sent as the client had to 
> know
> the server's public key before the first message (one can imagine a 
> setting
> where the server may send a different certificate in the second 
> message - if
> desired, this can be accommodated too as an option or extension).
>
> CLIENT AUTHENTICATION:
>
> Client authentication can be supported via an option or extension. It 
> would
> include a client certificate for a static DH key g^c sent in the third 
> message
> (the certificate can be encrypted under key K2 to provide client's 
> identity
> protection). In this case, the key for computing the ClientFinished 
> message and
> the application key K3 would be derived from a combination of the 
> values g^xy,
> g^xs, g^yc (and possibly also g^{cs}).
>
> NOTES:
>
> Note on Finished messages: The above spec sets ServerFinished as 
> mandatory and
> ClientFinished as optional. The latter option is needed for a 1-RTT 
> protocol.
> In principle, both Finished messages could be omitted and still obtain 
> security
> via implicit authentication (assuming the inputs to key derivation are 
> chosen
> appropriately). But given the advantages of ServerFinished for providing
> explicit authentication, key confirmation, and active forward secrecy (see
> below), it seems advisable to always include it. Including ClientFinished
> provides key confirmation from client and also explicit client 
> authentication
> when client certificate is included. ClientFinished also provides 
> Universal
> Composable (UC) security (this is a result of the Canetti-Krawczyk 
> proof that
> CK security implies UC security when a client confirmation step is 
> included).
>
> Note on certificates: Since in current practice servers hold 
> certificates for
> RSA signature keys rather than for static DH keys, the certificate 
> field in the
> above protocol will be implemented by a pair consisting of (i) the 
> server's RSA
> signature certificate and (ii) the server's signature using this RSA 
> key on the
> server's static public DH key g^s. The latter signature by the server is
> performed only when a new static DH key is created (how often this 
> happens and
> how many such keys are created is completely up to the server - it has the
> advantage that these keys can be changed often to increase security 
> against
> leaked keys). This use of RSA also enjoys the high efficiency of RSA
> verification for the client.
> The handling of Client certificates would be similar.
>
> Note on forward security (a.k.a. as PFS for Perfect Forward Security):
> PFS is provided by the (mandatory) use of ephemeral Diffie-Hellman keys.
> The meaning of PFS is that an attacker that finds the (long-term) static
> private keys of the parties cannot compromise past session keys. 
> Without the
> ServerFinished message the above protocol ensures forward secrecy against
> passive attackers (i.e., for sessions where the attacker did not 
> choose g^y).
> With ServerFinished, PFS holds also against active attackers. A similar
> consideration applies to ClientFinished.
>
> Client certificates in the first message: We note that in cases where 
> client
> certificates can be sent in the clear in the first message of the 
> protocol, one
> can provide PFS and mutual authentication in a 1-RTT at essentially 
> the same
> cost of an unauthenticated DH exchange (i.e., a cost of little more 
> than two
> exponentiations). In such a setting one can also obtain mutual 
> authentication in
> a 0-RTT protocol (with forward secrecy with respect to the client's key).
> These options, however, require HMQV-like mechanisms and may raise IP 
> issues (this
> can be investigated further if the WG is interested).
>
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Hugo Krawczyk <[email-masked]>
Date: Tue, 24 Mar 2015 11:11:43 -0400

Hi Rene,

We are working on such a write up as  we speak. Exactly because the details
matter and we have been changing them to adapt to the WG requirements and
preferences then the writing has been delayed. We are now converging to a
protocol that the people in the interim meeting were quite happy with. It
is in the same spirit of OPTLS but it is not signature-less, i.e.,
semi-static keys for the servers are now signed with online signatures that
prove freshness by including the client's nonce under the signature.

We should have something decent to post in two weeks.
But let me note that there is nothing revolutionary in the protocol - it is
crypto engineering with well understood components, not inventing new
fundamental pieces.

Hugo

On Tue, Mar 24, 2015 at 9:08 AM, Rene Struik <[email-masked]> wrote:

> the radar screen for discussion with TLS again. It would therefore be good
> to have a stable reference that describes this in full technical detail and
> makes this a stable and solid source for the cryptographic community to
> look at and reference.
>
> I do think that OPTLS has interesting features, perhaps also outside TLS,
> but would like to give this a thorough and critical look first (and invite
> others to do so as well). For this, it would help to have something beyond
> some emails on the TLS list and some "flashed out" draft spec Eric Rescorla
> worked on earlier this week (which, although useful, may change over
> time).  Having a stable document would make this more appealing to study
> and discuss in a wider audience, esp. for important potential use cases.
>
> If you have a paper (e.g., one you could post on the IACR ePrint server),
> that would be great. {Rest assured, this does not have to have the same
> size as your 2005 paper on HMQV for it to be useful.}
>
> Best regards, Rene
>
> ==
> protocol, but before getting into these details we want to get a sense of
> whether the WG is interested in this approach. In the meantime, Hoeteck Wee
> and myself are working on the details of the protocol and the security
> proof."
>
> and be based solely on a combination of ephemeral Diffie-Hellman for PFS
> and
> major performance gain (by replacing the per-handshake RSA signature by the
> server with a much cheaper elliptic curve exponentiation), compatibility
> with
> the mechanisms required for forward secrecy, natural accommodation of a
> 0-RTT
> before getting into these details we want to get a sense of whether the WG
> is
> [K] symbols represent pointers to key material whose exact derivation is
> not
> included here except for specifying the basic DH values from which the key
> is
> in g^x, g^{xy} (here xy denotes multiplication of the scalars x and y),
> etc.
> Omitted from the current high level description is a mechanism for testing
> group
> If the certificate is sent (it can be omitted if the client has indicated
> that
> Key K3 is the "application key" used to derive key material for protection
> of
> The above protocol is compatible with a 0-RTT protocol such as QUIC. In
> this
> case, the client is assumed to have information about the server's public
> key
> place for detecting replay (e.g., via timestamps, stored client nonces,
> etc.).
> The resulting protocol is as described above where the ClientData field is
> sent
> Note: In this case, ServerCertificate is not sent as the client had to know
> the server's public key before the first message (one can imagine a setting
> where the server may send a different certificate in the second message -
> if
> Client authentication can be supported via an option or extension. It would
> (the certificate can be encrypted under key K2 to provide client's identity
> the application key K3 would be derived from a combination of the values
> g^xy,
> Note on Finished messages: The above spec sets ServerFinished as mandatory
> and
> when client certificate is included. ClientFinished also provides Universal
> Composable (UC) security (this is a result of the Canetti-Krawczyk proof
> that
> Note on certificates: Since in current practice servers hold certificates
> for
> RSA signature keys rather than for static DH keys, the certificate field
> in the
> signature certificate and (ii) the server's signature using this RSA key
> on the
> performed only when a new static DH key is created (how often this happens
> and
> advantage that these keys can be changed often to increase security against
> private keys of the parties cannot compromise past session keys. Without
> the
> passive attackers (i.e., for sessions where the attacker did not choose
> g^y).
> can provide PFS and mutual authentication in a 1-RTT at essentially the
> same
> cost of an unauthenticated DH exchange (i.e., a cost of little more than
> two
> TLS mailing [email-masked]://www.ietf.org/mailman/listinfo/tls
>
>
>
> --

---

From: Rene Struik <[email-masked]>
Date: Tue, 24 Mar 2015 11:31:07 -0400

Great - looking forward to the technical write-up, when it becomes 
available.

One quick question: if I remember correctly from your original OPTLS 
sketch, you paid some tribute to a "modus operandi" that includes client 
authentication as well (i.e., making this into a mutually authenticated 
key agreement scheme). I would be curious whether this is still on the 
table and, if so, whether this would also follow the same online signing 
approach you sketched below for the server. Apologies in case I missed 
some of this finer detail (hence, my interest in having a concise 
overall and technically complete description).

While I do appreciate lots of this is "simply" cryptographic 
engineering, I do think you would have to agree that TLS has a mixed 
record here. Hence, some reflection and careful analysis seems to be in 
order, in addition to the great contributions you made yourself so far.

Best regards, Rene

On 3/24/2015 11:11 AM, Hugo Krawczyk wrote:
> Hi Rene,
>
> We are working on such a write up as  we speak. Exactly because the 
> details matter and we have been changing them to adapt to the WG 
> requirements and preferences then the writing has been delayed. We are 
> now converging to a protocol that the people in the interim meeting 
> were quite happy with. It is in the same spirit of OPTLS but it is not 
> signature-less, i.e., semi-static keys for the servers are now signed 
> with online signatures that prove freshness by including the client's 
> nonce under the signature.
>
> But let me note that there is nothing revolutionary in the protocol - 
> it is crypto engineering with well understood components, not 
> inventing new fundamental pieces.
>
> Hugo
>
>
> On Tue, Mar 24, 2015 at 9:08 AM, Rene Struik <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Hugo:
>
>     In your email of October 31, 2014 (see below), you introduced the
>     OPTLS protocol to TLS. At the time, you omitted some details,
>     since you simply wished to socialize the ideas. You did emphasize,
>     though, that details matter and put forward that you were working
>     on flashing out the full details of the protocol and security proof.
>
>     After a few months of radio silence (to me), the protocol seems to
>     be on the radar screen for discussion with TLS again. It would
>     therefore be good to have a stable reference that describes this
>     in full technical detail and makes this a stable and solid source
>     for the cryptographic community to look at and reference.
>
>     I do think that OPTLS has interesting features, perhaps also
>     outside TLS, but would like to give this a thorough and critical
>     look first (and invite others to do so as well). For this, it
>     would help to have something beyond some emails on the TLS list
>     and some "flashed out" draft spec Eric Rescorla worked on earlier
>     this week (which, although useful, may change over time).  Having
>     a stable document would make this more appealing to study and
>     discuss in a wider audience, esp. for important potential use cases.
>
>     server), that would be great. {Rest assured, this does not have to
>     have the same size as your 2005 paper on HMQV for it to be useful.}
>
>     Best regards, Rene
>
>     ==
>     derivation. The latter is a crucial component for the security of
>     the protocol, but before getting into these details we want to get
>     a sense of whether the WG is interested in this approach. In the
>     meantime, Hoeteck Wee and myself are working on the details of the
>     protocol and the security proof."
>
>>     During the TLS interim meeting of last week (Oct 22 2014) I
>>     suggested that TLS
>>     and be based solely on a combination of ephemeral Diffie-Hellman
>>     for PFS and
>>     static Diffie-Hellman for authentication. This has multiple
>>     benefits including
>>     the mechanisms required for forward secrecy, natural
>>     accommodation of a 0-RTT
>>     Below I present a schematic representation of the proposed
>>     protocol referred
>>     before getting into these details we want to get a sense of
>>     whether the WG is
>>     [K] symbols represent pointers to key material whose exact
>>     derivation is not
>>     included here except for specifying the basic DH values from
>>     which the key is
>>     Asterisks represent optional fields that the WG can decide to
>>     leave as optional,
>>     mandatory, or simply remove without changing the core
>>     cryptographic security of
>>     KeyShare's represent ephemeral Diffie-Hellman values exchanged by
>>     the parties.
>>     All the public key and Diffie-Hellman operations are assumed to
>>     happen over a
>>     cyclic group with generator g of order q (typically implemented
>>     by an elliptic
>>     in g^x, g^{xy} (here xy denotes multiplication of the scalars x
>>     and y), etc.
>>     Omitted from the current high level description is a mechanism
>>     for testing group
>>     depends on the group type and is typically very efficient for
>>     elliptic curves).
>>
>>     The server has a long term private-public key pair denoted by
>>     (s,g^s) where
>>     We assume that the server has a certificate that includes the
>>     server's public
>>     it knows the server key as in the case in the 0-RTT scenario) and
>>     is encrypted,
>>     Key K2 is an encryption key derived from both g^{xs} and g^{xy}.
>>     It is used to
>>     include a hash of the previous traffic) and to encrypt data from
>>     the server if
>>     Encryption keys and, possibly, keys for derivation of further
>>     re-key material.
>>     K3 is computed from  both g^{xs} and g^{xy} similarly to K2, but
>>     its derivation
>>     The above protocol is compatible with a 0-RTT protocol such as
>>     QUIC. In this
>>     case, the client is assumed to have information about the
>>     server's public key
>>     include a client certificate for a static DH key g^c sent in the
>>     third message
>>     protection). In this case, the key for computing the
>>     ClientFinished message and
>>     ClientFinished as optional. The latter option is needed for a
>>     1-RTT protocol.
>>     In principle, both Finished messages could be omitted and still
>>     obtain security
>>     via implicit authentication (assuming the inputs to key
>>     derivation are chosen
>>     Composable (UC) security (this is a result of the
>>     Canetti-Krawczyk proof that
>>     CK security implies UC security when a client confirmation step
>>     is included).
>>
>>     RSA signature keys rather than for static DH keys, the
>>     certificate field in the
>>     above protocol will be implemented by a pair consisting of (i)
>>     the server's RSA
>>     signature certificate and (ii) the server's signature using this
>>     RSA key on the
>>     performed only when a new static DH key is created (how often
>>     this happens and
>>     Client certificates in the first message: We note that in cases
>>     where client
>>     can provide PFS and mutual authentication in a 1-RTT at
>>     essentially the same
>>     cost of an unauthenticated DH exchange (i.e., a cost of little
>>     more than two
>>     These options, however, require HMQV-like mechanisms and may
>>     raise IP issues (this
>>     [email-masked]  <mailto:[email-masked]>
>     email:[email-masked]  <mailto:[email-masked]>  | Skype: rstruik
>     cell:+1 (647) 867-5658  <tel:%2B1%20%28647%29%20867-5658>  | US:+1 (415) 690-7363  <tel:%2B1%20%28415%29%20690-7363>
>
>

---

From: Hugo Krawczyk <[email-masked]>
Date: Tue, 24 Mar 2015 11:39:57 -0400

I absolutely agree with you and I am not asking to take my word on the
cryptographic design. This all needs review. I am just saying that
reviewers will not have to cope with some hard-to-digest revolutionary
ideas. And, yes, we hope to improve on TLS mixed record...

Hugo

On Tue, Mar 24, 2015 at 11:31 AM, Rene Struik <[email-masked]> wrote:

> authentication as well (i.e., making this into a mutually authenticated key
> agreement scheme). I would be curious whether this is still on the table
> and, if so, whether this would also follow the same online signing approach
> you sketched below for the server. Apologies in case I missed some of this
> finer detail (hence, my interest in having a concise overall and
> technically complete description).
>
> While I do appreciate lots of this is "simply" cryptographic engineering,
> I do think you would have to agree that TLS has a mixed record here. Hence,
> some reflection and careful analysis seems to be in order, in addition to
> the great contributions you made yourself so far.
>
> Best regards, Rene
>
>
> requirements and preferences then the writing has been delayed. We are now
> converging to a protocol that the people in the interim meeting were quite
> happy with. It is in the same spirit of OPTLS but it is not signature-less,
> i.e., semi-static keys for the servers are now signed with online
> signatures that prove freshness by including the client's nonce under the
> signature.
>
>  But let me note that there is nothing revolutionary in the protocol - it
> is crypto engineering with well understood components, not inventing new
> fundamental pieces.
>
>  Hugo
>
>
>> before getting into these details we want to get a sense of whether the
>> WG is
>> The resulting protocol is as described above where the ClientData field
>> is sent