Re: [TLS] Re-thinking OPTLS

[Hugo Krawczyk <[e-mail]>]

Martin, one does not have to resort to delegation for using OPTLS, you can
use
ECDH certificates, except that you may need a certificate for each group you
support. The *same* goes for using ECDSA in current TLS. That is, if you
want
to be able to sign in TLS with different groups (I think this will be
needed),
then you need one certificate for each group that you want to support or
else
you need delegation (for signing subcerts for mutliple ECDSA keys).

Let me parse all the options we have.

If you don't want delegation you have three options: RSA certificates (and
pay
for per-session RSA signing performance cost), per-group ECDSA certificate
(requiring per-session signature), or per-group ECDH certificates (requires
no
signing at all and no delegation). All other cases require delegation.

So, if you don't care about per-session RSA cost AND do not care about the
added value/functionality of OPTLS, then you can keep current TLS 1.3.

Otherwise, you are left with essentially two choices.

- If you are willing to live with multiple certificates, one per-group, then
  run OPTLS with ECDH certificates: It gives the best
  security-functionality-performance return (and no delegation).

- If you don't want per-group certificates then you must resort to
delegation
  (this is the case whether you use current TLS 1.3 with ECDSA or use
OPTLS).
  But if you are going to live with delegation then there is no advantage
to
  TLS 1.3 over OPTLS.

The interesting thing about OPTLS (with the optional online signature tweak)
is that it can accommodate all of the above options in one compact protocol:

- you don't want delegation or per-group keys, use OPTLS with Online RSA
  signature (the subcert signs the client nonce)

- you don't want delegation but accept per-group keys, use OPTLS with ECDH
  certificates (no signatures, no subcert/delegation)

- you don't like the above options (hence forced to live with delegation),
  use OPTLS with offline-signed subcerts for ECDH keys.

The above, I think, is nice and provides a strong justification for OPTLS.
However, if you want the protocol to support delegation and are concerned
about the
"HSM attacks" discussed here, then you need to require servers to obtain new
certificates (ECDH, ECDSA or RSA). The point is that you don't want servers
to
use their TLS 1.2 (or earlier) keys to also sign subcerts.

​Hugo​

PS: ​I will answer the issue of key derivation separately.​

On Sat, Nov 22, 2014 at 1:14 AM, Martin Thomson <[e-mail]>
wrote:

> On 21 November 2014 19:29, Hugo Krawczyk <[e-mail]> wrote:
> > I am glad to hear this too. Please let me know what the sources of
> perceived
> > complexity are.
>
> The only items of note were:
>  - the second update to the handshake protection under g^{xs}+g^{xy}.
> We all realized that this was trivially addressed (ekr had a slide at
> the meeting that showed an easy simplification, which should be in the
> meeting materials).
>  - the delegation scheme itself
>
> I don't think that you can underestimate the costs involved with
> creating an external dependency of any sort - for any project. The
> reliance on PKIX updates could be problematic.  That said, I'm not
> entirely sure that this is as straightforward a win as you suggest.
> If such a flag existed, using it would create the delegation problem
> we were most concerned about.
>
> I'll let others explain more of the thinking behind the delegation
> problem.  I think that it's the only real issue with your proposal
> that you need to worry about.  The performance characteristics are
> probably manageable.
>