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

[Nico Williams <[e-mail]>]

On Mon, Nov 10, 2014 at 03:53:35PM -1000, Yoav Nir wrote:
> On Nov 10, 2014, at 2: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.
> 
> How short is “short”? This is yet another thing that is hosed by the
> non-availability of a secure time signal. Clocks are skewed, so if you
> use a notAfter date that is less than 24 hours away, you’re going to
> have clients thinking that this has already passed. 

The time should be relative, as a TTL.

"This resumption ticket is good for 2 hours."

"This DH pubkey is good for 2 hours."

"hours" is good.  "days" is not.

That's good enough.  The items in question should be stored in memory
(tmpfs, ...), not stable storage anyways, so all that matters is that
time tick somewhat accurately for that TTL, unless the client reboots.

> Sure, we MUST fix time. [...]

Not for this.

> > 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.
> 
> This assumes a deployed DNSSEC. That will happen some time after the
> secure time signal.

Maybe, but until and unless we convince ourselves that these delegated
DH pubkeys can have lifetimes much longer than session resumption state
tickets... then there doesn't seem to be much value in static DH here.

> > 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?
> 
> I guess you can’t have everything. 

API-wise we can: you can have integrity and confidentiality protection
immediately, but PFS not until you consume the server's handshake
message.  (The GSS-API pretty much deals with this in the context of
authentication state, and it'd take adding a boolean flag to do the same
for PFS.)

The problem is that HTTP can't know if the data to be sent is sensitive,
and probably neither can the user-agent.  They have to assume it's all
sensitive.  If you want PFS you have to settle for either: a) (EC)DHE
and no 0rt every time, or b) (EC)DHE and no 0rt occasionally + 0rt w/
session resumption w/ short-lived sessions.

Nico
--