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

[Spencer Dawkins <[e-mail]>]

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