Re: Security for various IETF services
Stewart Bryant <stbryant@cisco.com> Mon, 07 April 2014 10:14 UTC
Return-Path: <stbryant@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 169A91A0392 for <ietf@ietfa.amsl.com>; Mon, 7 Apr 2014 03:14:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.511
X-Spam-Level:
X-Spam-Status: No, score=-9.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] 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 WQ_peY-Mglle for <ietf@ietfa.amsl.com>; Mon, 7 Apr 2014 03:14:39 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id AFDFA1A0680 for <ietf@ietf.org>; Mon, 7 Apr 2014 03:14:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4133; q=dns/txt; s=iport; t=1396865673; x=1398075273; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=vQiQFWnpZ5l3RZGlp2OwTnVLIKmKGgzL3htI7fPsmnA=; b=iolXLs+uhDeNb+HZE9ixvpV3ZJba0+Lgh0q1ZykO7xYBB+t2+inUwXHp Zv6Xk3P5pgRTHNlbOVcEpobdLohxY34sZtdb9iunLFXcDM1txNJ0fLddJ hoUNbUsehBacCOK3GFZahyGepHbHHjzwfqDoD+NzR521s+JeQ9xs8xyeO s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhkFAAd6QlOtJssH/2dsb2JhbABZgwY7wWODDoEiFnSCJQEBAQQ4QBELGAkNAQgPCQMCAQIBRQYBDAgBARYEh1uuapw8F4lGhFoBAQFVEgGEJQSYW5I/gzGBagcX
X-IronPort-AV: E=Sophos;i="4.97,809,1389744000"; d="scan'208";a="13837051"
Received: from aer-core-2.cisco.com ([173.38.203.7]) by aer-iport-2.cisco.com with ESMTP; 07 Apr 2014 10:14:32 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s37AEKpu004410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Apr 2014 10:14:20 GMT
Received: from STBRYANT-M-R010.CISCO.COM (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s37AEJev000324; Mon, 7 Apr 2014 11:14:19 +0100 (BST)
Message-ID: <53427A7B.8020109@cisco.com>
Date: Mon, 07 Apr 2014 11:14:19 +0100
From: Stewart Bryant <stbryant@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, IETF-Discussion <ietf@ietf.org>
Subject: Re: Security for various IETF services
References: <533D8A90.60309@cs.tcd.ie> <53417832.90405@cs.tcd.ie>
In-Reply-To: <53417832.90405@cs.tcd.ie>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/C8lhz_kMFMI1em9Si3hD_2zl7Ho
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: stbryant@cisco.com
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 10:14:45 -0000
On 06/04/2014 16:52, Stephen Farrell wrote: > As others have said, I think the questions posed have been > answered pretty much. > I also got some good offlist wording > suggestions, the result of which is: > > "The IETF is committed to providing secure and private > access to information via the web, mail, jabber and > other services. While most data on IETF services is > public, individual accesses to that data should be > kept private to the extent possible. That is an assumption that is the thin end of a wedge. A threat analysis is needed on a case by case basis. > However, as > there are numerous existing tools that have been built > that require access via cleartext, the IETF will > continue to allow such access so as not to break such > tooling. New services will however generally only be > made available in ways that use security protocols > such as TLS." It would be better to say: "The specification of new service will each be required to include a threat analysis. In each case a decision will be made about which, if any, security protocols are needed to match the needs of the application in the light of the threats." > > And just adding some stuff that's not been said before... > > I agree that IETF services aren't the most sensitive in the > world, but think we all nonetheless win if we up the ante for > attackers of whatever kind when we reasonably can. ... and we loose if we needlessly burn power, silicon, time, bandwidth.... What I hope we are doing is best in class engineering, and not simply reacting to the news of the past few months. > > There is a value in not making cleartext versions of services > available though - I've personally seen a number of cases where > http:// URLs were sent via mail with instructions to login at > that URL using e.g. a datatracker or tools login. Yes, that ought > not happen (https:// URLs should be sent), but it does happen > and will so long as the http:// URLs work, and it'd be naive of > us to assume that everyone sending out such mails would be aware > that doing so isn't a good plan. This is a very sweeping statement, which is surely application specific? > > Using e.g. TLS for confidentiality also helps counter attacks > where cleartext HTTP cookies etc. are being used for monitoring > which has been shown to be the case. [1] IMO that's already a > good enough reason to turn on TLS or equivalent as much as > possible since most services will expose some similar > fingerprint when run in clear. > > For those who expressed a wish for data origin authentication > over and above TLS server auth, that is already in place for > I-Ds. [2] > > A couple of people expressed concern that this was a bit of a > "blanket statement," while that is true, the statement is not > absolutist, e.g. it says "generally" in the last sentence > which I think is about right. A question here concerns the degree to which the en clare applications need to justify their case against an assumption of encryption. Each application surely needs to be considered on it's own merits. The text that you have is presumptive of the outcome, which is surely not best engineering practice. > > A number of people made mechanism-specific points which were > mostly reasonable but of course we shouldn't put those in > this proposed iesg statement. One person said that e.g. this > statement should not be used to require client authentication > which is of course correct. > > Someone mentioned having an IETF privacy policy for services > which sounds like a fine thing to me, and which is something > that I think Alissa has done a bit of work on in the past and > the IESG has chatted about resurrecting that. That is trickier > to get right though, and more work to get agreed, so not sure > if it'll happen. > > Lastly, I'm heartbroken that Lloyd has sussed out my formerly > secret plan to try to take over the world;-) Ah well, I'll > just have to try again tomorrow. > I am not sure that last para is called for. - Stewart
- 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