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.
- Re: [TLS] padding bug Peter Gutmann
- Re: [TLS] padding bug Nikos Mavrogiannopoulos
- Re: [TLS] padding bug Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] padding bug Peter Gutmann
- Re: [TLS] padding bug Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] padding bug Peter Gutmann
- Re: [TLS] padding bug Eric Rescorla
- Re: [TLS] padding bug Eric Rescorla
- Re: [TLS] padding bug Peter Gutmann
- Re: [TLS] padding bug Adam Langley
- Re: [TLS] padding bug Hugo Krawczyk
- Re: [TLS] padding bug Peter Gutmann
- Re: [TLS] padding bug Peter Gutmann
- Re: [TLS] padding bug Nikos Mavrogiannopoulos
- Re: [TLS] padding bug Ben Laurie
- Re: [TLS] padding bug Nikos Mavrogiannopoulos
- Re: [TLS] padding bug Ben Laurie
- Re: [TLS] padding bug Nikos Mavrogiannopoulos
- Re: [TLS] padding bug Peter Gutmann
- Re: [TLS] padding bug Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] padding bug Paterson, Kenny
- Re: [TLS] padding bug Bodo Moeller
- Re: [TLS] padding bug Michael D'Errico
- Re: [TLS] padding bug Ben Laurie
- Re: [TLS] padding bug Christian Kahlo
- Re: [TLS] padding bug Hovav Shacham
- Re: [TLS] padding bug Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] padding bug Martin Rex
- Re: [TLS] padding bug Andrei Popov
- Re: [TLS] padding bug Ben Laurie
- Re: [TLS] padding bug Kelly John Rose
- Re: [TLS] padding bug Lewis, Nick
- Re: [TLS] padding bug Alfredo Pironti
- Re: [TLS] padding bug Peter Gutmann
- Re: [TLS] padding bug Peter Gutmann