IETF Logo Mail Archive

Re: [TLS] Mail regarding draft-ietf-tls-record-limit

Ilari Liusvaara <ilariliusvaara@welho.com> Mon, 19 February 2018 18:23 UTC

Return-Path: <ilariliusvaara@welho.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 3ABE31204DA; Mon, 19 Feb 2018 10:23:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
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 x0_2zlZppPX8; Mon, 19 Feb 2018 10:23:52 -0800 (PST)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 194A91201F2; Mon, 19 Feb 2018 10:23:51 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 75E243C8F4; Mon, 19 Feb 2018 20:23:49 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id vNEMzX1O830A; Mon, 19 Feb 2018 20:23:47 +0200 (EET)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id A129279; Mon, 19 Feb 2018 20:23:43 +0200 (EET)
Date: Mon, 19 Feb 2018 20:23:43 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Jim Schaad <ietf@augustcellars.com>
Cc: 'Martin Thomson' <martin.thomson@gmail.com>, tls@ietf.org, draft-ietf-tls-record-limit@ietf.org
Message-ID: <20180219182343.GA28980@LK-Perkele-VII>
References: <008b01d3a94e$1cc174e0$56445ea0$@augustcellars.com> <CABkgnnUMKhnQS59Xt2=WaJp9Ywbzej6_vZ1u9R1dHE02ocir3Q@mail.gmail.com> <00a401d3a99f$28679e90$7936dbb0$@augustcellars.com> <20180219171827.GA28597@LK-Perkele-VII> <00ae01d3a9a6$e3757f70$aa607e50$@augustcellars.com> <20180219175043.GA28923@LK-Perkele-VII> <00b001d3a9aa$e3700460$aa500d20$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <00b001d3a9aa$e3700460$aa500d20$@augustcellars.com>
User-Agent: Mutt/1.9.3 (2018-01-21)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/JETZgiZa7YotC4sp0Z4V7uZknRg>
Subject: Re: [TLS] Mail regarding draft-ietf-tls-record-limit
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 19 Feb 2018 18:23:54 -0000

On Mon, Feb 19, 2018 at 09:55:51AM -0800, Jim Schaad wrote:
> 
> 
> > -----Original Message-----
> > From: ilariliusvaara@welho.com [mailto:ilariliusvaara@welho.com]
> > Sent: Monday, February 19, 2018 9:51 AM
> > To: Jim Schaad <ietf@augustcellars.com>
> > Cc: 'Martin Thomson' <martin.thomson@gmail.com>; tls@ietf.org; draft-ietf-
> > tls-record-limit@ietf.org
> > Subject: Re: [TLS] Mail regarding draft-ietf-tls-record-limit
> >
> > Because the server can not know the semantics of unknown extensions, it has
> > to assume any such can alter the maximum limit. Of course, when it comes to
> > that, the server could just not error on too large limits regardless of other
> > extensions.
> 
> But if the server does not understand the new extension, then it would
> not be returned to the client so that the client would understand how
> the server decided on what the maximum value that it is going to use for
> the client is.  The client can then abort the connection if it does not
> like the new limit.  However, I think that this would only affect the
> MAY in the proposed text.

Suppose client supports large-records extension that allows records up
to 65535 bytes, but the server does not know about this extension.

Then ClientHello which has record size limit of 65519 and the
extension MUST NOT cause an abort, because such ClientHello is fully
valid.

This would be very unusual requirement. So better to specify that the
server MUST accept overly large values, internally truncating to the
negotiated protocol maximums or implementation maximums, whichever is
smaller.


The server to client direction is different matter. Client always
understands all server extensions (there is a requirement to abort
otherwise) so it knows what is the maximum possible record size for
the negotiated protocol and can check that. However, it must still
internally trunccate that to implementation maximums.


Also, the values are capability advertisments, so the server value can
be larger or smaller than the client value. Following is fully legal
and well-defined in TLS 1.3:

Client: maximum-record-size=1025 (do not send me more than 1024 bytes
of record plaintext).
Server: maximum-record-size=16385 (understood, send me any size you
like within protocol limits).



-Ilari

v2.23.0 | Report a Bug | By Email