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

[Nico Williams <[e-mail]>]

On Mon, Nov 10, 2014 at 09:00:06PM -0800, Watson Ladd wrote:
> On Nov 10, 2014 4:52 PM, "Nico Williams" <[e-mail]> wrote:
> > 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.

TLS session resumption with tickets looks almost exactly like Kerberos,
and Kerberos definitely supports a 0rt mode: you send the AP-REQ and
immediately start sending protected data, and when the server sends an
AP-REP you switch to a new set of session keys.

In the Kerberos case there's an understanding that there's been no key
confirmation until you get the AP-REP.

The GSS-API calls this understanding "prot_ready": the security context
is ready to provide data protection services, but it's not fully
established therefore it's not safe to assume that both peers are fully
authenticated to each other.  The API has a way to signal this.

The question is: if there's something wrong with 0rt session resumption,
isn't there also something wrong with Kerberos "prot_ready"?

My take is: there's nothing wrong with it that we aren't already well
aware of and that isn't fully captured in the security considerations of
the GSS-API's prot_ready concept.

(The same prot_ready point about authentication not being complete also
applies to PFS.)

> I do see a benefit, which is that session resumption as currently
> envisioned involves keeping keys around that can decrypt old data.

Yes, because that's the only way to make it go fast (all symmetric key
crypto; no PK), and it's also why a short lifetime on the resumption
credentials is important.

Session resumption with additional PFS but no additional authentication
would also be faster than non-resumption (for non-anon ciphersuites
anyways), since there'd be just the (EC)DHE PK + the session resumption
symmetric key crypto, but it would be slower than all-symmetric-key-
crypto resumption, and it would have the sec. cons. given above as to
when PFS is available.

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

I'm not up on the details.  I think the right way to do this is as
follows:

 - model resumption as Kerberos-like authentication and key exchange;

 - add optional PFS key exchange to resumption by having the client and
   server exchange (integrity-protected, with the resumption session
   key) (EC)DHE pubkeys, and switch to using the new PFS session keys as
   soon as available;

   (one way to handle this is to make TLS modular, even if only conceptually)

 - adopt the GSS-API prot_ready concept.

Which yields:

 - 0rt for sending "prot_ready" data (no PFS, no key confirmation yet);

 - 1rt for sending data with PFS and key confirmation.

Not bad.

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

That's either missing the forest for the trees (i.e., the root key can,
and we can bet will, be upgraded to something stronger), or [likely
justified] paranoia (i.e., the root key is kept weak on purpose).

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

There's no stuffing of cert chains.  You can always build and/or staple
the chain (as Chrome supported, briefly).

And there are timestamps in some of the relevant RRtypes.

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

I meant this:

          C->S:  hello w/ resumption and ephemeral (EC)DH pubkey, CCS
-no-PFS-> C->S:  <application data>
          S->C:  hello w/ resumption and ephemeral (EC)DH pubkey, CCS
----PFS-> C<->S: <application data>

You can have 0rt w/o PFS.  You can have 1rt w/ PFS.  You can have both
too with the GSS prot_ready concept.

The problem, of course, is that in a complex protocol stack you might
have no idea if the first application record *needs* PFS, so you have to
assume that if PFS was requested, then it must be afforded, and you're
back to needing 1rt.

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

A new protocol has its costs too.  Both, new design, and extension, have
one-time costs, and both require careful analysis.  I'm not convinced
that TLS 1.2 is DoA here, but I'd love to see a fresh start if that's
realistic.  Among many benefits it'd give existing implementations' devs
a great excuse to clean house.  But again: is it realistic?

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

No recording?  That's terrible, unacceptable even.  Can we do better
than that for interims, *please*??  I've attended interim WG meetings
for other WGs in the past.  I know it's a low-tech affair by comparison
to normal IETF meetings, but TLS WG interim meetings are potentially
highly consequential!

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

Seconded.

Nico
--