Re: Security for various IETF services

Dick Franks <> Fri, 04 April 2014 18:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BB2611A0522 for <>; Fri, 4 Apr 2014 11:54:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jK0pybLkcqB5 for <>; Fri, 4 Apr 2014 11:54:44 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c01::234]) by (Postfix) with ESMTP id A43A61A0515 for <>; Fri, 4 Apr 2014 11:54:44 -0700 (PDT)
Received: by with SMTP id c41so3513464yho.39 for <>; Fri, 04 Apr 2014 11:54:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=l1iBITbkCF6Defpsnwv5mwFUHMQ1Ekcm6E1DV2tM0TE=; b=sAWZDFJlSLZqodh/gv5P8e3Am6x7VpyDVrvvxmWvQuF2meTpseK086BweIjJoY3d6D A8VqVtYfjTioF138KF0xO2d7c2BmPFopgCURJAC8kSt1GKb8LOb/8KLhTboQfrWV0dSI MZmuKCv2PgwkFFE1m8CSvpV2Hj5GB8EHkW2YXZzMgVpIBSarve5bNJq/tG7sPyy6x+1s 7Pwnl7tgbrl8oWfFR+eypfQLb8K1+HeUuJ6fq36K+9+KjrOkHYyzofPvFHwS5WcVJTKp s2j8FUOqnxFP47ZVo6ndmHn7hKvKjtlm8D+9xQN/3hpmmcPTEQaO2UK7zqQcuY6izK07 +H3w==
X-Received: by with SMTP id f27mr12231354yhl.116.1396637679919; Fri, 04 Apr 2014 11:54:39 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 4 Apr 2014 11:53:59 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Dick Franks <>
Date: Fri, 4 Apr 2014 19:53:59 +0100
X-Google-Sender-Auth: kTRVxFcGLGHrQ38C2HfPOltHcT0
Message-ID: <>
Subject: Re: Security for various IETF services
To: Hector Santos <>
Content-Type: multipart/alternative; boundary=20cf3040e3f4caa98104f63c0c9c
Cc: IETF-Discussion <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Apr 2014 18:54:49 -0000

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.


On 4 April 2014 18:43, Hector Santos <> 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
> 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
> --
> 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]
> --