ietf
[Top] [All Lists]

Re: Security for various IETF services

2014-04-04 13:55:07
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(_at_)isdg(_dot_)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





--
HLS