Re: [TLS] MITM Attacks on Client Authentication after Resumption

Watson Ladd <watsonbladd@gmail.com> Mon, 03 March 2014 21:55 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19BAC1A0176 for <tls@ietfa.amsl.com>; Mon, 3 Mar 2014 13:55:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oiUJMAOQW0NU for <tls@ietfa.amsl.com>; Mon, 3 Mar 2014 13:55:35 -0800 (PST)
Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) by ietfa.amsl.com (Postfix) with ESMTP id AD75D1A00D3 for <tls@ietf.org>; Mon, 3 Mar 2014 13:55:35 -0800 (PST)
Received: by mail-yk0-f176.google.com with SMTP id 19so12095364ykq.7 for <tls@ietf.org>; Mon, 03 Mar 2014 13:55:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nuL/RzZV57MHi1sQ/fuODll17oe2NaSNZSswZfndPsA=; b=GV13yulgcmQdmD+ty0oOO/QpI4ay3vp8rtfgRtIVUJITikGfeoH8q3oymIfMjekI6t zN1q12uhxgyEaTz0qxYP1gWKo+Eoha5e7jqqbsnUWIPybsHWrrUowrkYpguE25RVwjGS A2q+maW+xmn9OZaTyXSWhUW8+zUxsXRA9RpZ3rNBv8qtFDjgSHY6BD2gh3uBKN/yQCJi XwP/EBsxBlEdeBeCuvtGQoay2EESRqrl9EFor1Gna/2ijgunDfI/WNvJIa51Xw5/v0G7 J2NvvhECazSZa10CcC4Lpgi1jztaNcKAfeXOH1OwKVvRgfQLRV+WGUjfMFi8deIWtYi8 zq0g==
MIME-Version: 1.0
X-Received: by 10.236.142.198 with SMTP id i46mr9923333yhj.66.1393883732541; Mon, 03 Mar 2014 13:55:32 -0800 (PST)
Received: by 10.170.92.85 with HTTP; Mon, 3 Mar 2014 13:55:32 -0800 (PST)
Received: by 10.170.92.85 with HTTP; Mon, 3 Mar 2014 13:55:32 -0800 (PST)
In-Reply-To: <5314AF9B.8000402@drh-consultancy.co.uk>
References: <BB2FE60E-A7CA-4EA7-BFC8-AB794EC6FF00@inria.fr> <5314AF9B.8000402@drh-consultancy.co.uk>
Date: Mon, 3 Mar 2014 13:55:32 -0800
Message-ID: <CACsn0cmc=zDLeUWi-cNEK=rNzmZs7OBjwArSwtj15N+=RAT5XQ@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Dr Stephen Henson <lists@drh-consultancy.co.uk>
Content-Type: multipart/alternative; boundary=20cf306849edbc884e04f3bad838
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mjY7sIgMZthXWXPd10u-y_a-X24
Cc: tls@ietf.org
Subject: Re: [TLS] MITM Attacks on Client Authentication after Resumption
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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/options/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: Mon, 03 Mar 2014 21:55:37 -0000

Dear all,
This is the third time we've had a bug in the protocol in an area that was
supposedly fixed. In this case it's the interaction between two different
flows breaking a tacit assumption in the state machine, and the complex
semantics of session renegotiation, both of which were previously noticed
in 2009 with the Rex/Ray attack.

There are two ways to make apparently secure systems: make the system so
simple it can't have flaws, and make it so complicated we can't find the
flaws. Luckily the authors are completing a verification which should
hopefully ensure that there aren't any more flaws. Unluckily we have
decided to make TLS 1.3. Will TLS 1.3 actually make a protocol so simple
that it has no flaws? Or will it continue to be filled with surprises?

Furthermore,  I would like to ask the chairs what they plan to do about the
clear issues in the process that this has exposed, and why users should
continue to trust TLS with confidential information.

Username password and cookies continue to be widely used in part because
client authentication in TLS has not had a good run. We need a new
mechanism for client authentication.

Sincerely,
Watson Ladd