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

[Eric Rescorla <[e-mail]>]

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

> 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.
>

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.



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).
>

Thanks for pointing this out.

Best,
-Ekr

Hugo
>
> On Mon, Jul 27, 2015 at 7:26 AM, Sean Turner <[e-mail]> 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:
>>
>> > From: Eric Rescorla <[e-mail]>
>> > Subject: Summary of today's discussion on server-side signing
>> > Date: July 22, 2015 at 08:52:31 EDT
>> > To: Sean Turner <[e-mail]>
>> >
>> > 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
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>