Re: [TLS] padding bug

Peter Gutmann <pgut001@cs.auckland.ac.nz> Tue, 24 September 2013 05:02 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623D821F915C for <tls@ietfa.amsl.com>; Mon, 23 Sep 2013 22:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.578
X-Spam-Level:
X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmpYXyP3OKJT for <tls@ietfa.amsl.com>; Mon, 23 Sep 2013 22:01:59 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id B7BF311E810F for <tls@ietf.org>; Mon, 23 Sep 2013 22:01:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1379998902; x=1411534902; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=1I/R7D5d26zpfQGrgHrgQfzzgKBXMSiflSeWQEKxPPg=; b=N/fLI+hui2nc50FWkFzpJNkX11BvvSU0MCM1FJnVHFbfQM5Mav6b0+Zf Gj/l+hIoHACdxWMQRSGZd7RVckCFHE9jFokXIKhOk5PJC46B+hdIb15xS NBsSiXefmYDvbcYKnrsCq898Nq0XfRNXQHBkWcy42H/UTJjJIGFvgRGM7 g=;
X-IronPort-AV: E=Sophos;i="4.90,968,1371038400"; d="scan'208";a="213850200"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing
Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 24 Sep 2013 17:01:41 +1200
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.158]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.02.0318.004; Tue, 24 Sep 2013 17:01:40 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] padding bug
Thread-Index: Ac644yexka+JHcxaQ6OFXY9dkTUeRA==
Date: Tue, 24 Sep 2013 05:01:40 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73556760B8@uxcn10-6.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 24 Sep 2013 05:02:04 -0000

Eric Rescorla <ekr@rtfm.com> writes:

>These messages from Nikos look negative to me:
>http://www.ietf.org/mail-archive/web/tls/current/msg09809.html
>http://www.ietf.org/mail-archive/web/tls/current/msg09520.html

That's just Nikos complaining (as Ben Laurie put it, "I've seen no objection
that makes any sense").  I've just responded to Nikos yet again, see my
message of a few minutes ago.

>We think this would benefit from F2F discussion and I would invite you or
>someone else in favor of this draft (or another approach) to present in
>November in Vancouver. If there is WG consensus for this, we can adopt it
>then.

Well if you guys are willing to pay my air fares to Canada to repeat, yet
again, all the stuff that's already been gone through on the list, then I
guess I can do it.

This work has been stalled now since the start of the year.  Nothing else has
moved forward.  So it's not a matter of chosing between several competing
viable proposals, it's a choice between (A) "adopt a simple fix for a decade-
old problem that's been repeatedly exploited" and (B) "don't fix the problem,
allowing further exploitation in the future".

I want to apply the simple fix, and I get the feeling the rest of the WG does
too.  It appears that the WG chairs don't care about fixing it, or at least in
nine months they've shown no interest in moving it forward.

So I'd like to adopt Ben's proposal:

  How about we take a vote?

Could people please indicate on the list whether they'd prefer option (A), fix
the problem with EtM, or option (B), which appears to be "do nothing", or at
least "delay indefinitely", which amounts to the same thing.

Peter.