Re: Security for various IETF services

David Morris <dwm@xpasc.com> Sun, 06 April 2014 23:08 UTC

Return-Path: <dwm@xpasc.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 7DBC81A0515 for <ietf@ietfa.amsl.com>; Sun, 6 Apr 2014 16:08:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.546
X-Spam-Level:
X-Spam-Status: No, score=-0.546 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, MISSING_HEADERS=1.021, SPF_PASS=-0.001] autolearn=no
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 em0DZ6xr3F-v for <ietf@ietfa.amsl.com>; Sun, 6 Apr 2014 16:08:12 -0700 (PDT)
Received: from c2w3p-2.abacamail.com (c2w3p-2.abacamail.com [67.231.154.153]) by ietfa.amsl.com (Postfix) with ESMTP id 46FC71A0503 for <ietf@ietf.org>; Sun, 6 Apr 2014 16:08:12 -0700 (PDT)
Received: from xpasc.com (h-68-164-244-186.snva.ca.megapath.net [68.164.244.186]) by c2w3p-2.abacamail.com (Postfix) with ESMTP id 391253F9DE for <ietf@ietf.org>; Sun, 6 Apr 2014 23:07:17 +0000 (UTC)
Received: from egate.xpasc.com (egate.xpasc.com [10.1.2.49]) by xpasc.com (8.13.8/8.13.8) with ESMTP id s36N868M024562 for <ietf@ietf.org>; Sun, 6 Apr 2014 16:08:06 -0700
Date: Sun, 6 Apr 2014 16:08:06 -0700 (PDT)
From: David Morris <dwm@xpasc.com>
cc: IETF-Discussion <ietf@ietf.org>
Subject: Re: Security for various IETF services
In-Reply-To: <53417832.90405@cs.tcd.ie>
Message-ID: <alpine.LRH.2.01.1404061602580.14892@egate.xpasc.com>
References: <533D8A90.60309@cs.tcd.ie> <53417832.90405@cs.tcd.ie>
User-Agent: Alpine 2.01 (LRH 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/jC-0U5ynKGLfpkJDR47gPNysNMU
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: ietf@ietf.org
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: Sun, 06 Apr 2014 23:08:17 -0000

On Sun, 6 Apr 2014, Stephen Farrell wrote:

> ...
> 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.

Um, it is not difficult to protect the login credentials will leaving
the remainder of the interaction in the clear. Then it won't matter
what is the the email.

I don't object to making TLS/et al access available when it can be
done at a moderate cost. But that is different than the implied
statement that the intent is to require TLS for future service
access.

I agree with those who've said a threat analysis is needed before
deciding access is limited to TLS or other secure alternative.