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

[Hugo Krawczyk <[e-mail]>]

On Mon, Nov 3, 2014 at 6:47 PM, Nico Williams <[e-mail]> wrote:

> On Sun, Nov 2, 2014 at 4:24 PM, Hugo Krawczyk <[e-mail]>
> wrote:
> > Don't forget that 0-RTT cannot be supported with a signature-based
> protocol
> > so in that sense going to static DH is a win-win.
>
> That was DJB's point a while back, and, really, this goes back to the
> old AUTH_DH concept back in 1986.  It goes back further, actually,
> IIUC, all the way back to DH's invention.
>
> If you know the peer's public DH key a priori (from DNSSEC, from
> /etc/publickey [who remembers that?]) then you can send one security
> context establishment message and immediately start sending encrypted
> and authenticated data.  You need a response message to get key
> confirmation, and you can't get PFS until after consuming that
> message.
>
> (The GSS-API deals with this, incidentally.  A security context can be
> partially established but ready to encrypt application data with
> security caveats.  This is called "prot_ready".)
>
> A proper static-static DH + PFS exchange would take the usual 1.5
> round trips, but would be "prot_ready" in 0 round trips.
>
> There's a lot to be said for this.  But note that RSA key transport
> also lends itself to being prot_ready in 0 rt, so we still need to
> quantify the total cost of static-static DH + PFS, and RSA key
> transport + PFS for a proper comparison.
>

​The costs for the 0-RTT option in addition to the cost of an ephemeral DH
are as
follows.
DH+PFS: a single variable-base exponentiation for client and server.
RSA+PFS: for server an RSA decryption, for client an RSA encryption.
So the computational advantage of DH+PFS is very significant for the server.
For client RSA-PFS has some advantage as RSA encryption is faster than a DH
exponentiation but the difference is less dramatic than for the server, in
particular considering that the client is already doing two DH
exponentiations.
In addition, RSA encryption requires added protocol operations (and
implementation care) to prevent Bleichenbacher attack (e.g., you'll need to
dummy-decrypt ClientData even if the received ciphertext is illegal).
And aren't we in the process of phasing out RSA wherever possible?
​

​Hugo
​


> Nico
> --
>