IETF Logo Mail Archive

Re: [saag] Additions to RFC 3631?

Eliot Lear <lear@cisco.com> Mon, 21 May 2012 08:26 UTC

Return-Path: <lear@cisco.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 810F221F85A8 for <saag@ietfa.amsl.com>; Mon, 21 May 2012 01:26:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 qCOXLYrFG0Bs for <saag@ietfa.amsl.com>; Mon, 21 May 2012 01:26:56 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id B95F521F8599 for <saag@ietf.org>; Mon, 21 May 2012 01:26:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=626; q=dns/txt; s=iport; t=1337588815; x=1338798415; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=dFFLvrMKKpauPPs3hj+DKsq79vIQw6h5a7Mc2ePmWxU=; b=gAmi8r+ZTcvxsib87fD2RCF5592KG9w7NikLQIOEwSqpZG/AZMFk9DEe La5i5xn8d7CtvbD4HCuqi4r+pgkEFu5GkgXjERQoaD9cGQIHzLnGSpQaB /b+Y8akP6eXjByDQpov81i/TktwWKl9qvfDyuVKaIJlATQUQidPWTKVtq U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAIb7uU+Q/khN/2dsb2JhbABEhS2uZoEHghUBAQEEEgEQVQEQCxgCAgUWCwICCQMCAQIBRQYNAQcBAR6HbJ9BjRSSG4EmjhiBFAOVG44MgWSCaw
X-IronPort-AV: E=Sophos;i="4.75,629,1330905600"; d="scan'208";a="138222951"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 21 May 2012 08:26:53 +0000
Received: from dhcp-10-61-99-170.cisco.com (dhcp-10-61-99-170.cisco.com [10.61.99.170]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q4L8QqfX024695; Mon, 21 May 2012 08:26:52 GMT
Message-ID: <4FB9FC4C.9010107@cisco.com>
Date: Mon, 21 May 2012 10:26:52 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Mouse <mouse@Rodents-Montreal.ORG>
References: <300A2E9F-E99B-46FA-A101-E3611BD0D197@cs.columbia.edu> <201205190331.XAA28531@Sparkle.Rodents-Montreal.ORG>
In-Reply-To: <201205190331.XAA28531@Sparkle.Rodents-Montreal.ORG>
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: saag@ietf.org
Subject: Re: [saag] Additions to RFC 3631?
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 May 2012 08:26:56 -0000

Hi Mouse,

On 5/19/12 5:31 AM, Mouse wrote:
> If the point of a mandatory-to-implement mechanism is interoperability,
> allowing it to be disabled is a bad idea; it has pretty much the same
> effect on interoperability as not having it there in the first place:
> peers cannot count on its availability when speaking with peers they
> have no particular knowledge of.

How would you propose to handle the situation where an MTI algorithm is
found to be vulnerable?  Isn't it the operator's choice between running
vulnerable code and turning off MTI (yes, there is middle ground but
it's wildly complex)?

Eliot

v2.23.0 | Report a Bug | By Email