Re: [Cfrg] tcp-md5 "strength"

Greg Rose <ggr@seer-grog.net> Thu, 29 September 2016 14:05 UTC

Return-Path: <ggr@seer-grog.net>
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 C89D012B554 for <cfrg@ietfa.amsl.com>; Thu, 29 Sep 2016 07:05:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=seer-grog.net
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 c-mBdEUPz0GQ for <cfrg@ietfa.amsl.com>; Thu, 29 Sep 2016 07:05:03 -0700 (PDT)
Received: from homiemail-a21.g.dreamhost.com (sub3.mail.dreamhost.com [69.163.253.7]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D6B112B54F for <Cfrg@irtf.org>; Thu, 29 Sep 2016 07:05:03 -0700 (PDT)
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 07CC6300061; Thu, 29 Sep 2016 07:05:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=seer-grog.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=seer-grog.net; bh=yEpYFZ7HTdMUHR9Mh pafZYC4ORE=; b=cSjgWgah8l8GPgxNJqKuq0wnxCmJirXs1G+8JDIEY+90oCuik MOp3XfYUQsx4jYKfUjVbLztphjrfNOc5Yjhi5JS817eU5YIXsJnHTx7jZllaZgsG umAX8HorNjaCjwHRo5IZyVTWfwS2Xxdcr2l6i/ClfU8JRdEZ767q6b36Eg=
Received: from [10.0.1.5] (cpe-76-167-195-197.san.res.rr.com [76.167.195.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ggr@seer-grog.net) by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id DE678300074; Thu, 29 Sep 2016 07:05:02 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_75002D38-33CF-45C1-A188-B9C08323BB88"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Greg Rose <ggr@seer-grog.net>
In-Reply-To: <baa756a9-e42a-9f0a-f772-ca230b4e43b7@cs.tcd.ie>
Date: Thu, 29 Sep 2016 07:05:02 -0700
Message-Id: <7615C52A-F83B-4B80-84C3-95FA39DBE6D0@seer-grog.net>
References: <baa756a9-e42a-9f0a-f772-ca230b4e43b7@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/gYDmlWW7SV4ybCiSZMDm0m_5mxU>
Cc: "cfrg@irtf.org" <Cfrg@irtf.org>
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 14:05:07 -0000

> On Sep 29, 2016, at 5:14 , Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> 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.
> 
> 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

Appending the shared key to the end of the data to be hashed, as a message digest, is not considered to be safe with any hash function. That's why HMAC was developed. In the face of MD5 being not target collision resistant, I'd say this is a large security vulnerability. Practically speaking, the effort might depend on the length of the messages being transmitted, and their internal format, and I don't know enough about BGP to say for sure. If the messages are multiple blocks, with fairly flexible content in them, there's software out there that can produce messages with the same validation data in seconds.

I do understand that designing a replacement, particularly one without downgrade attacks applicable, is hard, and deploying it will be even harder, but wow, this is BGP! It's a bit important to the functioning of the Interwebs.

Greg.

Phone:  +1 619 890 8236 
GPG/PGP:  1081A37C  232B EC8F 44C6 C853 D68F  E107 E6BF CD2F 1081 A37C