Re: [Cfrg] tcp-md5 "strength"

"David McGrew (mcgrew)" <mcgrew@cisco.com> Thu, 29 September 2016 20:18 UTC

Return-Path: <mcgrew@cisco.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8480612B108 for <cfrg@ietfa.amsl.com>; Thu, 29 Sep 2016 13:18:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.837
X-Spam-Level:
X-Spam-Status: No, score=-16.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 6NBmczonXYmK for <cfrg@ietfa.amsl.com>; Thu, 29 Sep 2016 13:18:35 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C851E126579 for <Cfrg@irtf.org>; Thu, 29 Sep 2016 13:18:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2636; q=dns/txt; s=iport; t=1475180315; x=1476389915; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=CalkHeQt94tbxEZLVJmFP7GtltKdIrfvFv3zTlmXc30=; b=dsAJ8fLJ2mU4sAI+J6nvHpqmnZsjr46mOlOGfGbp3UPwunMvD++YhLyN gruKuFrd71YPfK2rkLvkV8g7XYHkHREp8y8S7r8ARt7KHPYOtx1qaumBL HVpRlwHRKKI134gkd4b/w2Tgo1xCAxZttK5jF063HcdhSvuBFbVkMy9mg E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DlAgA0du1X/4UNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgz8BAQEBAR5XfAe6USCFfgIcgU47EQECAQEBAQEBAV4nhGIBAQQ?= =?us-ascii?q?jEVUCAQgaAiYCAgIwFRACBAESiE0Orh+MbQEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RcFgQaHLgiCUIdIK4IvBYg6kT0BhiaJSY9ukGgBNCCDHAIbgVByhi2BAAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.31,268,1473120000"; d="scan'208";a="329682156"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Sep 2016 20:18:34 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u8TKIYUo024459 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 29 Sep 2016 20:18:34 GMT
Received: from xch-aln-004.cisco.com (173.36.7.14) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 29 Sep 2016 15:18:34 -0500
Received: from xch-aln-004.cisco.com ([173.36.7.14]) by XCH-ALN-004.cisco.com ([173.36.7.14]) with mapi id 15.00.1210.000; Thu, 29 Sep 2016 15:18:34 -0500
From: "David McGrew (mcgrew)" <mcgrew@cisco.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "cfrg@irtf.org" <Cfrg@irtf.org>
Thread-Topic: [Cfrg] tcp-md5 "strength"
Thread-Index: AQHSGksh+mA6ziZfz0GK0TIwZvrpF6CQ+XqA
Date: Thu, 29 Sep 2016 20:18:34 +0000
Message-ID: <4D40B732-6FC5-471F-9552-593A5D12A8AC@cisco.com>
References: <baa756a9-e42a-9f0a-f772-ca230b4e43b7@cs.tcd.ie>
In-Reply-To: <baa756a9-e42a-9f0a-f772-ca230b4e43b7@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.15.1.160411
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.117.10.228]
Content-Type: text/plain; charset="utf-8"
Content-ID: <83F8C453C383CE47B8C649E7CE04F26A@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/qpRlivQ6X5JIux8m3oo7R55HeSA>
Subject: Re: [Cfrg] tcp-md5 "strength"
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Sep 2016 20:18:37 -0000

Hi Stephen,




On 9/29/16, 8:14 AM, "Cfrg on behalf of Stephen Farrell" <cfrg-bounces@irtf.org on behalf of stephen.farrell@cs.tcd.ie> wrote:

>
>Hiya,
>
>I was just asked for an estimate for how much effort
>it might be to break tcp-md5 [1] and whether (and for
>whom:-) that might be practical, for any interesting
>kind of break.
>
>If anyone has answers or estimates handy, that'd be
>appreciated.

There are several different types of attacks that are possible on TCP-MD5:

1) attacks on the "secret-suffix MAC” used in that construction: (see Preneel and Van Oorschot, "MD-x MAC and building fast MACs from hash functions", Advances in Cryptology Crypto '95 Proceedings).  The attacker needs to find two messages M, M’ that hash to the same value, then they can substitute one message for the other, when it appears on the wire.  Applying this attack to TCP-MD5 is not exactly straightforward, because the attacker doesn’t have a chosen-message oracle, but it probably feasible with O(2^64) operations.   A good variant would be for the attacker to create a large set of (message, hash) pairs, then observe the victim traffic until a collision occurs between that set and the hash of the messages on the wire.

2) replay attacks, or session-splicing attacks.   These are especially successful if the attacker goes active and forces a reset of the TCP session, in which case about 256 resets are typically needed to create the window overlap needed to make an attack possible.

3) offline dictionary attacks, which will work whenever the key is predictable.

#1 would be the most interesting to study, #2 is probably the easiest to pull off, and #3 is the stealthiest.  

Don’t use TCP-MD5!

best

David


>
>Cheers,
>S.
>
>PS: Yes, I know tcp-md5 is pretty to very crappy,
>sadly, it's still used and hard to displace :-(
>
>[1] https://tools.ietf.org/html/rfc2385
>