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



Marsh Ray wrote:
> 
> Martin Rex wrote:
> 
> > If you lock down established identites, then I do not see a problem with this.
> 
> Really, it's the upper layers that define how 'identity' is to be
> interpreted. TLS may know that the certs on one end or the other is the
> same, but that is not the same as saying that the actual app-layer
> identities are interchangeable.

One can not blindly rely on apps to do authentication, let alone
do it consistently multiple times.  Therefore the default should
be exact identity match.


I think that an administrative change to the identity ought to have
an effect on TLS communication established with that identity/credentials,
or it is (a) a security problem and (b) a support nightmare.


If an apps protocol is so broken that it keeps running for weeks after
an administrative change but will fail a reboot, then this is a support
nightmare.


Similarly, if an application wants TLS to use OCSP and also wants
TLS to keep established session running for days or weeks ignoring
certificate expiration and revocation status, then something about
such an apps security requirements is fundamentally flawed.


> 
> >> I do see however, that data probably needs to stop flowing after sending
> >> a Finished message until receiving the peer's Finished message, but
> >> that affects only one direction and last for one round trip, not two.
> > 
> > Why Finished?  I think its everything following the ChangeCipherSpec.
> 
> For all the reasons that the Finished message was added to the protocol?
> 
> Hmmm, is app data allowed prior to the first finished message? No way,
> couldn't happen.


We're talking about renegotiation, not the initial handshake.
The current TLS spec contains a requirement that application data
can be arbitrarily interleaved with handshake message during
renegotiation.


Application data uses a different record type at the SSL/TLS record layer
than handshake messages.  The MAC for the finished messages covers
only the handshake messages, it entirely ignores all interleaved
application data records.
 


-Martin


Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.