Re: [TLS] Upload of draft-pironti-tls-length-hiding-00

Nikos Mavrogiannopoulos <nmav@gnutls.org> Tue, 12 February 2013 08:34 UTC

Return-Path: <n.mavrogiannopoulos@gmail.com>
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 43E5621F8B4C for <tls@ietfa.amsl.com>; Tue, 12 Feb 2013 00:34:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2cpf+zLVAAU for <tls@ietfa.amsl.com>; Tue, 12 Feb 2013 00:33:59 -0800 (PST)
Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by ietfa.amsl.com (Postfix) with ESMTP id BFBFC21F8B5E for <tls@ietf.org>; Tue, 12 Feb 2013 00:33:57 -0800 (PST)
Received: by mail-ee0-f48.google.com with SMTP id t10so3837846eei.35 for <tls@ietf.org>; Tue, 12 Feb 2013 00:33:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:x-enigmail-version:openpgp :content-type:content-transfer-encoding; bh=sFpg7lh27TRN9qECb8os5rrPoQ22sdUsNr1EOtd3FtY=; b=xsa366fuIzqy5vDDP7ODv4QRiN6ge49ePzfdrbT8nMZ0fHw6+VijQR9KFylDY448ye X2UJYinTpKyap/zrTH6QQSAPWwY9Ftte+TSmRpPYMCint5O5KcwaC2ESQAtcEB895O6k w5InySLnEdV3QLCfSwuh9Kxe1BEnpWJkP4j/hLOEXAaGM7zph+ZonowEbdTfKr3RCntJ vfDRlD3A3FY9lg9AxYoID4y1g9FV/vedcvZ+t6nGh1p7AOQMLDtwlHwtExB/+x2Vwox7 Ih2H0hHilCj1qov/fd81ezr7aZVsm1CttrJfZtRT7k7bh0L9jcHKEdDQhsnHM5ZFt4tr 3urw==
X-Received: by 10.14.179.5 with SMTP id g5mr60118900eem.41.1360658036834; Tue, 12 Feb 2013 00:33:56 -0800 (PST)
Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id d47sm7767596eem.9.2013.02.12.00.33.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 00:33:55 -0800 (PST)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <5119FE6D.6050400@gnutls.org>
Date: Tue, 12 Feb 2013 09:33:49 +0100
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121122 Icedove/10.0.11
MIME-Version: 1.0
To: tls@ietf.org
References: <20130212060449.4C7711A53E@ld9781.wdf.sap.corp>
In-Reply-To: <20130212060449.4C7711A53E@ld9781.wdf.sap.corp>
X-Enigmail-Version: 1.4.1
OpenPGP: id=96865171
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Upload of draft-pironti-tls-length-hiding-00
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, 12 Feb 2013 08:34:00 -0000

On 02/12/2013 07:04 AM, Martin Rex wrote:

> Alfredo Pironti wrote:
>> I uploaded a draft that explains how to correctly use extra padding in
>> TLS to effectively hide the plaintext length. The draft proposes an
>> extension where length-hiding padding can be used with any cipher.
> Since TLS implementations will likely need to support interop
> for the original ciphersuites and GenericBlockCipher, GenericStreamCipher
> and GenericAEADCipher for many years to come, I would personally prefer
> to keep the PDU changes to a minimum.
> Is there any specific benefit or necessity for the padding to be inserted
> before the plaintext, rather than directly trailing the plaintext?


The main reason is that it is much easier to remove this padding using
the current TLS parsing methods (i.e. two bytes the length, and data
follow).

The alternative would be to put the two length bytes at the end and the
padding data would be just before that. That would require a custom
parser for that packet that isn't used anywhere in TLS.

regards,
Nikos