Re: [TLS] Closing some open comments on draft-ietf-tls-renegotiation

[Sebastian Gajek <[e-mail]>]

I totally agree. My suggestion was meant as an alternative to the
TLS-renegotiation proposal. One needs to define what is meant by a state
that contains all previous session messages. I am not sure whether you need
a fake ciphersuite for that. You simply need a mechanisms that tells the
parties that TLS session is "alive" (like in the lower layer protocols). I
am a little bit worried about using the previous-session finished messages
as a sub-session identifier (SUSI) in plain text. Imagine there is in future
a higher-layer protocol that allows the attacker to access the TLS
transcript (think of a powerful application like AFLEX). Given the attacker
the finished values in clear means that he gets a verification oracle for
free. I am not saying this leads to a concrete attack. However, this oracle
is unnecessary and can be circumvented by the above proposal.


"Yoav Nir" <[e-mail]> wrote 14/12/09 22:35:

> It would be easy to require this, but it's not compliant with the current
> spec. The current spec says that the finished value depends on all the bytes
> starting with the first byte of the ClientHello.
> 
> We may do just that for some future version of TLS (1.3? 2.0? 4.0?) but adding
> the previous finished message is a change to the spec, one that requires some
> sort of signaling, either with a fake cipher suite or with an extension.
> 
> ________________________________________
> From: [e-mail] [[e-mail]] On Behalf Of Sebastian Gajek
> [[e-mail]]
> Sent: Monday, December 14, 2009 17:42
> To: [e-mail]
> Subject: [TLS] Closing some open comments on draft-ietf-tls-renegotiation
> 
> Hi there,
> 
> sorry for putting another mail into the long list of TLS renegotiation
> mails. I skimmed the TLS-renegotiation draft. Surely, a countermeasure is to
> cryptographically link the TLS sessions. There are different approaches to
> achieve this goal. I was wondering why you introduce a new cipher suite.
> Wouldn't it be easier to require that finished values are a function of all
> values received so far (incl. previous TLS sessions or at least their
> finished values.) This countermeasure is simple, complies with the present
> TLS spec and could result in faster adaption.
> 
> Is there a technicality I am not aware?
> 
> Thx for any feedback.