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

[Watson Ladd <[e-mail]>]

On Nov 10, 2014 4:52 PM, "Nico Williams" <[e-mail]> wrote:
>
> On Mon, Nov 10, 2014 at 02:15:34PM -1000, Daniel Kahn Gillmor wrote:
> > On 11/10/2014 01:45 PM, Watson Ladd wrote:
> > > Furthermore,  eliminating online certificates enables
> > > isolation of certs without a performance penalty.
> >
> > if we get people to move their secret keys offline by replacing certs
> > with something that is cert-equivalent for purposes of authentication,
> > then what have we gained?
>
> The ability to use cheaper, lower-performance HSMs, for one (maaaybe,
> and only where one was using an HSM to begin with).  Or, put another
> way, to handle more connections with a given HSM investment.  It's not
> nothing.  But see below!
>
> > The reason to move secret keys offline is to protect the identity
> > credentials of the TLS endpoint, not because those keys are valuable in
> > themselves.  If a delegation process creates a new object that is an
> > identity credential for the TLS endpoint, and the secret part of that
> > object remains online, we haven't actually gained anything.
>
> The delegation has to have a short lifetime because otherwise it
> might as well be a certificate issued by an intermediate CA...
>
> ...which the customer can't get because of the failure to widely
> implement and deploy PKIX name constraints.
>
> But also because of revocation: if you have to check the status of the
> key then you lose the 0rt.
>
> By putting a short lifetime on the delegation that problem goes away.
> But then there's no advantage over plain session resumption.

Can we make 0-RTT resumption? Snap start doesn't do this, and my
proposal from the summer to do this was thought to not be that great.
I'll look up exactly what was wrong and try to fix it. This may work
better than general 0-RTT exchanges, if delegation is considered to be
a problem.

I do see a benefit, which is that session resumption as currently
envisioned involves keeping keys around that can decrypt old data.
Changing this means that TLS 1.3 resumption works differently than TLS
1.2 resumption, which isn't a problem. We should at minimum fix this
PFS failure.

>
> Even if each 0rt connection can lengthen the delegatee key's life by
> having the server send a fresh signature of the key as needed, the
> server could also just refresh the session resumption state/ticket.
>
> IMO the main value in static DH is in learning the server's static DH
> pubkey out of band, via DNSSEC (DANE).  That eliminates all these
> concerns while enabling 0rt connections _every_ time for servers that
> have such keys.

So we have a root cert with RSA 1024 bit RSA, or the same delegation
point issue. It doesn't eliminate revocation concerns either: DNSSEC
doesn't guarantee liveness. (DNS can have dynamic data, but the size
is strictly limited, so stuffing a cert chain in is a bad idea).

>
> Of course, 0rt connections can't provide proper PFS to data sent
> immediately after the client's first TLS handshake message.  That's a
> problem, no?

They can limit the time the key is around, so an attacker has a narrow
window to steal the keys.

There is another set of advantages beyond those mentioned above: TLS
1.2 is annoying to think about for technical reasons, whereas OPTLS
had a good chance of avoiding those. We need to actually design a
secure protocol, not just spray and pray as we have in the past. There
was a 20 year gap between TLS 1.0, and the definitive security
analysis, which discovered new attacks, and is dependent on tool
support. A TLS 1.3 based on TLS 1.2 runs a risk of having significant
security holes in new features unless we take care to do the analysis
before deploying.

I feel the delegation problem was clearly spelled out in Hugo's
message describing the protocol. What I don't understand is why it is
a problem to have a duration-limited credential equivalent in power to
a certificate. Since there is no recording, I can't figure out what
was said and what convinced everyone this was a bad idea.

I've looked at the minutes but they are extremely sparse. What was the
worry associated with complicating the key schedule? Can someone
summarize the argument about delegation, so I can figure out if it
convinces me or not?

Sincerely,
Watson Ladd

>
> Nico
> --