RE: Security for various IETF services
"Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net> Mon, 07 April 2014 19:51 UTC
Return-Path: <matthew.kaufman@skype.net>
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 1953B1A0237 for <ietf@ietfa.amsl.com>; Mon, 7 Apr 2014 12:51:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] 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 lhAZZuvMLjiq for <ietf@ietfa.amsl.com>; Mon, 7 Apr 2014 12:51:24 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0142.outbound.protection.outlook.com [207.46.163.142]) by ietfa.amsl.com (Postfix) with ESMTP id D66901A0257 for <ietf@ietf.org>; Mon, 7 Apr 2014 12:51:23 -0700 (PDT)
Received: from BY2PR03CA032.namprd03.prod.outlook.com (10.242.234.153) by BY2PR03MB025.namprd03.prod.outlook.com (10.255.240.39) with Microsoft SMTP Server (TLS) id 15.0.913.9; Mon, 7 Apr 2014 19:51:16 +0000
Received: from BN1AFFO11FD032.protection.gbl (2a01:111:f400:7c10::164) by BY2PR03CA032.outlook.office365.com (2a01:111:e400:2c2c::25) with Microsoft SMTP Server (TLS) id 15.0.908.10 via Frontend Transport; Mon, 7 Apr 2014 19:51:16 +0000
Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD032.mail.protection.outlook.com (10.58.52.186) with Microsoft SMTP Server (TLS) id 15.0.918.6 via Frontend Transport; Mon, 7 Apr 2014 19:51:15 +0000
Received: from TK5EX14MBXC298.redmond.corp.microsoft.com ([169.254.1.124]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.03.0181.007; Mon, 7 Apr 2014 19:50:35 +0000
From: "Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net>
To: Christian Huitema <huitema@microsoft.com>, "ietf@ietf.org" <ietf@ietf.org>
Subject: RE: Security for various IETF services
Thread-Topic: Security for various IETF services
Thread-Index: AQHPT1jXle3ChO4j00Wi4jXF9jNZyZsEwa4AgAB5wwCAAAYrgIABTx3Q
Date: Mon, 07 Apr 2014 19:50:34 +0000
Message-ID: <AE1A6B5FD507DC4FB3C5166F3A05A484504B5176@TK5EX14MBXC298.redmond.corp.microsoft.com>
References: <533D8A90.60309@cs.tcd.ie> <53417832.90405@cs.tcd.ie> <alpine.LRH.2.01.1404061602580.14892@egate.xpasc.com> <ecabb0a4080548d99ab083c0ff0c27ee@BLUPR03MB424.namprd03.prod.outlook.com>
In-Reply-To: <ecabb0a4080548d99ab083c0ff0c27ee@BLUPR03MB424.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.37]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(438001)(199002)(377454003)(189002)(51704005)(50986001)(49866001)(20776003)(98676001)(95666003)(23726002)(54316002)(99396002)(94316002)(84676001)(33656001)(81542001)(79102001)(92726001)(93136001)(97186001)(6806004)(86362001)(90146001)(85306002)(46406003)(63696002)(76796001)(87936001)(47776003)(1511001)(2009001)(97336001)(44976005)(94946001)(97736001)(77096001)(54356001)(87266001)(77982001)(55846006)(83322001)(81686001)(19580395003)(80976001)(65816001)(56816005)(19580405001)(31966008)(74662001)(74502001)(74366001)(74706001)(81816001)(92566001)(47446002)(80022001)(66066001)(50466002)(74876001)(53806001)(81342001)(97756001)(47976001)(47736001)(69226001)(93516002)(4396001)(76786001)(56776001)(46102001)(85852003)(2656002)(76482001)(59766001)(95416001)(83072002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB025; H:mail.microsoft.com; FPR:A03BF4DF.AD34D7D9.7DF03773.84E6A100.20310; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0174BD4BDA
Received-SPF: Pass (: domain of skype.net designates 131.107.125.37 as permitted sender) receiver=; client-ip=131.107.125.37; helo=mail.microsoft.com;
X-OriginatorOrg: skype.net
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/rBZtbF2I7xW3NnmhS33_0hz76rw
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: Mon, 07 Apr 2014 19:51:29 -0000
From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Christian Huitema > Sent: Sunday, April 6, 2014 4:30 PM > To: ietf@ietf.org > Subject: RE: Security for various IETF services > > > I agree with those who've said a threat analysis is needed before > > deciding access is limited to TLS or other secure alternative. > > But we have that threat analysis, and the recommended mitigation is > precisely "encrypt everything." The "pervasive monitoring" threat is analyzed > by a number of perpass drafts, and Stephen has merely followed the > conclusions of that analysis. There is no need to repeat that analysis for each > and every tool that the IETF produces, and there is indeed a need for the > IETF as a whole to "lead by example." I've been following this thread with some amusement, as it was clear that when the perpass draft took its unusual journey from personal draft submission to BCP the fallout would include things like an immediate call for all IETF services to be encrypted. At the same time, there are an equally well known number of attacks against TCP itself that make TCP the wrong substrate upon which to build "secure" communication channels. (Just a couple of well-known examples: the ease of session hijacking of established connection and SYN flood attacks against well-known servers, both of which lead to denial of service and potentially forcing the user to downgrade to an alternative channel for obtaining the information). If the same level of urgency were shown towards a viable, and secure, replacement for TCP itself, then the calls for secure-only access to IETF services might make sense. Instead, it feels a lot like requiring stronger deadbolts on glass doors. Matthew Kaufman
- Security for various IETF services Stephen Farrell
- RE: Security for various IETF services l.wood
- RE: Security for various IETF services Randall Gellens
- Re: Security for various IETF services Fred Baker (fred)
- RE: Security for various IETF services ned+ietf
- Re: Security for various IETF services Dave Crocker
- Re: Security for various IETF services Randall Gellens
- Re: Security for various IETF services Pranesh Prakash
- Re: Security for various IETF services Fred Baker (fred)
- Re: Security for various IETF services Douglas Otis
- RE: Security for various IETF services l.wood
- Re: Security for various IETF services Fred Baker (fred)
- Re: Security for various IETF services Brian E Carpenter
- Re: Security for various IETF services Randy Bush
- Re: Security for various IETF services Scott Brim
- RE: Security for various IETF services l.wood
- Re: Security for various IETF services ned+ietf
- Re: Security for various IETF services Dave Crocker
- Re: Security for various IETF services Randy Bush
- Re: Security for various IETF services Randall Gellens
- Re: Security for various IETF services Martin Rex
- RE: Security for various IETF services l.wood
- Re: Security for various IETF services t.p.
- Re: Security for various IETF services John C Klensin
- Re: Security for various IETF services Ted Lemon
- Re: Security for various IETF services John C Klensin
- Re: Security for various IETF services Dick Franks
- Re: Security for various IETF services Hector Santos
- Re: Security for various IETF services Dick Franks
- Re: Security for various IETF services Hector Santos
- Re: Security for various IETF services Dick Franks
- RE: Security for various IETF services l.wood
- Re: Security for various IETF services Pranesh Prakash
- Re: Security for various IETF services Martin Thomson
- Re: Security for various IETF services John C Klensin
- Re: Security for various IETF services Stewart Bryant (stbryant)
- RE: Security for various IETF services l.wood
- Re: Security for various IETF services Hector Santos
- RE: Security for various IETF services l.wood
- Re: Security for various IETF services ned+ietf
- Re: Security for various IETF services Tim Bray
- Re: Security for various IETF services Stephen Farrell
- Re: Security for various IETF services Dick Franks
- Re: Security for various IETF services Stephen Farrell
- RE: Security for various IETF services l.wood
- Re: Security for various IETF services David Morris
- RE: Security for various IETF services Christian Huitema
- RE: Security for various IETF services l.wood
- Re[2]: Security for various IETF services mohammed serrhini
- RE: Security for various IETF services l.wood
- Re: Security for various IETF services Randy Bush
- RE: Security for various IETF services l.wood
- Re: Security for various IETF services S Moonesamy
- Re: Security for various IETF services Stewart Bryant
- Re: Security for various IETF services Stewart Bryant
- Re: Security for various IETF services Brian Trammell
- Re: Security for various IETF services Stewart Bryant
- Re: Security for various IETF services Stewart Bryant
- Re: Security for various IETF services Stewart Bryant
- Re: Security for various IETF services Stephen Farrell
- Re: Security for various IETF services Ted Lemon
- Re: Security for various IETF services John C Klensin
- Re: Security for various IETF services Spencer Dawkins
- Re: Security for various IETF services Stewart Bryant
- Re: Security for various IETF services Ted Lemon
- RE: Security for various IETF services l.wood
- RE: Security for various IETF services Matthew Kaufman (SKYPE)
- RE: Security for various IETF services Eric Gray
- Re: Security for various IETF services t.p.
- Re: Security for various IETF services Scott Brim
- Re: Security for various IETF services Ted Lemon
- Re: Security for various IETF services Dick Franks
- Re: Security for various IETF services Phillip Hallam-Baker
- RE: Security for various IETF services l.wood
- Re: Security for various IETF services Yoav Nir
- Re: Security for various IETF services Stephen Farrell
- RE: Security for various IETF services l.wood
- RE: Security for various IETF services l.wood
- Re: Security for various IETF services Stephen Farrell
- Re: Security for various IETF services Yoav Nir
- Re: Security for various IETF services Noel Chiappa
- Re: Security for various IETF services Phillip Hallam-Baker
- Re: Security for various IETF services Dave Crocker
- Re: Security for various IETF services Ted Lemon
- Re: Security for various IETF services Theodore Ts'o
- Re: Security for various IETF services Tim Bray
- Re: Security for various IETF services Steve Crocker
- Re: Security for various IETF services Dave Cridland
- Re: Security for various IETF services Randall Gellens
- Re: Security for various IETF services Dave Crocker
- Re: Security for various IETF services Phillip Hallam-Baker
- Re: Security for various IETF services Stephen Farrell
- Re: Security for various IETF services Theodore Ts'o
- Re: Security for various IETF services Phillip Hallam-Baker
- Re: Security for various IETF services Ted Lemon
- Re: Security for various IETF services Phillip Hallam-Baker
- Re: Security for various IETF services Phillip Hallam-Baker
- Web of trust at Internet Scale Sam Hartman
- Re: Security for various IETF services Dave Cridland
- Re: Security for various IETF services Dave Cridland
- Re: Security for various IETF services Mark Andrews
- Re: Security for various IETF services Theodore Ts'o
- Re: Security for various IETF services Jelte Jansen
- Re: Security for various IETF services Stephen Kent