Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance

[Nicolas Williams <[e-mail]>]

On Tue, Nov 10, 2009 at 12:02:06PM -0600, Marsh Ray wrote:
> Nicolas Williams wrote:
> > On Mon, Nov 09, 2009 at 10:08:53PM -0600, Marsh Ray wrote:
> > 
> > TLS connections are not so long lived
> 
> But there is no defined upper limit.

True, and indeed, IMAP depends on that.  Are there IMAP/other servers
the request re-negotiation when a client's cert reaches/nears
expiration?

If so then my assertion that we don't have to worry about key rollover/
cert expiration would be wrong.  Indeed, it's safer to assume that that
assertion was wrong as finding out for sure would be hard.

However, this is a constraint that _applications_ could enforce, or
request be enforced by the TLS implementation (oh dear, back to APIs).

> > that we should worry about issues
> > such as, for example, public key rollover or certificate expiration
> > during a connection's lifetime.
> 
> I agree, but we should probably check that it's documented somewhere.

It probably isn't.

> > Therefore a simple Certificate octet-
> > for-octet comparison will do for identity comparison.  Anything more
> > complicated than that (and anon->non-anon) would make Martin's proposal
> > too unqieldy to consider at this point, and possibly ever.
> 
> So this restriction would not apply when another auth type is used?

I suppose non-anon->anon re-negotiation, but with the new inner->outer
connection binding should be OK once too (to allow for re-keying without
having to bother with authentication).

Yes, I see your point: this is now getting too complex.

Applications can always enforce that identities don't change around
re-negotiation, by asking the TLS implementation what the IDs were
before and after re-negotiation, and by sticking to simple rules (e.g.,
cert octet-wise comparison) even if those defeat key/cert rollover.  But
if we're going to let apps do ths (and I think now only apps should)
then there's no place in EKR's I-D for text about it, except, maybe, in
the Security Considerations section (since TLS defines no APIs).

> One subtlety is that apps (https servers) are still expecting the
> transition to preserve some guarantees about identity. Even though the
> first session is "anonymous" it still has an identity, namely it has to
> be the same party as all previous non-anonymous sessions on the same
> connection.
> 
> The proposed Renegotiation Indication extension attempts to enforce
> those guarantees, but I'm not sure it's so easy to specify that it
> shouldn't be given a lot of thought. (Consider what happens when you add
> various combinations of resumption into the mix.)

Certainly channel binding is _always_ easier than identity equivalence.

That's the main reason I have been pushing channel binding.  There are a
number of protocols where the only way to ensure there's no MITM is to
ensure that one sees the same server identity on the server end of two
channels -- that's asking for trouble.

> > Ordering cipher suites by strength is a complex
> > topic that I'd rather avoid for the specific enhancement that Martin
> > proposes.
> 
> Perhaps ordering levels of authentication is equally complex.

If you're willing to make certain simplifying assumptions (e.g., no need
for key/cert rollover), then authenticated ID equivalence can be simple.
If you're not willing to make those assumptions then yes, it becomes as
complex as cipher suite strength ordering.

> Isn't proving "I'm the same as that other guy" a form of authentication?

I.e., channel binding.  It doesn't authenticate identities, but it does
"authenticate" that two end-points are logically the same entity.

> Surely this will be allowed:
> 
>   |--- session A anon ---||-- resumed A --|
> 
> Is this allowed?

I.e., negotiate an anonymous session, then re-negotiate where the
re-negotiation is just a resumption of the anon session?  Ick.

>   |--- session A anon ---|
>   |--- session B anon ---||-- resumed A --|
> 
> I have heard that browsers may do this.

I think session resumption in a re-negotiation should probably be out,
yes.

Nico
--