Re: [TLS] RFC 6066 - Max fragment length negotiation

Martin Thomson <martin.thomson@gmail.com> Fri, 17 March 2017 01:47 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 49927129BA0 for <tls@ietfa.amsl.com>; Thu, 16 Mar 2017 18:47:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 Q5wWRooGd3u7 for <tls@ietfa.amsl.com>; Thu, 16 Mar 2017 18:47:31 -0700 (PDT)
Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 92722129B9B for <tls@ietf.org>; Thu, 16 Mar 2017 18:47:31 -0700 (PDT)
Received: by mail-qk0-x229.google.com with SMTP id y76so54465046qkb.0 for <tls@ietf.org>; Thu, 16 Mar 2017 18:47:31 -0700 (PDT)
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=0zoxvcID8xo+j0DaUQs4wbIO2NDC2kvK1Oq+jyWtx/A=; b=C3g/YVmu7eja1ujKyZIRjWdRPTID2WA5pnzfBUfndX+2pkfnaIMFtr/EDAopyYW2A4 /kwCof+EQBxxNXV8hEwRxe9MGwDtQVxUY1n1usBZlRSM1o9z7JU3gRFA3LI1FP4ibkkD s0VrC1M0B9oeUu/Ley2Q8sECXjr1mPt/HEfLXxmDRRhwzdI+mvj9R5bDODUtp+ApRLox VDaq93VszRwog79EEH+E2rGLVj+mJ075k1f9RwCV3VCQnqOa9ZEWu9k/wC/ed6x9pCji cjOSK9INssh05ts84dAnhE8lCcp5W3hEJOSESyV/02Cp5dFG3ufxpXzGKUeehj/NRDdn cRzA==
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=0zoxvcID8xo+j0DaUQs4wbIO2NDC2kvK1Oq+jyWtx/A=; b=B3Y7UT9wyWy2McJK7nMQGl8YmkEnsglyh418j4fwBbvU5/QoG1KBa/70kLMgQ6Shr8 FBbcN9m9UV9+KVSYsw8wxdD9T3beISFA/X6O/uDDIDpgfiQaMoVgt+NokBdz1e2Cjik9 9sshvSGXYxHco/T58icR7eLhVJBxl6wl/KIKesL4vvqJIMwf0bp642AKTdWIU5KtQnaD 819PQAASqDZaQ1L5VnQMRQ5bDmpTS5wQ+2ESFCVgca6marY79twkeJc3lviztLtMo1UV BTJXx5cfxGneNGnzpKrYLgA0nUzecHfffDtPhVVcfzHh89z9AnQ/HyFVcnG7CnsaZMaC UO5Q==
X-Gm-Message-State: AFeK/H1bm9QEnacbGS+OWd/TI66MpVEsNw5X822FlN0xQsk/HxK2muQJwjUXETnyT90aaXWU9iMVOHo0K6DTfA==
X-Received: by 10.55.136.2 with SMTP id k2mr7700255qkd.316.1489715250689; Thu, 16 Mar 2017 18:47:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.27.194 with HTTP; Thu, 16 Mar 2017 18:47:30 -0700 (PDT)
In-Reply-To: <1489710142144.88978@cs.auckland.ac.nz>
References: <CAD8WAomJLs4hdaso9hT036=UORjT9=H5-oCHbdSofuv++n3rYg@mail.gmail.com> <1489706298995.98317@cs.auckland.ac.nz> <855C5079-FDA7-4E68-AE29-1E9605B495D7@broadcom.com> <1489707933992.42551@cs.auckland.ac.nz> <CABkgnnVRZBwXHZ6w=gX9pykNpXp80OLP1pe-VMg-uO-C6O8yEQ@mail.gmail.com> <1489710142144.88978@cs.auckland.ac.nz>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 17 Mar 2017 12:47:30 +1100
Message-ID: <CABkgnnXiB5ksGbbPqDP3D=FVdQu9ht0vD8-T-5HTaEKQQE4+9w@mail.gmail.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Cc: Nitin Shrivastav <nitin.shrivastav@broadcom.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/mFVvGPALCRTrf6IKVO6wuWqYvKQ>
Subject: Re: [TLS] RFC 6066 - Max fragment length negotiation
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: Fri, 17 Mar 2017 01:47:33 -0000

On 17 March 2017 at 11:22, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
> Is that from actually trying it with clients, or just assuming that
> implementations will do what the spec says?

I know for certain that NSS explodes.  Not from trying, but from
knowing that part of the code very well.  I'm fairly certain that
boringSSL does too, knowing David.

You say negative utility, but I've found that if you can get away with
stricter policing of these things, it helps prevent servers from
starting to do the wrong thing.  The odds that someone tests a new
server implementation against major browsers is fairly good.

In any case, what would you expect a client to do if they don't
advertise the extension?  In this case, max_fragment_length is so
badly designed that you can actually argue that it has utility, but I
don't consider that as a good argument for the general case.