Re: Security for various IETF services

Hector Santos <hsantos@isdg.net> Fri, 04 April 2014 19:49 UTC

Return-Path: <hsantos@isdg.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 426641A0667 for <ietf@ietfa.amsl.com>; Fri, 4 Apr 2014 12:49:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.138
X-Spam-Level:
X-Spam-Status: No, score=-101.138 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 5nGu2_FsF4Tg for <ietf@ietfa.amsl.com>; Fri, 4 Apr 2014 12:49:44 -0700 (PDT)
Received: from listserv.winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 277D61A0584 for <ietf@ietf.org>; Fri, 4 Apr 2014 12:48:12 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4822; t=1396640887; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=XXW1wBdQh7zHx9W5ShIN1xUd3hs=; b=h4/EW62pR9XvXMycOnwj HxcSIDISaRpi6zckVv52OXtCfUoeprveV5FScjs6/5M5YQh071VrQPiIZe3NYDSX yEEAhgCmplOJCOEJDT2/lpnPTK2aGNx5XakLcQrKlrZZ5vPFs/oZ1Ix8qZOHkxnY aIlmR4pV44mKp1/+vNN+COM=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf@ietf.org; Fri, 04 Apr 2014 14:48:07 -0500
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com;
Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1628343624.3926.5880; Fri, 04 Apr 2014 14:48:07 -0500
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4822; t=1396640840; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=rtj4W8r FRFrt4vZjnwoe/ZASdGbtTxo6XNQPP3ssNp0=; b=F7/J8UWuV3OTio+mJvk4MoS G9iEgCan/mU+FYEydpUgmVhhSxejdYuPERxce6IDrERI7Oa2HSLjRqShkkqeiJPO 9tjCd0JrDGBc5IJnFuO9PvwehfxURW8Fjs4hzmAyNxuDiyV69hyG0N2sDS+R0RJ5 PkJnHpQyDI7JwuiEH/Ug=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf@ietf.org; Fri, 04 Apr 2014 15:47:20 -0400
Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1074596350.9.18756; Fri, 04 Apr 2014 15:47:19 -0400
Message-ID: <533F0C7B.9090705@isdg.net>
Date: Fri, 04 Apr 2014 15:48:11 -0400
From: Hector Santos <hsantos@isdg.net>
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Dick Franks <rwfranks@acm.org>
Subject: Re: Security for various IETF services
References: <533D8A90.60309@cs.tcd.ie> <533EEF35.7070901@isdg.net> <CAKW6Ri5_Ty6rVsMTBKXEjC6r7Mg-o8pZoLQP+yJ4pBwqOF-nYw@mail.gmail.com>
In-Reply-To: <CAKW6Ri5_Ty6rVsMTBKXEjC6r7Mg-o8pZoLQP+yJ4pBwqOF-nYw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/KBYxl7UO3HCPTXcuvro3aP3M1R8
Cc: IETF-Discussion <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 19:49:48 -0000

Hi Dick,

Everyone else has already touch based with the same issues. I'm 
pointing out there are legal, business related regulations to be 
followed making it well understood, it (modern security methods) may 
be mandatory in certain "new service" areas.   If not, then never 
mind. If so, Stephen asked about the last sentence:

   New services will however generally only be made
   available in ways that use security protocols such as
   TLS.

If it is not already implied, I thought it may help with some specific 
admonition as to why it will only be made available in a secured way. 
It says TLS.  Anything else?  A draft suggestion only, additional 
sentence:

   There are areas at the IETF site that may require updated, modern
   security-aware connection client access software to be used
   as required for industry compliance standards, e.g.; PCI/DSS.

Nothing to do with PR, but it doesn't hurt either.

Thanks

-- 
HLS

On 4/4/2014 2:53 PM, Dick Franks wrote:
> Tinkering with the text of a 90 word statement full of PR claptrap is
> not going to achieve anything.
>
> The starting point for any sensible discussion on this topic is a
> threat model, for each service,  against which the effectiveness of
> proposed mitigation strategies can be assessed.
>
> Until that is forthcoming, reasoned discussion taken place, and
> (rough) consensus reached, this proposal MUST go nowhere.
>
>
> Dick
> ________________________
>
>
>
> On 4 April 2014 18:43, Hector Santos <hsantos@isdg.net
> <mailto:hsantos@isdg.net>> wrote:
>
>     I would add and be specific with the last sentence, for example,
>     the IETF site
>     "new services" might need to be PCI/DSS compliant. This is
>     especially the case if the IETF site is collecting credit card
>     information for IETF meeting registrations or other purposes.  For
>     logging in purposes, it may also need to be PCI/DSS compliant
>     depending on the AUTH method. For DIGEST AUTH, it may require SSL
>     and NONCE support. BASIC AUTH requires SSL, and it may not be
>     sufficient for PCI/DSS unless there is other methods wrapping the
>     BASIC AUTH process, i.e. a cookie method method. A form-based
>     cookie login methods, where there is no standard protocol method,
>     may require other conditions. Overall, there are areas at the IETF
>     site that require updated, modern security-aware connection client
>     access software to be used as required by industry standards such
>     as PCI/DSS.  (I note, that this is probably USA, not sure how that
>     applies in Europe, Asia, etc)
>
>     If fact, the IETF may not be running proper software that complies
>     with PCI/DSS.
>
>     Maybe visiting one of the PCI/DSS resource/compliance sites can
>     tell you what compliancy level the IETF site may fit.  Depending
>     on what software is used, it may suffice or it may not, thus
>     perhaps even adding new functional requirements to the IETF Web
>     Site revamping project.
>
>     Hope this helps
>
>     --
>     HLS
>
>
>     On 4/3/2014 12:21 PM, Stephen Farrell wrote:
>
>
>         Hi all,
>
>             >From time to time the issue of how to secure IETF services
>
>         comes up e.g. whether to turn on TLS for some IETF web server
>         or jabber or mail etc.
>
>         The most recent such was a request to turn on HSTS [1] for
>         the IETF web site, which I don't think we can do without
>         breaking old tools etc. Nonetheless we would like to turn
>         on things like TLS more often going forward as seemed to
>         me to be the outcome of a long thread on here late last
>         year.
>
>         So, the IESG are considering the following as an IESG
>         statement to offer some guidance about this:
>
>         "The IETF are committed to providing secure and privacy
>         friendly access to information via the web, mail, jabber
>         and other services. While most (but not all) data on IETF
>         services is public, nonetheless access to that data
>         should use best practices for security and privacy.
>         However, as there are numerous legacy 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."
>
>         If you have wordsmithing changes to suggest please just send
>         those to me or the iesg. More substantive comments should go
>         here I guess. I hope the only bit worth discussing (except
>         for the few folks who would rather we do none of this;-)
>         might be the last sentence.
>
>         A few weeks after any discussion here dies down I'll put the
>         resulting text on an IESG telechat for approval if that seems
>         like the right thing to do.
>
>         Thanks,
>         S
>
>         [1] https://tools.ietf.org/html/__rfc6797
>         <https://tools.ietf.org/html/rfc6797>
>
>
>
>
>
>     --
>     HLS
>
>
>