Re: Telnet and FTP to Historic

Phillip Hallam-Baker <phill@hallambaker.com> Thu, 03 December 2020 20:45 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF323A0C59 for <ietf@ietfa.amsl.com>; Thu, 3 Dec 2020 12:45:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 lOf9xiMR_omF for <ietf@ietfa.amsl.com>; Thu, 3 Dec 2020 12:45:53 -0800 (PST)
Received: from mail-yb1-f176.google.com (mail-yb1-f176.google.com [209.85.219.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E9A93A0C55 for <ietf@ietf.org>; Thu, 3 Dec 2020 12:45:53 -0800 (PST)
Received: by mail-yb1-f176.google.com with SMTP id l14so3318740ybq.3 for <ietf@ietf.org>; Thu, 03 Dec 2020 12:45:53 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8qrsRuwzIR/MMQ6/o91j9Rdv+QL3DtgDHvYzHJPF0xU=; b=t80Oz/C8oiSBo3lOtZq3KiSJB3gNVQaz+5JI//zhXPTaze8FgPFIvQ3fdutAwbi1HZ HtbEjlT52QlQXXF7ySKwHRkP+d2DhjNJ1Ci9ZcDFRXp6sdyxoCU8h2zoCt0edVv9hfyF 3RJpawxmzzW1LXML45cNSjV2H/fumHJESSi5XmF6zdm6RttTK8RxSFp8x6qWsxCg130p jEmMHw2E7KmYav8N/ZqJqItHvIEH+eL+PB2Bh9F854jWh2zeGi5R0g44X0RHVVMj1Bpi qW5q0gUt6grAd1Fb2SByQnSqLlpA2jeWidGEzV4zcesTvTiX7ZgpACRHD2nLIHG0nh8J 6kgQ==
X-Gm-Message-State: AOAM531iO0nUv7xp7ELArCPcdJH2v9Z1kEZIbdGVahpJ5hIpYEmPxI7q zMZcicdiVr1dhxoNXC/UF46xjlNFYQ6hjn+onBo/Kwx7d3Q=
X-Google-Smtp-Source: ABdhPJx14+h0pNed36Ko2Pz7dzapVORabKIwnQjNoVlA1fzuULX1tm4OIjL9ZiIm3K99zRtoQB0EtCbJaStJfeJ6mIc=
X-Received: by 2002:a25:830e:: with SMTP id s14mr1371000ybk.213.1607028352676; Thu, 03 Dec 2020 12:45:52 -0800 (PST)
MIME-Version: 1.0
References: <51d208a3-4cae-b69a-6ecc-d15f48c66b44@huitema.net> <06E7EB62-D6C2-4827-A241-8E276860C2B7@strayalpha.com> <6842e463-6fce-42e5-402c-acacabd9905b@huitema.net> <8cb5f679-ebc5-3107-1708-c4912b9222d4@network-heretics.com>
In-Reply-To: <8cb5f679-ebc5-3107-1708-c4912b9222d4@network-heretics.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Thu, 03 Dec 2020 15:45:41 -0500
Message-ID: <CAMm+LwhiDK-mxjzezGvAu5pRw0S1=7+vEi8NKYdBWAtmyW+dxA@mail.gmail.com>
Subject: Re: Telnet and FTP to Historic
To: Keith Moore <moore@network-heretics.com>
Cc: IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001af8b105b595722e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/v1XvIiYt8n9yWQk1atU3J103i3M>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 03 Dec 2020 20:45:55 -0000

On Thu, Dec 3, 2020 at 3:06 PM Keith Moore <moore@network-heretics.com>
wrote:

> On 12/3/20 1:54 PM, Christian Huitema wrote:
>
> >
> > I understand why you say that. Machines behind a NAT or a stateful
> > firewall cannot be remotely probed for low level vulnerabilities, so
> > you do get some reduction of the attack surface. My contention is that
> > this reduction is far from being sufficient, because attackers have
> > found many ways to project themselves through NATs or firewalls. If
> > you allow for unsafe practices because the machines are behind a NAT
> > or a firewall, these unsafe practices will result in catastrophic
> > cascades of failures after a single breach happens.
>
> +1
>
> For that matter not even "air gapped" networks are really safe. There's
> almost always some laptop or other that occasionally connects to such
> networks, and malware can creep in that way.
>

There are viable controls but they are very expensive. At VeriSign we
constructed a tier 6 SOC and kept the machines that perform offline
operations in a very pricey safe along with the HSMs (see the CPS which
documents all of that).

Firewalls are an effective means of mitigating risk. They do not eliminate
risk. They don't come close.

Perimeter security is useful but incomplete. A starting point for any
security analysis has to be 'what stuff do I have control over and what
stuff do I have no control over'. But perimeter security has been declining
in effectiveness for decades now. It is the 1980s level car alarm that
every thief has learned how to disable.


To go further, we have to start looking a security policy and we have to
look at separation of roles. And right now the research community focused
on that approach is tiny. We are starting to get some traction with
threshold cryptography which is the only technology that provides a real
hope of protecting data at rest whether in the cloud or elsewhere.

Suggest doing security policy and people start bleating that it is hard.
Well if it was easy we would be doing it already.