Re: [kitten] draft-ietf-kitten-rfc4402bis-00

Shawn M Emery <shawn.emery@oracle.com> Mon, 23 February 2015 18:18 UTC

Return-Path: <shawn.emery@oracle.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7C41A1EB7 for <kitten@ietfa.amsl.com>; Mon, 23 Feb 2015 10:18:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.312
X-Spam-Level:
X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 YrVIPCgoFXLr for <kitten@ietfa.amsl.com>; Mon, 23 Feb 2015 10:18:06 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAFBE1A1E0F for <kitten@ietf.org>; Mon, 23 Feb 2015 10:18:06 -0800 (PST)
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t1NII2tJ009526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Feb 2015 18:18:03 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t1NII2C0006449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 23 Feb 2015 18:18:02 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t1NII1Qs018976; Mon, 23 Feb 2015 18:18:02 GMT
Received: from [10.159.86.55] (/10.159.86.55) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 23 Feb 2015 10:18:01 -0800
Message-ID: <54EB6F1C.6070804@oracle.com>
Date: Mon, 23 Feb 2015 11:19:08 -0700
From: Shawn M Emery <shawn.emery@oracle.com>
User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20150125 Thunderbird/17.0.11
MIME-Version: 1.0
To: Nico Williams <nico@cryptonector.com>
References: <alpine.GSO.1.10.1501201753140.23489@multics.mit.edu> <54CE9F5B.9070808@mit.edu> <alpine.GSO.1.10.1502131258090.3953@multics.mit.edu> <54E2BFE4.4000003@oracle.com> <alpine.GSO.1.10.1502172140380.3953@multics.mit.edu> <CAK3OfOirmVgxgmW7LzO18yuC8ZFCHJs2HsB4wK-0bxpNSAFGuw@mail.gmail.com>
In-Reply-To: <CAK3OfOirmVgxgmW7LzO18yuC8ZFCHJs2HsB4wK-0bxpNSAFGuw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Source-IP: aserv0021.oracle.com [141.146.126.233]
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/VAvQzm_5fVtiGu5CAmEzAv1oZIY>
Cc: "kitten@ietf.org" <kitten@ietf.org>
Subject: Re: [kitten] draft-ietf-kitten-rfc4402bis-00
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Feb 2015 18:18:08 -0000

On 02/17/15 08:40 PM, Nico Williams wrote:
> On Tue, Feb 17, 2015 at 8:43 PM, Benjamin Kaduk <kaduk@mit.edu>; wrote:
>> On Mon, 16 Feb 2015, Shawn M Emery wrote:
>>> Thanks for your review, comments in-line...
>>> On 02/13/15 11:16 AM, Benjamin Kaduk wrote:
>>>
>>>> The original RFC 4402 security considerations include:
>>>>
>>>>      [...] if an
>>>>      application can be tricked into providing very large input octet
>>>>      strings and requesting very long output octet strings, then that may
>>>>      constitute a denial of service attack on the application; therefore,
>>>>      applications SHOULD place appropriate limits on the size of any input
>>>>      octet strings received from their peers without integrity protection.
>>>>
>>>> It is not clear to me that integrity protection is sufficient to alleviate
>>>> the denial of service attack, since verifying the message integrity may
>>>> itself consume a substantial amount of resources.
>>> I interpret this statement differently:
>>>
>>>      If integrity protection is not enforced then an attacker can construct an
>>> arbitrarily long string.
>>
>> Woudln't the attacker be able to do that without needing a very large
>> input string, though?  I guess the claims it that each individual
>> pseudo-random() call is more expensive on a long input, so your
>> interpretation is still plausible.
> I think the original was about use of the PRF to bind something like,
> say, a TLS handshake.  Now suppose you send such messages that are
> very large prior to completing authentication.
>
> Anyways, it's not a realistic problem.  I think that was stretching to
> cover what in retrospect strikes me as a non-issue.

If this is the case then I think this problem is really outside the 
scope of the specification and in general applications would be 
susceptible to such DoS attacks.  I believe the consensus in the WG is 
that this sentence be elided from the bis draft.  I will make the 
necessary update if so.  BTW, I should probably move myself as an editor 
of the draft.

Shawn.
--