Re: [TLS] Reducing record expansion overhead allowance

Martin Thomson <martin.thomson@gmail.com> Sun, 20 July 2014 02:35 UTC

Return-Path: <martin.thomson@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 A18D91B2B5A for <tls@ietfa.amsl.com>; Sat, 19 Jul 2014 19:35:39 -0700 (PDT)
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 tDWpTXMefMUw for <tls@ietfa.amsl.com>; Sat, 19 Jul 2014 19:35:38 -0700 (PDT)
Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D993B1B2B58 for <tls@ietf.org>; Sat, 19 Jul 2014 19:35:37 -0700 (PDT)
Received: by mail-we0-f169.google.com with SMTP id u56so6030737wes.14 for <tls@ietf.org>; Sat, 19 Jul 2014 19:35:36 -0700 (PDT)
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=iQAkc+LmB5jwYwNeJiv0lkLqcWHThOVJIvaIgzoVgkA=; b=u+m3KH7yVRfVh5TJ+QHLdFOApwLE1MzPI1I8BMVf1IkC+a/SeUV+ec3k+H3n5q6s5u 3xfj+tXPBc/TjzfwNAbWltp+mu88oi3EhvP9E5qZe1gSmkL/PCu1fF3YHqgXA2hS6SpX OGDvx/6VbJXfKbi2jX9Ti/mppgeLIuhBSOq30I4i8Tlm2dKQ2BL+n5MUC5dEr4O7y/fv 1JQewz34UFoTVZ7dg5bt1L8eJSNIj/WlG1SITeoiI1mDAAKzyggHwjg2B/aeuJflwN3d KJ/bKpChu1yhCX04iAsOG1sAqlJMosPzvN16k1BkeP07vj+f9Lz601niWI2fZDr0+yiO nKig==
MIME-Version: 1.0
X-Received: by 10.194.143.49 with SMTP id sb17mr9183669wjb.25.1405823736249; Sat, 19 Jul 2014 19:35:36 -0700 (PDT)
Received: by 10.194.110.6 with HTTP; Sat, 19 Jul 2014 19:35:36 -0700 (PDT)
Received: by 10.194.110.6 with HTTP; Sat, 19 Jul 2014 19:35:36 -0700 (PDT)
In-Reply-To: <CABcZeBODbabpOUgb431X3Xz_fB1KK8wn8-SMJgYZVE2V3oCLow@mail.gmail.com>
References: <CABcZeBODbabpOUgb431X3Xz_fB1KK8wn8-SMJgYZVE2V3oCLow@mail.gmail.com>
Date: Sat, 19 Jul 2014 19:35:36 -0700
Message-ID: <CABkgnnUdt0qt=WYGqBer6PcLpG3b-Ynw9bqEj3fHBSaNjveg6A@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: EKR <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary=089e013c635a6a849e04fe96d8eb
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NiMLKw0G1XkhQgvH_nuEbvOvs0g
Cc: tls@ietf.org
Subject: Re: [TLS] Reducing record expansion overhead allowance
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: Sun, 20 Jul 2014 02:35:39 -0000

I'd have thought the first 1024 was a no-brainer. As for the aead
expansion, it does seem excessive. Even if we listen to doomsayers and
acknowledge that we might need as much as 8 times the current biggest
algorithm pad from the non-aead suites, that would all allow us to halve it.
On Jul 19, 2014 2:57 PM, "Eric Rescorla" <ekr@rtfm.com> wrote:

> https://github.com/tlswg/tls13-spec/issues/55
>
> In TLS 1.2, we had the following maximum values:
>
> TLSPlaintext: 2^{14}
> TLSCompressed: 2^{14} + 1024
> TLSCiphertext: 2^{14} + 2048
>
> These overhead values allow for expansion in these transforms
> due to potential bad compression overhead or padding, etc.
>
> Wan-Teh Chang points out that we no longer have compression
> so there's no need to allow for 1024 bytes of expansion there.
>
> Minimally we should reduce the TLSCiphertext overhead to
> 2^{14} + 1024. Do people believe that we will have AEAD
> ciphers with 1024 bytes of expansion or should we reduce
> it further? I'm inclined to not re-judge that and just leave it
> at 2^{14} + 1024.
>
> Thoughts?
> -Ekr
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>