Re: [TLS] Call for Consensus on removal of renegotiation

[[e-mail] (Martin Rex)]

Peter Gutmann wrote:
> James Cloos <[e-mail]> writes:
>> 
>>If tls1.3 drops rekeying established sockets, then one reasonably can predict
>>that its adoption will be limited enough that any security benefits it has
>>over 1.2 will be, mostly, for naught.

I think that TLSv1.3 will be largely ignored for many other reasons
(except maybe by a few (heart)bleeding edge implementations that spend
 their scarce resources to implement every TLS kitchen sink rather than
 for quality of the stuff that is important).


> 
> That's pretty speculative.  My speculation is instead:
> 
>   If tls1.3 drops rekeying established sockets, then one reasonably can
>   predict that people won't rekey established sockets any more.
> 
> I'd say that's far more likely.

For the purpose of rekeying, I still think that renegotiation is
a pretty good solution.


I started my adventure into crypto protocols as a consumer of
GSS-API and participant of the IETF CAT working group in 1995.

GSS-API itself does not have renegotiation or rekeying, and back
then (MIT) Kerberos 5 was the canonical GSS-API mechanism,
was using (single)DES for encryption and it was enforcing a
lifetime on GSS-API security contexts, deriving it from the
lifetime of the Kerberos ticket that authenticated the security
context.

If an application wanted (a) use Kerberos 5 and (b) be able to
communicate for more than 10 hours (often less, because the
TGT may have been acquired a few hours ago), then a significant
amount of complexity was thrown on the application to deal with
this.

I implemented a communication protcol for our application that will
try to "transparently" replace an expiring security context with
a new one, but MIT Kerberos 5 did not exactly make this easy:

MIT Kerberos enforced security context expiration not just
on send (gss_wrap, gss_get_mic), but also on receipt (gss_unwrap,
gss_verify_mic) so that a message that was protected with
only little security context lifetime left and was delayed
in transport or delayed in processing on the receiver side
would fail to unprotect (i.e. message lost).  Most application
protocols can not deal with lost data

Since the security context lifetime is derived from the ticket
lifetime (and service ticket lifetime derived from TGT lifetime),
a security context with a longer lifetime could only be established
when a new TGT was available.  With MIT Kerberos, acquisition of
a new TGT for a user required _manual_user_intervention_.

So one's protocol layer above gssapi may want to try establishing
a new security context with sufficient margin to expiration of the
existing context to prevent protected messages from "expiring"
in transit or on the receivers incoming message queue.

Since the user may have not provided a new TGT yet, one may have
to continue using the existing security context as fallback
as long as it lives.  The client can locally check the lifetime
of his credential and avoid to insert a useless context establishment
handshake that results in a new security context with not more lifetime
than the existing.  But when the server is the one who starts talking
after a longer period of silence on an established channel, it may
notice that the existing security context is close to expiration or
already expired, and then needs to ask the client to try establishing
a new security context before the server can convey the data under
protection.  Any such handshaking for the purpose of trying to replace
an expiring (but not yet expired) security context needs to be performed
in a fashion that is _not_ a deadly embrace, the fallback to continue
using the not-yet-expired security context should be used.


Microsoft implemented their own Kerberos 5 in Windows 2000,
and in Windows2000 Beta3, Microsoft briefly tried to enforce security
context expiration in the MIT Kerberos style.  It was a pretty fierce
crashing and burning of all Microsoft apps on top of SSPI.  Exactly
none of their apps was able to handle it.  Beta3 (the last before rc1)
might have been a little late to get back to the drawing board and
redesign communication protocols to cope with security context
roll-over.  So security context expiration was disable for Win2Krc1
and was never seen again.

Since all Microsoft apps are completely ignoring the various SSPI
lifetimes (credentials and security context lifetime), this part
is largely untested.  While the info was mostly correct in Win2K,
ever new Window release has added situations when bogus values
are returned from SSPI.  Client and Server on different machines
may be told differing security context lifetimes, and there are
Citrix usage scenarios when it is *IMPOSSIBLE* to create a security
context that SSPI does *NOT* report as expired (via the lifetime
parameter value).




Not using or not being able to support a protocol feature is one thing,
but over time, the credential and context lifetime reporting at SSPI
for Kerberos went from OK to flaky to buggy to close-to-unusable (today).

While Microsoft Kerberos has the nice capability to automatically acquire
and refresh TGTs, the mechanism is flaky.  Tickets may get replaced only
*after* they've expired (and handshakes might get performed with
expired tickets, resulting in expired security context being returned
from the security context establishment handshake.

In some Citrix scenarios, the reported lifetime of security contexts
differ between client side and server side by the time zone difference
between server and client.  When the time zone difference is >= 10 hours,
it is impossible to establish non-expired security contexts...


Another challenge for a security context roll-over is in the Kerberos
protocol itself.  Authenticators have a limited lifetime (typically
5 minutes).  This may be a problem for a communication link of an
application that is processing stuff in batch (request pipelining) and that
may exhibit response times of 10+ minutes.  New requests from the network
are read from the network and placed into a local message queue
(so that TCP doesn't tear down the connection), but the actual
processing of the message may get delayed for 10+ minutes, at which
point the acceptor may be faced with an error because the authenticator
has "expired".


Bottom line:  if renegotiation is dropped from TLSv1.3, then long-lived
connections with either not rekey, i.e. kiss forward secrecy good-bye,
or long-lived connections will kiss TLSv1.3 good-bye.

The latter of these two options is less work and immediately available...



-Martin