Re: Security for various IETF services

Hi Dick,

Everyone else has already touch based with the same issues. I'mpointing out there are legal, business related regulations to befollowed making it well understood, it (modern security methods) maybe mandatory in certain "new service" areas. If not, then nevermind. 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 specificadmonition as to why it will only be made available in a secured way.It says TLS. Anything else? A draft suggestion only, additionalsentence:


  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(_at_)isdg(_dot_)net
<mailto: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
        <https://tools.ietf.org/html/rfc6797>





    --
    HLS