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

[Nico Williams <[e-mail]>]

On Mon, Nov 10, 2014 at 02:08:06PM -1000, Yoav Nir wrote:
> The issue is that the server sends a certificate + a buffer that is a
> long-term DH public key signed with the private key associated with
> the public key in that certificate. 
> 
> Anyone who has that certificate and buffer plus the long-term DH
> private key can impersonate the server. It's delegation in the sense
> that the server can sign a DH public key and let another node
> impersonate it. 

Session tickets too are a form of delegation, with narrower scope (just
one client).  But surely clients won't be sharing these delegated DH
pubkeys with each other?

This sort of delegation is probably a fine thing, except that:

> So the argument against it is that the new signed buffer is in effect
> a credential, a certificate. Except that this kind of certificate does
> not have the PKIX stuff. Specifically, there is no revocation for that
> signature. A compromised signed  DH public key can only be revoked by
> revoking the certificate.   As we are not currently prepared to work
> on TLS delegation, we don't want to sneak delegation in through the
> back door.

it needs to have an explicit notAfter date, that needs be in the near
future.  The acceptable lifetime of a delegated server pubkey should be
comparable to the acceptable lifetime of a session ticket, and both
should be relatively short (hours, not days, and certainly not weeks).

Nico
--