Re: [TLS] TLS Digest, Vol 65, Issue 76

Ravi Ganesan <ravi@findravi.com> Fri, 18 December 2009 07:55 UTC

Return-Path: <ravi@findravi.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB5033A683F for <tls@core3.amsl.com>; Thu, 17 Dec 2009 23:55:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.316
X-Spam-Level:
X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcYhdMm404ZS for <tls@core3.amsl.com>; Thu, 17 Dec 2009 23:55:43 -0800 (PST)
Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 7F9033A6828 for <tls@ietf.org>; Thu, 17 Dec 2009 23:55:42 -0800 (PST)
Received: by pzk6 with SMTP id 6so2056149pzk.29 for <tls@ietf.org>; Thu, 17 Dec 2009 23:55:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.115.80.6 with SMTP id h6mr2405320wal.108.1261122924604; Thu, 17 Dec 2009 23:55:24 -0800 (PST)
In-Reply-To: <4B2B2E5A.90805@extendedsubset.com>
References: <mailman.5706.1261104584.32729.tls@ietf.org> <3561bdcc0912172249i678bdbf5p89f1c3b3e8fd635@mail.gmail.com> <4B2B2E5A.90805@extendedsubset.com>
Date: Thu, 17 Dec 2009 23:55:24 -0800
Message-ID: <3561bdcc0912172355j6ff1ec8bp69a22627823af092@mail.gmail.com>
From: Ravi Ganesan <ravi@findravi.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary="0016e64dc8fef06e2b047afc0f53"
Subject: Re: [TLS] TLS Digest, Vol 65, Issue 76
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Dec 2009 07:55:43 -0000

> > The attack
> > only applies of course to last category, and NOT to the abbreviated
> > handshake.
>
> No, it applies equally to session resumption "abbreviated" handshakes.
>
> They can also be conducted during a renegotiation. OpenSSL even defines
> an option SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION. I'm sure
> there's a story behind that one.
>
>
Marsh, I re-read the relevant links and it did not jump out on me. Am sure I
am missing something but can you elaborate on how this happens? i.e. the
genuine Client and geniune Server have agreed on a master secret using their
respective certs, and are trying to establish a new session using the
abbreviated handshake, using the session_key (the master_secret, which
hopefully in TLS 1.x will be renamed the session_key!). How does MITM
intervene? Thx.

-- 
Ravi Ganesan
ravi@findravi.com
www.findravi.com