Subject: [TLS] Fwd: Summary of today's discussion on server-side signing

From: Sean Turner <[email-masked]>
Date: Mon, 27 Jul 2015 10:26:12 -0400

All,

I asked ekr to write a brief summary of the server-side signing issue.  The summary provided matches the WG consensus as judged by the chairs.  Please let us know if you object to the way forward by August 3rd.

J&S

Begin forwarded message:

> From: Eric Rescorla <[email-masked]>
> Subject: Summary of today's discussion on server-side signing
> Date: July 22, 2015 at 08:52:31 EDT
> To: Sean Turner <[email-masked]>
> 
> Sean,
> 
> Here's a summary of today's discussion on signing and KnownConfiguration.
> 
> SUMMARY
> The WG agreed that the server must sign whenever certificate authentication
> is used (even if the KnownConfiguration is used).
> 
> 
> BACKGROUND
> The current draft requires the server to send a Certificate/CertificateVerify
> whenever either:
> 
> (a) The KnownConfiguration option is not in use.
> (b) The server sends a ServerConfiguration
> 
> but it does not need to sign if the KnownConfiguration option is in
> use but no new ServerConfiguration is provided.  Several people (most
> recently Martin Thomson) have suggested that it would be simpler to
> just require the server to sign any time certificate-based
> authentication is in use. The penalty for this is an extra sign/verify,
> as shown in the following table:
> 
> Scenario                           Client                   Server
> ------------------------------------------------------------------
> 1-RTT                  1 (EC)DHE + Verify         1 (EC)DHE + Sign
> 
> 0-RTT (current,                 2 (EC)DHE                2 (EC)DHE
>   no new config) 
> 
> 0-RTT (current,        2 (EC)DHE + Verify         2 (EC)DHE + Sign
>   new config)
> 
> 0-RTT (proposed)       2 (EC)DHE + Verify         2 (EC)DHE + Sign
> 
> 
> So, the performance difference here is between line 2 and line 4,
> since whenever you provide a new config (line 3) you have to sign
> anyway. The benefit is that it makes the server side of the handshake
> essentially identical in both 0-RTT and 1-RTT, which is nice from an
> implementation and analysis perspective.
> 
> 
> SUMMARY OF WG DISCUSSION
> During the WG discussion today, there was rough consensus to adopt
> this change (i.e., always sign). A number of arguments were advanced
> in favor of this change.
> 
> (1) It's significantly simpler for implementors and (at least informal)
>     analysis. A side benefit is being able to merge the extension
>     logic for 0-RTT and KnownConfiguration, since KnownConfiguration
>     is only useful with 0-RTT.
>     
> (2) It extends the properties we were shooting for with online-only
>     signatures and requiring that the server always sign ServerConfiguration,
>     namely continuous proof of access to the signing key.
> 
> (3) The performance cost of an extra ECDSA signature is small and
>     shrinking fast (per Ian Swett channelling Adam Langley), and
>     people who care about speed will cut over to ECDSA (certs are
>     readily available).
> 
> (4) You can still do 0-RTT with PSK resumption, which is computationally
>     much faster.
> 
> On balance the WG seemed to feel that these were more compelling than
> the performance value of the optimization.
> 
> There was also a recognition that signature amortization was valuable,
> but the consensus was that instead of doing this here, it would be
> better to adopt Hugo's suggeston from a while back to have a
> certificate extension that allowed offline signatures. This allows
> both amortization *and* delegation, while not constituting a threat
> to existing TLS 1.2 implementations. We agreed that this could be
> worked in in parallel but shouldn't hold up TLS 1.3.
> 
> Per WG guidance, I'll be preparing a draft PR for this.
> 
> -Ekr
> 
>  
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>

---

From: Hugo Krawczyk <[email-masked]>
Date: Fri, 31 Jul 2015 17:56:46 -0700

I am ok with whatever the WG decides, particularly when the reasons are
non-cryptographic but rather based on implementation considerations.

Still, for the record, I'd like to correct the statement "
​
KnownConfiguration is only useful with 0-RTT.
​"​.

KnownConfiguration could be used with 1-RTT even if the client does not
send early application data in the first flight.
This would have allowed to save a signature also in the 1-RTT case whenever
the client has cached a KnownConfiguration.
Saving a signature is a major performance benefit with RSA signatures (are
they really going away soon?) but is a benefit also with ECDSA as it avoids
the need to send a certificate chain (shortening the handshake) and the
need to verify these certificates. ECDSA also has a cost for the client.

Lastly, the protocol would be secure without the signature (in the case the
client uses a known configuration), a property that enables the use of the
protocol with offline signatures (to-be-specified).

Hugo

On Mon, Jul 27, 2015 at 7:26 AM, Sean Turner <[email-masked]> wrote:

> All,
>
> I asked ekr to write a brief summary of the server-side signing issue.
> The summary provided matches the WG consensus as judged by the chairs.
> Please let us know if you object to the way forward by August 3rd.
>
> J&S
>
> Begin forwarded message:
>
> >     logic for 0-RTT and KnownConfiguration, since
> ​​
> KnownConfiguration
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 31 Jul 2015 18:00:57 -0700

On Fri, Jul 31, 2015 at 5:56 PM, Hugo Krawczyk <[email-masked]>
wrote:

> This would have allowed to save a signature also in the 1-RTT case
> whenever the client has cached a KnownConfiguration.

This was very bad writing on my part. What I was trying to say was that
once you commit to signing every transaction, then it's not helpful to
use the KnownConfiguration mechanism with 1-RTT because you've
already given up the optimizations you quite rightly point out. Sorry for
the
confusion.

> protocol with offline signatures (to-be-specified).

Thanks for pointing this out.

Best,
-Ekr

Hugo