Re: Security for various IETF services

"Fred Baker (fred)" <fred@cisco.com> Fri, 04 April 2014 00:23 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 DFD931A0429 for <ietf@ietfa.amsl.com>; Thu, 3 Apr 2014 17:23:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -114.501
X-Spam-Level:
X-Spam-Status: No, score=-114.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_TVD_FUZZY_SECURITIES=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 taqBISjlkXTw for <ietf@ietfa.amsl.com>; Thu, 3 Apr 2014 17:23:55 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 401D21A0025 for <ietf@ietf.org>; Thu, 3 Apr 2014 17:23:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3218; q=dns/txt; s=iport; t=1396571031; x=1397780631; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MWt+R81H3/AnUwfIP0RK3WiLv6fqH1k0RKIOeakBkKU=; b=PqeDHzs0mrQJHw/xnxVCGDjyOedNhnnA7rL9eA4Br0GheOAXgoRngOB5 zEDyevOJ7+/+AJtjTshHn+PRvEpnf64DrxDAQzy1om6X4RcOXzdCnnI0I oXbNDKjih20u9/ZhcxO72G5r985zmAt7SSHfJTJydY+zgq+rxi8/eNDa9 I=;
X-Files: signature.asc : 195
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AogFAK/6PVOtJV2Z/2dsb2JhbABXDoJ4O1EGw36BHBZ0giUBAQEDAXkFCwIBCBEEAQEBLiERHQgCBA4FDodXAwkICMgZDYciF4xXgTgRAVAHBoMegRQEkF+BNYJbgX+BbYE0izsDhUyCcECBcjk
X-IronPort-AV: E=Sophos; i="4.97,791,1389744000"; d="asc'?scan'208"; a="315027593"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 04 Apr 2014 00:23:50 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s340Noxu005700 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Apr 2014 00:23:50 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 19:23:50 -0500
From: "Fred Baker (fred)" <fred@cisco.com>
To: "l.wood@surrey.ac.uk" <l.wood@surrey.ac.uk>
Subject: Re: Security for various IETF services
Thread-Topic: Security for various IETF services
Thread-Index: AQHPT1jb9RjrCInNDUKc3+ugPcK7EpsAuYgAgAAjUICAAARUgIAACXSAgAACRICAAACHAA==
Date: Fri, 4 Apr 2014 00:23:49 +0000
Message-ID: <E87EF968-2AD5-47BD-95A7-39891975D0D0@cisco.com>
References: <533D8A90.60309@cs.tcd.ie> <290E20B455C66743BE178C5C84F1240847E779EEB6@EXMB01CMS.surrey.ac.uk> <p06240601cf639cb2113b@[99.111.97.136]> <F8AEEDAE-C8BB-4979-8122-1110DFF62770@cisco.com>, <57560B49-6A9A-4F4B-A3DD-191C5BA11722@gmail.com> <290E20B455C66743BE178C5C84F1240847E779EEB7@EXMB01CMS.surrey.ac.uk>
In-Reply-To: <290E20B455C66743BE178C5C84F1240847E779EEB7@EXMB01CMS.surrey.ac.uk>
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=_3F20B16C-E495-41C6-9886-384BC2F0F43B"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/lBUgorxsyUfcdVqwt3ydH9Aj-Kc
Cc: "randy@qti.qualcomm.com" <randy@qti.qualcomm.com>, "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: Fri, 04 Apr 2014 00:24:00 -0000

On Apr 3, 2014, at 5:21 PM, <l.wood@surrey.ac.uk> <l.wood@surrey.ac.uk> wrote:

> "It would be good to see the excellent work of Dukhovni and Parsons extended
> to include authentication of sending servers (clients) to support federation. "
> 
> Why?

In order to support data authentication.

> Lloyd Wood
> http://about.me/lloydwood
> ________________________________________
> From: ietf [ietf-bounces@ietf.org] On Behalf Of Douglas Otis [doug.mtview@gmail.com]
> Sent: 04 April 2014 01:13
> To: Fred Baker (fred)
> Cc: Randall Gellens; ietf@ietf.org
> Subject: Re: Security for various IETF services
> 
> On Apr 3, 2014, at 4:40 PM, Fred Baker (fred) <fred@cisco.com> wrote:
> 
>> 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."
> 
> Dear Fred,
> 
> XMPP provides an interesting feature called server federation.  It would be good to see the excellent work of Dukhovni and Parsons extended to include authentication of sending servers (clients) to support federation.  This is something TLS supports but is rarely used.  Such a feature could significantly improve overall security especially in the wake of RTF messages exposing users to remote code execution.
> 
> DKIM only covers message fragments and is unrelated to the actual sender by design.  A malicious link might be found in the Subject line that can be followed with user clicks which may not have been signed or users might see prepended From header fields which don't impact DKIM signature validity.
> 
> Regards,
> Douglas Otis

	• Make things as simple as possible, but not simpler.
Albert Einstein