Re: [OPSEC] minutes part 2

R Atkinson <ran.atkinson@gmail.com> Wed, 17 December 2008 16:08 UTC

Return-Path: <opsec-bounces@ietf.org>
X-Original-To: opsec-archive@optimus.ietf.org
Delivered-To: ietfarch-opsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 307983A6B10; Wed, 17 Dec 2008 08:08:37 -0800 (PST)
X-Original-To: opsec@core3.amsl.com
Delivered-To: opsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 037EA3A6B10 for <opsec@core3.amsl.com>; Wed, 17 Dec 2008 08:08:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWyKDooLAJZB for <opsec@core3.amsl.com>; Wed, 17 Dec 2008 08:08:35 -0800 (PST)
Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id C1CC53A6B03 for <opsec@ietf.org>; Wed, 17 Dec 2008 08:08:34 -0800 (PST)
Received: by qyk4 with SMTP id 4so3802297qyk.13 for <opsec@ietf.org>; Wed, 17 Dec 2008 08:08:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=z2VB44K/IcAsBQI6J3h3By/+IxHMuDUyREzd5dpX8QI=; b=HlbqBgB3CdOZlPLPKy+6+WAAfQloLrSHguhRCUUpgGm15cveHW3Cahg18ED+Mdnrh6 waO565PfdmOuolBWK2JHjxLf7jnMiZAy4UqEC6bQuR7jMVLUpyiEswsNIF2Y2ImilD93 6rGn4N2xsvG4gL5bBomgVNP/T7cjVG3H6YAHI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=A6b57yQ/raWvo/6NKeMLqJP1upCyHd6Ul5XBps3vhBLDIURDCNbUOE06O2aDUITw14 CvU/yh71tg4juXoHc+m4lJDp9UW1WYLIeo8UW2opY04uzIkNqWzUfF0AG96e29vNocYt THiaNdgH1+Mz9sdmH920VHIST5SNOrIBLNrnA=
Received: by 10.215.66.1 with SMTP id t1mr992871qak.327.1229530106682; Wed, 17 Dec 2008 08:08:26 -0800 (PST)
Received: from ?10.10.1.61? (67.111.52.130.ptr.us.xo.net [67.111.52.130]) by mx.google.com with ESMTPS id 7sm1608250qwf.27.2008.12.17.08.08.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 17 Dec 2008 08:08:26 -0800 (PST)
Message-Id: <0D015957-EF5A-4D25-8C1B-410DFE17E46B@gmail.com>
From: R Atkinson <ran.atkinson@gmail.com>
To: opsec@ietf.org
In-Reply-To: <77ead0ec0812161846g1cfa399etff00328e1ed79610@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Wed, 17 Dec 2008 11:08:24 -0500
References: <14198D76-AA32-4E02-9425-0700ED57B07B@gmail.com> <77ead0ec0812161759g4900bd98h6ad6c07bb0d81fe3@mail.gmail.com> <69BA9195-6869-45F1-832F-9040901F0C9F@gmail.com> <77ead0ec0812161846g1cfa399etff00328e1ed79610@mail.gmail.com>
X-Mailer: Apple Mail (2.930.3)
Subject: Re: [OPSEC] minutes part 2
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: opsec-bounces@ietf.org
Errors-To: opsec-bounces@ietf.org

On  16 Dec 2008, at 21:46, Vishwas Manral wrote:
> The second draft is about defining the set of algorithms for IGP just
> like RFC4835 does for IPsec. This is to provide minimal set of
> cryptographic algorithms to be supported for basic interoperability.

There isn't an actual problem here to be solved.

You have reported 2 in-progress implementations of HMAC-SHA
for IGP authentication, with 2 being a lot smaller than the
set of router families in the world.

By contrast, support for Keyed-MD5/HMAC-MD5 is either
very widespread or universal.

> With the additional support of new crypto algorithms into IGP's there
> are now multiple crypto algorithms defined for the same IGP. Also as
> we move forward and security vulnerabilities are found in
> cryptographic algorithms, the algorithm support for Routing Protocols
> can be changed without change of the base protocol RFC's.

The existing specs would not need to be changed -- whether or not
such a document existed.  Your assumption that they would
need to be changed is not correct.  This is a "Red Herring".

> The issue was seen in IPsec case where we had to move from DES to
> 3-DES to AES-CCM.

IGP authentication is not IPsec; they don't have the same
issues.

And this is not the OSPF WG or the IS-IS WG, which would be
the WGs chartered to make such implementation recommendations
for their respective IGPs.

> Based on the reccomendations of the IETF on various
> crypto algorithms,

The IETF has no IETF-wide policy on cryptographic algorithms.
According to IETF practice, such decisions are up to each
individual WG.

> we have recommended cryptographic algorithms as
> MUST- to SHOULD +  etc to also give a sense of direction.

I've cited here several specific scientific papers noting that
SHA is just as vulnerable as MD5, which you then agreed
was correct.  (URLs provided in email from me yesterday)

NIST has noted publicly that "serious attacks" have been
published against SHA. (URLs were provided yesterday
to the NIST web site to support this statement.)

I noted earlier that neither Keyed-Hash nor HMAC-Hash
have known vulnerabilities, which you also agreed
was correct. (OPsec list archives)

So one can see that it does not make scientific sense
for this WG to recommend anything beyond "some form of
cryptographic protection" -- because there is no scientific
reason to believe that either approach is better or
stronger than the other.

Recommending SHA as a "future direction" is particularly
silly -- because NIST is in the process of deprecating
and replacing the entire current SHA algorithm family
due to concerns about its strength.  (See the NIST URLs
I provided to the WG yesterday)

(By the way, the NIST announcement that it would replace
SHA was made in 2007.  The closing date for proposals to
NIST for a new algorithm was October 31st 2008.  The new
hash algorithm will have different maths, although it might
[confusingly, IMHO] be called SHA-3.)

If some WG were going to suggest a "future direction"
for IGP cryptographic authentication, then an entirely
different approach (e.g. some form of AES CBC MAC,
such as Rogaway has published) is likely the sensible
scientific approach to take, given what is known now.

So far as I am aware there is no work in progress on
specifying such a thing for any IGP.  (Maybe that is
an opportunity for someone.)

There might be individual users who choose to undergo the
pain of migration later from existing approaches (e.g. MD5)
to something else (SHA or whatever) for local policy reasons,
but that local policy choice is not an IETF matter,
and that direction isn't supported by science available
to this WG right now.

Yours,

Ran
rja@extremenetworks.com


_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec