Re: [secdir] Collision on changes for draft-ietf-soc-overload-control-14

Spencer Dawkins <spencerdawkins.ietf@gmail.com> Tue, 18 February 2014 21:55 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDF21A028F; Tue, 18 Feb 2014 13:55:19 -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, SPF_PASS=-0.001] 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 VsLexC1El-Wz; Tue, 18 Feb 2014 13:55:16 -0800 (PST)
Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id B272F1A026A; Tue, 18 Feb 2014 13:55:16 -0800 (PST)
Received: by mail-ob0-f181.google.com with SMTP id va2so19208305obc.40 for <multiple recipients>; Tue, 18 Feb 2014 13:55:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=6V5GYAuBCfei2ZRKiQ/pJMxbVsdIrTLjlE4cgJ+pKAQ=; b=0JjaWFiIoQwYQpEet5m1+I6X83K14I4mEsbgb4KfHMrv06vG8h7Vvwm0Hulz2ctvm9 SUzehVVLv2RR0xmdoI4VuvVTtMXEfzjLeCKSmrxY4rcIwioKN53LZS87d70jy79wdk5+ D4sfm2PP3X0ZTHwXCMq0P6bSkL47QrjhyegTfJ2OEsRHddXDdJLaRCcKIPr9H2vzFTOU uW1tzAOkEB1NQfHhFOtBN4lKZ+zh1ozCn83bTZ++0wYdqqvd+31+TKJgvW/R6AnrNSXR fw77W4dhARZ7M4t/YrwLQBR3NO1UZ0ykpHcLZrZripmLQsoUQKQ6/UCrJAFo0RTP7F4j mtFA==
X-Received: by 10.60.69.138 with SMTP id e10mr2462848oeu.75.1392760513642; Tue, 18 Feb 2014 13:55:13 -0800 (PST)
Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id m7sm62639431obo.7.2014.02.18.13.55.12 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Feb 2014 13:55:13 -0800 (PST)
Message-ID: <5303D6BF.6070901@gmail.com>
Date: Tue, 18 Feb 2014 15:55:11 -0600
From: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "Vijay K. Gurbani" <vkg@bell-labs.com>, "jsalowey@cisco.com" <jsalowey@cisco.com>
References: <5303B709.20407@bell-labs.com>
In-Reply-To: <5303B709.20407@bell-labs.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/2M2r2YbOjSjjl5mPw5hzuLsU97Q
X-Mailman-Approved-At: Wed, 19 Feb 2014 09:26:35 -0800
Cc: "draft-ietf-soc-overload-control@tools.ietf.org" <draft-ietf-soc-overload-control@tools.ietf.org>, "soc-chairs@tools.ietf.org" <soc-chairs@tools.ietf.org>, IESG IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Collision on changes for draft-ietf-soc-overload-control-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Feb 2014 21:55:19 -0000

Hi, Vijay,

Thank you for asking. Pls. see below.

On 02/18/2014 01:39 PM, Vijay K. Gurbani wrote:
> Spencer and Joe: I am attending to the secdir (Joe) and IESG (Spencer)
> comments to soc-overload-control-14.
>
> It appears that both of you hit on the same piece of text in the draft
> and requested modifications to it.  The text in question is the
> following paragraph in Section 11 of -14 [1]:
>
>    Attacks that indicate false overload control can be mitigated by
>    using TCP or Websockets [RFC6455], or better yet, TLS in conjunction
>    with applying BCP 38 [RFC2827].  Attacks that are mounted to suppress
>    genuine overload conditions can be avoided by using TLS on the
>    connection.
>
> The gist of your comments revolve around the role of TLS in the above
> paragraph.  Both of you wanted the role highlighted, and in addition
> Joe thought that the role of BCP 38 should be encouraged in all cases,
> rather than just with the TLS case.
>
> I independently agreed to a modification of the above paragraph with
> both of you, and now I have to ensure that the independently agreed-to
> modifications are distilled into a single new paragraph that is
> acceptable to both of you.
>
> Here is the text Joe and I agreed on (Jan 17, 2014):
>
>    Attacks that indicate false overload control can be mitigated by
>    using TCP or Websockets [RFC6455], or better yet, TLS in conjunction
>    with applying BCP 38 [RFC2827].  Attacks that are mounted to suppress
>    genuine overload conditions can be avoided by using TLS on the
>    connection.  Generally, TCP and Websockets in conjunction with
>    BCP-38 make it more difficult for an attacker to insert or modify
>    messages,  but it is still possible depending on where the attacker
>    is positioned in the network.  TLS provides better protection from
>    an attacker that has access to the network link.
>
> And here is the text Spencer and I agreed on (Feb 11, 2014):
>
>    Attacks that indicate false overload control are best mitigated by
>    by using TLS in conjunction with applying BCP 38 [RFC2827]. Attacks
>    that are mounted to suppress genuine overload conditions can be
>    similarly avoided by using TLS on the connection.  The use of TCP or
>    Websockets [RFC6455] without TLS can provide some protection, but
>    may be inadequate against an adversary that can modify traffic on
>    links L1 and L2.
>
> As you can see, both the suggested texts above appear to be heading in
> the same direction.  I propose the following merger of the suggested
> texts that I hope will be acceptable to both of you.
>
>    Attacks that indicate false overload control are best mitigated by
>    using TLS in conjunction with applying BCP 38 [RFC2827]. Attacks
>    that are mounted to suppress genuine overload conditions can be
>    similarly avoided by using TLS on the connection.  Generally, TCP
>    and Websockets in conjunction with BCP-38 make it difficult for an

This is working for me, but the version you and Joe crafted had "make it 
*more* difficult".

I'm hoping not to say anything like "TCP is a great security strategy"; 
"more difficult" is more like "TCP is a better security strategy than 
UDP, but ...".

Could you help me understand where that word went?

Spencer

> attacker to insert or modify messages,  but may be inadequate
>    against an adversary that can modify traffic on links L1 and L2.
>    TLS provides the best protection from an attacker with access to
>    the network links.
>
> Thank you for your time attending to this email.  Please let me know of
> any changes to the above text.
>
> [1] http://tools.ietf.org/html/draft-ietf-soc-overload-control-14
>
> Cheers,
>
> - vijay