[radext] Short draft on using larger packets for TLS fragmentation

Sam Hartman <hartmans@painless-security.com> Mon, 08 July 2013 02:29 UTC

Return-Path: <hartmans@painless-security.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D7C21F91B0 for <radext@ietfa.amsl.com>; Sun, 7 Jul 2013 19:29:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.229
X-Spam-Level:
X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEvZuP0Po1F7 for <radext@ietfa.amsl.com>; Sun, 7 Jul 2013 19:29:29 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id A5C3821F8EB2 for <radext@ietf.org>; Sun, 7 Jul 2013 19:29:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 0D34220181 for <radext@ietf.org>; Sun, 7 Jul 2013 22:24:50 -0400 (EDT)
Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulTOq61IRouX for <radext@ietf.org>; Sun, 7 Jul 2013 22:24:49 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS for <radext@ietf.org>; Sun, 7 Jul 2013 22:24:48 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F404F88414; Sun, 7 Jul 2013 22:28:43 -0400 (EDT)
From: Sam Hartman <hartmans@painless-security.com>
To: radext@ietf.org
Date: Sun, 07 Jul 2013 22:28:43 -0400
Message-ID: <tsly59hu6n8.fsf@mit.edu>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [radext] Short draft on using larger packets for TLS fragmentation
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Jul 2013 02:29:35 -0000

There seems to be consensus on the idea that TCP level fragmentation is
the right way to fragment TLS when you can afford to change the proxies.
In fact, we may even have consensus that since RADSEC is experimental
that it's reasonable to assume that people who need fragmentation and
RADSEC can upgrade their proxies.

I'm tempted to write a short draft that revises RADSEC, permits larger
RADIUS messages and introduces a mechanism for saying that  you cannot
respond to a request without being able to send a larger fragment.

This does not provide negotiation nor does it provide support for the
proxy unmodified case.  However at least as I've been reading the WG
discussion, we all seem to agree this is the best approach when it is
possible.  Also, such a draft would not preclude using a future
negotiation mechanism and could work well along-side Alex's draft.

I'd kind of like to get to noises of support soon if I'm going to put
this together.  I understand the 00 deadline has been removed but I'd
rather publish sooner than later.

If this is published I'd like this to be consider as part of the
fragmentation discussion.  It's been brought up a number of times.