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

Martin Thomson <martin.thomson@gmail.com> Mon, 19 February 2018 10:14 UTC

Return-Path: <martin.thomson@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 C389E126D05; Mon, 19 Feb 2018 02:14:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 r_h-lljAbIkZ; Mon, 19 Feb 2018 02:14:56 -0800 (PST)
Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8C0F126CF9; Mon, 19 Feb 2018 02:14:56 -0800 (PST)
Received: by mail-ot0-x233.google.com with SMTP id 38so882512otg.1; Mon, 19 Feb 2018 02:14:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DKnokio8fMiFe6bUYG7n4dBZbp4lhIVUTCdmf0/zkjY=; b=PxIsZFvxtl32yw620vnsBADkcg5tbbcIknKlnnJxSnYcgBKYXFtcf5nQFi4U8MpIo+ MtUxJw92felc/qWjVYLnB+6eDw5chiHaF0Zzd9yGTuDKaNoLZW9KfARHdzqauUkn+fem cPMXRRJkbWBculIckAkzWxt3Wuyl9b+acfyFIQHTcj/L+P5Xb43nZQnFJQ1GAa/su9Wc 3sPWnR4qVsGj9a8zeuxsQ+oySvKLlolfbolx1/nFiwDL8QX4hlz/aZ+6I1E8oJzu40S1 hII0ZTsHv9FfzmKonz0wVgnf8rcgn0lPmqgHkQCARVTwz9rQ0PcfE8YTOmZptD+mkWM0 M/Vg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DKnokio8fMiFe6bUYG7n4dBZbp4lhIVUTCdmf0/zkjY=; b=bArNOsREk9bI42S8g5Wk+LzXszsxvU2fgDGnng6wycLXEFfDfxQjaJcK1eXifamFEZ +BOsRbDhbpN/CIxsoT+lxWuyK1ncXOkU0M3iMkSPdew713UeW3h54kxfXV7CKjrZJj9O YVwmMreASIYMZQZXtga/z4QN4xctI+tcsMzWze9Luho4+UrB4tgRP+wOzUnIX6BBCSrM 1lv2vOObflVqmZ1Zurp95KU4FcoEP20rfhbCtcJ9fl+bzTU6T39XZXaiu50tiSxfVG92 t6fMfmD6W/2mpsjMUac/+mxT4bTG1sxwgj4jntZooPoWAeKE4SCJ5fxtIy9Nt/rSlemc qKpg==
X-Gm-Message-State: APf1xPBByVa4ekbxsQwzK9lf0s/KRjCb3PWmbmlrhP+ZzLnV2v6MlmAA 5hyNkgEWLxVW2V1G2ZCq8bS0Yxej2JyLLoU1hS8zwcR8
X-Google-Smtp-Source: AH8x226lr3DkMzEDwermoTXGGahH1Zbqxkcmvz2xZ+YVCtbSYRp3nJ+qtTTluDs0FLEWNXEPzTH35MgRNzByhqFJqiE=
X-Received: by 10.157.12.229 with SMTP id o34mr7775394otd.352.1519035295851; Mon, 19 Feb 2018 02:14:55 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.16.85 with HTTP; Mon, 19 Feb 2018 02:14:54 -0800 (PST)
In-Reply-To: <008b01d3a94e$1cc174e0$56445ea0$@augustcellars.com>
References: <008b01d3a94e$1cc174e0$56445ea0$@augustcellars.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 19 Feb 2018 21:14:54 +1100
Message-ID: <CABkgnnUMKhnQS59Xt2=WaJp9Ywbzej6_vZ1u9R1dHE02ocir3Q@mail.gmail.com>
To: Jim Schaad <ietf@augustcellars.com>, "<tls@ietf.org>" <tls@ietf.org>
Cc: draft-ietf-tls-record-limit@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/d3PcyFUAyXymLtHx5cZWxqWrZpk>
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 10:14:58 -0000

(+tls@)

This is a good question Jim and one that I thought through during
implementation, but failed to capture in the doc.

Basically, there is no way to validate the extension if the client
includes an unknown version of TLS or an extension that it doesn't
understand.  A client can know because it should understand the
protocol as negotiated.

The text currently says "an endpoint MUST NOT send a value higher than
the protocol-defined maximum record size unless explicitly allowed by
such a future version or extension"  I think that we should add "A
server MUST NOT enforce this restriction; a client might advertise a
higher limit that is enabled by an extension or version the server
does not understand."

Does that make sense?


On Mon, Feb 19, 2018 at 5:51 PM, Jim Schaad <ietf@augustcellars.com> wrote:
> I was looking at this document relative to a specific question for Kathleen,
> and I had one thing that I would like you to look at and see if you think it
> is clear enough.
>
> I have a server that is TLS 1.2, a client that is TLS 1.2 & 1.3.   It sends
> a hello w/ and extension value of 2^14+1.  It is not completely clear to me
> that the server should accept this as a legal value and compute the min of
> it and the maximum 1.2 value as the value to use when sending messages to
> the client rather than producing an error message because the value is too
> large.
>
> Jim
>
>