IETF Logo Mail Archive

Re: [TLS] padding bug

Peter Gutmann <pgut001@cs.auckland.ac.nz> Fri, 20 September 2013 13:29 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 8D21021F995B for <tls@ietfa.amsl.com>; Fri, 20 Sep 2013 06:29:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.57
X-Spam-Level:
X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 bBNsKBpNUmIv for <tls@ietfa.amsl.com>; Fri, 20 Sep 2013 06:29:38 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 002B521F9767 for <tls@ietf.org>; Fri, 20 Sep 2013 06:29:36 -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=1379683778; x=1411219778; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=rlackX4M0VS47GrRl4HKRW0Y3tM+Vo0ftulKnEkNl9M=; b=i3t+I93CZAuFbmCuPfGzrlEhlLBRAYkoc05J/jAak737AKMpFgIQP8Sq 2kSKvDvo5EKYkLmQgrvLtbxJyS3G8gL9NdAa03YxYMtDUKVEQ8mYJIB24 jHaCdrm8Afz6eClo54B0yD6u3BEiu4Cgi/ibIgsg+P08YRV1Mgis5RcH/ s=;
X-IronPort-AV: E=Sophos;i="4.90,944,1371038400"; d="scan'208";a="213251377"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 21 Sep 2013 01:29:35 +1200
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.158]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Sat, 21 Sep 2013 01:29:35 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] padding bug
Thread-Index: Ac62BXKJPwFODXUbTnCN6PSCJqCALg==
Date: Fri, 20 Sep 2013 13:29:35 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C7355674A34@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: Fri, 20 Sep 2013 13:29:43 -0000

Eric Rescorla <ekr@rtfm.com> writes:

>Of course, this naturally raises the question of whether this document will
>be accepted by the TLS WG.

It seems to be accepted by everyone except the WG chairs, who point to:

>However, as I think recent discussion indicates, there are a number of
>proposed approaches and there isn't really consensus to adopt this particular
>one

Can you provide concrete examples of this lack of consensus?  It's already
present in deployed implementations (as I mentioned a while back, the response
of one SSL library developer was "this should have been done ten years ago").
So lets reverse this, if the WG chairs think that there are viable alternative
approaches could they please point to *currently active RFC drafts* (not an
expired six-month-old text but a current draft) with authors willing to
actively champion their approaches on the list?

If this isn't possible, can we just go ahead and adopt it?  This is a decade-
old problem with a fairly trivial fix, and yet the NSA doesn't even need to
resort to BULLRUN-style subversion if the WG chairs are determined to block
its adoption.

Peter.

v2.23.0 | Report a Bug | By Email