headers
Vlastimil Klima | 19 Mar 2003 07:34
Picon
Favicon

Another side channel weakness in the SSL/TLS

Dear colleagues
we would like to inform you about a new attack on SSL/TLS. For further
details see the cryptologic report at <http://eprint.iacr.org/2003/052/>

Best regards
Vlastimil Klima and Tomas Rosa, {vlastimil.klima, tomas.rosa} <at> i.cz
Permalink | Reply | 0 comments |
headers
Giovanni Pedone | 24 Mar 2003 14:22
Picon
Favicon

some problems with TLS and attacks

Hello all,
I'm new to this mailing list. I'm writing some papers on TLS and studing how
it works in deep.
I have some questions about it I would like to discuss.
Anyway, I dont know whether you allow this kind of questions on this mailing
list, or not.
If you do, here are the questions, otherwise, never mind :)

Questions:

1)
The TLS v1.1 specification (RFC) states:
"If a session is resumed, it must be resumed using the same cipher suite it
was originally negotiated with."

What does this mean? To my understanding it means:

a) a resumed session cannot be resumed with a ciphersuite *weaker* than the
one it was originally negotiated with

b) a resumed session cannot be resumed with a ciphersuite *stronger* than
the one it was originally negotiated with

c) a resumed session cannot be resumed with a previos protocol version (that
is, if it was originally negotiated in TLSv1, it cannot be resumed in SSLv3
or SSLv2)

Are a, b and c right ?

2)
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Wagner | 24 Mar 2003 21:50
Picon

Re: some problems with TLS and attacks

Giovanni Pedone wrote:
>The TLS v1.1 specification (RFC) states:
>"If a session is resumed, it must be resumed using the same cipher suite it
>was originally negotiated with."
>What does this mean? To my understanding it means:

Why not interpret this as meaning that it must be resumed with
exactly the same ciphersuite and protocol version as was originally
negotiated, no changes whatsoever?

I'm really suspicious of allowing the session to be resumed with
a different protocol version, in either direction (from TLS to SSL,
or SSL to TLS).  I've never thought carefully about this possibility,
but it seems possible it might open up a potential for new and subtle
kinds of attacks.  (See Section 4.6 of my paper with Bruce Schneier
on SSL 3.0.)  Does anyone want to devote the brain power to being
sure that there aren't any such attacks?  I'm not excited to do so.

Then again, I don't know what I'm talking about.  I've never
implemented SSL or TLS, so I don't really have a clue what the
RFC was intended to mean or how implementers have interpreted it
in practice.  I'm just reacting based on security concerns.

>[ see Wagner - Schneier, Analysis of SSL 3.0 protocol ]
>Key Exchange Algorithm Rollback Attack:
>
>how is the attacker supposed to get the server choose DH key exchange method
>if the attacker cannot modify the ClientHello message being the this message
>protected by the Finished hash ?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Rescorla | 24 Mar 2003 23:10

Re: some problems with TLS and attacks

daw <at> mozart.cs.berkeley.edu (David Wagner) writes:
> Then again, I don't know what I'm talking about.  I've never
> implemented SSL or TLS, so I don't really have a clue what the
> RFC was intended to mean or how implementers have interpreted it
> in practice.  I'm just reacting based on security concerns.
I don't see that there's any advantage in allowing it.

-Ekr

--

-- 
[Eric Rescorla                                   ekr <at> rtfm.com]
                http://www.rtfm.com/
Permalink | Reply | 0 comments |
headers
Bill Frantz | 25 Mar 2003 00:26
Favicon

Re: some problems with TLS and attacks

At 2:10 PM -0800 3/24/03, Eric Rescorla wrote:
>daw <at> mozart.cs.berkeley.edu (David Wagner) writes:
>> Then again, I don't know what I'm talking about.  I've never
>> implemented SSL or TLS, so I don't really have a clue what the
>> RFC was intended to mean or how implementers have interpreted it
>> in practice.  I'm just reacting based on security concerns.
>I don't see that there's any advantage in allowing it.

