[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] Closing some open comments on draft-ietf-tls-renegotiation
From:       Sebastian Gajek <gajek () post ! tau ! ac ! il>
Date:       2009-12-16 10:06:24
Message-ID: C74E7DC0.668%gajek () post ! tau ! ac ! il
[Download RAW message or body]


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" <ynir@checkpoint.com> 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: tls-bounces@ietf.org [tls-bounces@ietf.org] On Behalf Of Sebastian Gajek
> [gajek@post.tau.ac.il]
> Sent: Monday, December 14, 2009 17:42
> To: tls@ietf.org
> 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.

["smime.p7s" (application/pkcs7-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]