Re: Security for various IETF services

"Fred Baker (fred)" <fred@cisco.com> Thu, 03 April 2014 23:40 UTC

Return-Path: <fred@cisco.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4AF1A036D for <ietf@ietfa.amsl.com>; Thu, 3 Apr 2014 16:40:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.511
X-Spam-Level:
X-Spam-Status: No, score=-109.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
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 5V3lFI3lA8zp for <ietf@ietfa.amsl.com>; Thu, 3 Apr 2014 16:40:11 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2351A0369 for <ietf@ietf.org>; Thu, 3 Apr 2014 16:40:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2392; q=dns/txt; s=iport; t=1396568407; x=1397778007; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=SsRsnUlMPkSjgMmSDvuEI8a5HXR+ncWHVQ89k8sJABQ=; b=CWrSoNuaamYkVPs5VDAyi7TCsZZu62OpzbJ99MOOihIM9hNTehRI2AKD tR2ZMiwdVYiTBFQNSWFG0ZlXdutE8vbbLXJqur7K1PD9iAKie+GqSwH+X f8e0ie+0eEUTIV6H0PmNl1wdolbvEqIE0wIeCJ8mqGsSizOF8DgGu1F6B c=;
X-Files: signature.asc : 195
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkQFACvwPVOtJA2L/2dsb2JhbABXgwY7V8N/gRsWdIIlAQEBAwF5BQsCAQgOODIlAgQOBQ6HYwjPVheODxEBUAeDJIEUBJBfgTWGR4YajCSDMIFyOQ
X-IronPort-AV: E=Sophos; i="4.97,791,1389744000"; d="asc'?scan'208"; a="32731602"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-3.cisco.com with ESMTP; 03 Apr 2014 23:40:01 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s33Ne19G023342 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Apr 2014 23:40:01 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.247]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Thu, 3 Apr 2014 18:40:00 -0500
From: "Fred Baker (fred)" <fred@cisco.com>
To: Randall Gellens <randy@qti.qualcomm.com>
Subject: Re: Security for various IETF services
Thread-Topic: Security for various IETF services
Thread-Index: AQHPT1jb9RjrCInNDUKc3+ugPcK7EpsAuYgAgAAjUICAAARUgA==
Date: Thu, 03 Apr 2014 23:40:00 +0000
Message-ID: <F8AEEDAE-C8BB-4979-8122-1110DFF62770@cisco.com>
References: <533D8A90.60309@cs.tcd.ie> <290E20B455C66743BE178C5C84F1240847E779EEB6@EXMB01CMS.surrey.ac.uk> <p06240601cf639cb2113b@[99.111.97.136]>
In-Reply-To: <p06240601cf639cb2113b@[99.111.97.136]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.19.64.115]
Content-Type: multipart/signed; boundary="Apple-Mail=_E9BB0649-48A2-4608-8A3F-A228C4DAC22A"; protocol="application/pgp-signature"; micalg="pgp-sha1"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/VfzD4ot32s-ESm8GcOr2vtYry2U
Cc: "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Apr 2014 23:40:16 -0000

In view of recent issues in TurkTelecom and Indosat, it seems like the simplest reason would be to ensure that data putatively obtained from the IETF would in fact be obtained from the IETF.

From my perspective, I would support a statement to the effect that IETF technology should be obtainable using https or whatever else we are recommending as "secure.” I’d also be in favor of asking IETF contributors to obtain and use PGP keys and/or DKIM encodings to sign messages. And of asking that IETF tools not reformat email in ways that corrupt data that has been signed.

To that end, I could imagine a requirement for some kind of roadmap. “The tools that access the IETF SMTP and HTTP sites use protocols X, Y, and Z. After <date>, we require them to use Secure X, Secure Y, and Secure Z, and traffic originated by the IETF sites shall use such protocols."

On Apr 3, 2014, at 4:24 PM, Randall Gellens <randy@qti.qualcomm.com> wrote:

> My reaction is also to ask "Why?"  Security and privacy involve trade-offs where various costs (including operational difficulty) are weighed against the benefits, such as protecting information from unauthorized disclosure or modification.  So, I'd suggest that a blanket statement isn't a good idea, but rather, a service-by-service decision should be made.  For example, XMPP and document submission may justify requiring encryption while email and document retrieval might not.
> 
> -- 
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself only
> -------------- Randomly selected tag: ---------------
> !!!!!CP MBI na ni deppart m'I  !pleH
>