I agree.  Complexity is the enemy of security.  Unless there is a really
good reason to allow changing the crypto algorithms in mid-session, it
should not be permitted.

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz           | Due process for all    | Periwinkle -- Consulting
(408)356-8506         | used to be the         | 16345 Englewood Ave.
frantz <at> pwpconsult.com | American way.          | Los Gatos, CA 95032, USA
Permalink | Reply | 0 comments |
headers
Bill Yeager | 24 Mar 2003 23:45
Picon

Latest Bad Version Oracle PKCS#1 attacks

Hi,

So, do you need to patch your server code, or does it handle these attacks? It
is amazing to me how sensitive ciphers are to the most subtle leaks of
information - like bad version errs in the pre-mastersecret.

` bill
Permalink | Reply | 0 comments |
headers
Giovanni Pedone | 25 Mar 2003 09:24
Picon
Favicon

Re: some problems with TLS and attacks

> Why not interpret this as meaning that it must be resumed with
> exactly the same ciphersuite and protocol version as was originally
> negotiated, no changes whatsoever?
>
> I'm really suspicious of allowing the session to be resumed with
> a different protocol version, in either direction (from TLS to SSL,
> or SSL to TLS).  I've never thought carefully about this possibility,
> but it seems possible it might open up a potential for new and subtle
> kinds of attacks.  (See Section 4.6 of my paper with Bruce Schneier
> on SSL 3.0.)  Does anyone want to devote the brain power to being
> sure that there aren't any such attacks?  I'm not excited to do so.

Yes, the simple interpretation is as you said: "same ciphersuite and same
protocol version". :)
Indeed, since che protocol version is somehow included in the ciphersuite
string, I suppose that the TLS specification means that sessions must be
resumed with both same ciphersuite and same protocol version.
This would be easier, maybe, if TLS_RSA_WITH_RC4_128_MD5 (for example) were
considered a different *ciphersuite* from SSL_RSA_WITH_RC4_128_MD5, just
because the protocol version is different, so without the need to specify
"with same protocol version" in the above requirement.

Anyway, the important point is that it is fine not to allow resuming with a
different protocol version (or at least with an older protocol version)

> See Section 4.4 of that paper, in particular the following sentence:
>   Now that the pre_master_secret is compromised, it is easy to
>   spoof the rest of the key exchange, including forging finished
>   messages, to both endpoints.
> The point is that the attacker learns the pre_master_secret secret
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Hopwood | 24 Mar 2003 10:42
Picon

Re: some problems with TLS and attacks


Bill Frantz wrote:
> At 2:10 PM -0800 3/24/03, Eric Rescorla wrote:
> >daw <at> mozart.cs.berkeley.edu (David Wagner) writes:
> >> Then again, I don't know what I'm talking about.  I've never
> >> implemented SSL or TLS, so I don't really have a clue what the
> >> RFC was intended to mean or how implementers have interpreted it
> >> in practice.  I'm just reacting based on security concerns.
> >
> >I don't see that there's any advantage in allowing it.
> 
> I agree.  Complexity is the enemy of security.  Unless there is a really
> good reason to allow changing the crypto algorithms in mid-session, it
> should not be permitted.

Note that the extensions spec does not allow changing extensions in
renegotiated sessions, based on similar reasoning. Here is the wording it
uses:

   Finally note that all the extensions defined in this document are
   relevant only when a session is initiated. However, a client that
   requests resumption of a session does not in general know whether the
   server will accept this request, and therefore it SHOULD send an
   extended client hello if it would normally do so for a new session.
   If the resumption request is denied, then a new set of extensions
   will be negotiated as normal. If, on the other hand, the older
   session is resumed, then the server MUST ignore extensions appearing
   in the client hello, and send a server hello containing no
   extensions; in this case the extension functionality negotiated
   during the original session initiation is applied to the resumed
(Continue reading)

Permalink | Reply | 2 comments |
headers
John Belmonte | 28 Mar 2003 17:24
Picon
Favicon

TLS + PGP

Hello,

I am developing a specification for an open web service where we use PGP and its 
existing public key infrastructure for authorization and trust.  I would like to 
incorporate the use of PGP keys in TLS authentication, but am wary that such use 
will not become a standard.

How do things look for the "Using OpenPGP keys for TLS authentication" draft 
becoming an RFC?

-John Belmonte

--

-- 
http:// if   l .   /
Permalink | Reply | 0 comments |

Gmane