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