Re: [saag] should we revise rfc 3365?
Nico Williams <nico@cryptonector.com> Thu, 07 June 2012 01:49 UTC
Return-Path: <nico@cryptonector.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 444E011E80C1 for <saag@ietfa.amsl.com>; Wed, 6 Jun 2012 18:49:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.224
X-Spam-Level:
X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 tb4QVKotiGud for <saag@ietfa.amsl.com>; Wed, 6 Jun 2012 18:49:36 -0700 (PDT)
Received: from homiemail-a28.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 82C1B11E80B1 for <saag@ietf.org>; Wed, 6 Jun 2012 18:49:36 -0700 (PDT)
Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id F03F41B4058 for <saag@ietf.org>; Wed, 6 Jun 2012 18:49:35 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=IS3/UxZ73m0EfwIrBt3K5XKq8+pdwTOButhJs3xnZx48 hmxdDvRUAGiOdTSsWBkMyFGOJ2M8cbocbq61xtSkkZZS8IVs28t+flsqKgcYoC0n ufi+Gy5TI/XTcd9BPaENBcwYr1t1J3bB9aoQIrZ1HW0B9cxESwGPj7SkcJhVlMc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=5PBNXyV0o5ib9rrQf/EdGjJ6/ss=; b=sSQvTcutdBh 7nC4M6ll31vw1of2QIGmRlv/6PjiuypMfNtXq6RdBjC5zgXRIMTYiDlF3hZYwKbN bcdU+pvM9GcYpATvXOK/mSf3sk6uCCPTg7SS4bpPlUhKdBm7XJ1FXz+X/28LbH/M yMzGKQ5eMyRvePv5unPpXlnBJPHVA5hw=
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id E055D1B4057 for <saag@ietf.org>; Wed, 6 Jun 2012 18:49:35 -0700 (PDT)
Received: by dacx6 with SMTP id x6so129383dac.31 for <saag@ietf.org>; Wed, 06 Jun 2012 18:49:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.203.7 with SMTP id km7mr4347530pbc.7.1339033775466; Wed, 06 Jun 2012 18:49:35 -0700 (PDT)
Received: by 10.68.15.134 with HTTP; Wed, 6 Jun 2012 18:49:35 -0700 (PDT)
In-Reply-To: <201205291613.MAA05874@Sparkle.Rodents-Montreal.ORG>
References: <4FBD6A78.2070204@cs.tcd.ie> <201205232351.TAA23415@Sparkle.Rodents-Montreal.ORG> <4FC4EBA7.9070106@cs.tcd.ie> <201205291613.MAA05874@Sparkle.Rodents-Montreal.ORG>
Date: Wed, 06 Jun 2012 20:49:35 -0500
Message-ID: <CAK3OfOjsmuBoBS2ztUh1DNjy+785W5BGsJSUMHvErw6PkXdFeA@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Mouse <mouse@rodents-montreal.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: saag@ietf.org
Subject: Re: [saag] should we revise rfc 3365?
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: Thu, 07 Jun 2012 01:49:37 -0000
On Tue, May 29, 2012 at 11:13 AM, Mouse <mouse@rodents-montreal.org> wrote: >>>> "MUST implement strong security in all protocols" >>> I believe this is too dogmatic a position, and will simply lead to >>> IETF process being ignored in [some cases]. >> So how would you phrase it so that we do get security mechanisms >> defined in most all cases but not when they're really really not >> needed (or fictional)? > > I don't think that can be done by drawing a hard line in the sand, as > 3365 tries to do, regardless of where that line is drawn. Whether > strong security is appropriate is a judgement call, as is how much > security constitutes `strong' for a particular purpose. And judgement > calls have this annoying property that they require, well, judgement, > that they can't be made by unambiguous algorithms. > > It's possible I'm just missing something, but I can't see any way to do > this that doesn't mean involving real humans. 3365 appears to be > trying to do it in a way that avoids needing to involve humans; So let's give guidance. Something like: "It should be possible to implement and deploy Internet protocols securely vis-a-vis the Internet threat model. Some protocols can have no security features and still result in deployable security. For example, it is possible to use IP without having to deploy IPsec and yet obtain decent protection -against adversaries per the Internet threat model- by using TLS or other suitable protocols. In fact, quite a few Internet protocols can be deployed with no security functionality and the resulting systems can still be secure in the Internet threat model: ARP, IP, UDP, TCP, DHCP, etcetera. Additionally, low-value services need not require any security functionality in the protocol. For some protocols a security option is desirable, such as in IP (IPsec) and DNS (DNSSEC), for some a security option would be unwelcome (e.g., UDP, DHCP), while other protocols absolutely must have security options. In general high-value (or potentially high-value) applications require security options (e.g., HTTP applications)." IMO security choices generally (but not always) belong in the application layer, though session security doesn't necessarily (e.g., TLS is below the application layer). Deploying real, end-to-end security at the IP layer (IPsec) is currently so difficult that it cannot be scaled to the Internet, while deploying decent security at the link layer is feasible and desirable but cannot address the Internet threat model (due to the link layer inherently not being end-to-end). Nico --
- [saag] should we revise rfc 3365? Stephen Farrell
- Re: [saag] should we revise rfc 3365? Mouse
- Re: [saag] should we revise rfc 3365? Steven Bellovin
- Re: [saag] should we revise rfc 3365? Joe Touch
- Re: [saag] should we revise rfc 3365? Mouse
- Re: [saag] should we revise rfc 3365? Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [saag] should we revise rfc 3365? Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [saag] should we revise rfc 3365? Mouse
- Re: [saag] should we revise rfc 3365? Nico Williams
- Re: [saag] should we revise rfc 3365? Stephen Farrell
- Re: [saag] should we revise rfc 3365? Stephen Farrell
- Re: [saag] should we revise rfc 3365? Stephen Farrell
- Re: [saag] should we revise rfc 3365? Mouse
- Re: [saag] should we revise rfc 3365? Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [saag] should we revise rfc 3365? Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [saag] should we revise rfc 3365? Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [saag] should we revise rfc 3365? Mouse
- Re: [saag] should we revise rfc 3365? Mouse
- Re: [saag] should we revise rfc 3365? Joe Touch
- Re: [saag] should we revise rfc 3365? Nico Williams