[apps-discuss] APPSDIR review of draft-ietf-krb-wg-des-die-die-die-04

Tobias Gondrom <tobias.gondrom@gondrom.org> Wed, 18 April 2012 03:40 UTC

Return-Path: <tobias.gondrom@gondrom.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7780221F84CD for <apps-discuss@ietfa.amsl.com>; Tue, 17 Apr 2012 20:40:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.777
X-Spam-Level:
X-Spam-Status: No, score=-96.777 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-O7rxWmY0yk for <apps-discuss@ietfa.amsl.com>; Tue, 17 Apr 2012 20:39:59 -0700 (PDT)
Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id B4E8911E8076 for <apps-discuss@ietf.org>; Tue, 17 Apr 2012 20:39:58 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=BZG7HHqHaCc2Kb4d5X9Febcsd/MvA+j7AuP/SwlnxylkGPaSyvaJWcQD0nKnQO8HKXA1o067glwgLdJo2lFf7z5rU5IUJHJdCe1oL03nsFRYybmaqIyNQgvS3Bi7b8dI; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type;
Received: (qmail 13416 invoked from network); 18 Apr 2012 05:39:46 +0200
Received: from n2028211917.imsbiz.com (HELO ?10.65.1.159?) (202.82.119.17) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Apr 2012 05:39:46 +0200
Message-ID: <4F8E377D.2010601@gondrom.org>
Date: Wed, 18 Apr 2012 11:39:41 +0800
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: apps-discuss@ietf.org, draft-ietf-krb-wg-des-die-die-die.all@tools.ietf.org
Content-Type: multipart/alternative; boundary="------------010108090005000106040702"
Cc: iesg@ietf.org
Subject: [apps-discuss] APPSDIR review of draft-ietf-krb-wg-des-die-die-die-04
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Apr 2012 03:40:03 -0000

I have been selected as the Applications Area Directorate reviewer for 
this draft (for background on appsdir, please see  
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments 
you may receive. Please wait for direction from your document shepherd 
or AD before posting a new version of the draft.

Document: draft-ietf-krb-wg-des-die-die-die-04
Title: Deprecate DES, RC4-HMAC-EXP, and other weak cryptographic 
algorithms in Kerberos
Reviewer: Tobias Gondrom
Review Date: April-17

Summary: The document is ok for publication.

Major Comment:
Agree that we should/must deprecate the weak cryptographic algorithms in 
Kerberos.
However IMHO, I do not agree with the reasoning "to not actively 
discourage the use of RC4-HMAC" in section 7.
I understand that interoperability is of major importance, but at some 
point a very weak algorithm will give users a false sense of security 
while exposing them to malicious attacks. And keeping RC4-HMAC supported 
does also expose the majority of the community (who is not using the 
deprecated Windows Versions) at possible risks to downgrade attacks.

I believe even though the support of the complete Internet community is 
vital for standards, the support of deprecated (and AFAIK no longer 
supported OS versions) should not be the deciding argument behind our 
decisions here. Even old OS can be patched or fixed by the vendor or 
other service providers and it should not justify to keep a weak algorithm.

Best regards, Tobias