Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance
On Mon, Nov 09, 2009 at 10:08:53PM -0600, Marsh Ray wrote:
> Nicolas Williams wrote:
> > On Mon, Nov 09, 2009 at 10:52:31PM +0100, Martin Rex wrote:
> >> I whish there was a constraint that an identity/certificate that has
> >> been established for a party during the TLS handshake MUST not change
> >> during re-negotiation,
>
> Hmm, few questions about that plan:
>
> Is this currently a defined concept in TLS: equivalence of identity?
TLS connections are not so long lived that we should worry about issues
such as, for example, public key rollover or certificate expiration
during a connection's lifetime. 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.
> 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.
> Perhaps you want to allow identities to be "strengthened" but not
> "weakened". Is this another new concept in TLS: are identities required
> to be partially- or fully-ordered?
>
> It's starting to sound like that question about ciphersuites being
> ordered according to strength.
No, I don't think so. Ordering cipher suites by strength is a complex
topic that I'd rather avoid for the specific enhancement that Martin
proposes.
> 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.
> 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.
Nico
--
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.