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

[Marsh Ray <[e-mail]>]

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.

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

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

>> Isn't that one of the major uses of renegotiation? To change identity?
> 
> But only from anonymous to non-anonymous, right?  That's also easy to
> specify.

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

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

>> Would that make it illegal to resume a previous session over the same
>> underlying connection if it could not be proven it was "the same" identity?
> 
> There's no authentication during session resumption handshakes --
> there's only proving that both peers remember the relevant state,
> including master secret.

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

Surely this will be allowed:

  |--- session A anon ---||-- resumed A --|

Is this allowed?

  |--- session A anon ---|
  |--- session B anon ---||-- resumed A --|

I have heard that browsers may do this.

>> What if the session's identity were strengthened? Could you end up in a
>> situation where a session could be resumed on any of several other
>> connections except the one on which it originated!
> 
> I'm not sure I follow.  See above.

1  |--- session A anon ---||-- session B client cert auth --|
2  |--- session C anon -----|
3  |--- session D anon -----------|
4  |--- session E anon -----|

Would an effect of the proposal be that session A can be resumed on
connections (2, 3, 4) but not 1?

- Marsh