[Tools-discuss] Re: [EXTERNAL] Re: Re: Fwd: Brief outage for the RPC infrastructure tomorrow (15May)

Eric Rescorla <ekr@rtfm.com> Thu, 16 May 2024 21:58 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 62A68C14F6FB for <tools-discuss@ietfa.amsl.com>; Thu, 16 May 2024 14:58:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20230601.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id RCOyYLrn-IVg for <tools-discuss@ietfa.amsl.com>; Thu, 16 May 2024 14:58:00 -0700 (PDT)
Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA86CC14F6F5 for <tools-discuss@ietf.org>; Thu, 16 May 2024 14:58:00 -0700 (PDT)
Received: by mail-yb1-xb2b.google.com with SMTP id 3f1490d57ef6-dc6cbe1ac75so6667459276.1 for <tools-discuss@ietf.org>; Thu, 16 May 2024 14:58:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20230601.gappssmtp.com; s=20230601; t=1715896679; x=1716501479; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=3GxlFHfo16GVj3rZaxhSpzKQxLHYk15kcsNSBr3Blm8=; b=Y7N4YwEVpErPEyqI/gSxLlDZzh18CFuWtU9xNK4zc/+Q+zBhPOiiqvAQwXtd89m+k7 Uj3tHcjZi9ZqiMEAvIp+soV/Tmizp0jks88JiTZwt+v8pgOs/WsGOej+R2/U9UW8UWNQ EUKN6DLGj96lUaVRId69cSp3ajJm2Haghq+X2oAIU41zS/caLwuSK+yls3h8NFxr81DH pzVZSSqpzeRzypB23JCTh50ryaEPqe33HFMt+2YZFNF236UnOPs/+FPnE6eKChFkj215 yB9R8yDnbYX+WCtnSQm3iuYlSTTHPLfG3E1+OsTWX2CGwo3YiaQ/RrtfE19YIfzITLyq JY6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715896679; x=1716501479; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3GxlFHfo16GVj3rZaxhSpzKQxLHYk15kcsNSBr3Blm8=; b=Nd9K6mdZo2bh/FY8S5+uYMg1M4nDWEFFGpKOxyVI3BlO3IY+cNUypzlgdfwf8KlEuH Ut3Yarz9KnSy/rWynlnnc6G/PuMuyJYSE6Vs2tcE5evzVbIVsV0ngcxwGzDAHQMvkhx4 faFR77/WO+rUbIv5sy7ulupp8+lm71VbnCSymfSclaq2EYK1BdxXsTzC3dzXHp+JLZev EPQludBCnyHelgJkFsS0rM9EUpFuhYDWPfwW+lOvCQsSyybxaqmxALfq4dd7Qk1057Ky ps9Z4jWSPJKdqvP2/nzwrjIoOEafpO3JXzoWdCTRCO9mTYDOSg3KsZ617xRvaTMDHUpV nNqw==
X-Forwarded-Encrypted: i=1; AJvYcCVI4Z5OEOpwfClftuBPr+SBIRJ6dfRT2uYennDTV2LZTP0nWmrO+a43Ko3W5EzBJKx6heYViQvTy11h8KtCBy8AGIHz3fpc
X-Gm-Message-State: AOJu0YyrUu/USD2yRvxFd+jhNyEF7dpleT7/+VM01uW3UtmyVHZgwf09 mIw5e4+PdY+CB0MiZebgQ12e+Cnq2bQLsxhrnli6bQMsKYjsQHDjbvNTaSTU1zlwdKuz3SFzdlz amSlkEyHvVU5XdDEQhc4dpBITwflpf5JMMFc2UQ==
X-Google-Smtp-Source: AGHT+IFS4RvWRdhvztGqPxFXNJLM1qU1xK0xzK+ezXu5i5fZGN1VsiGYAUlpIcFXiHXvSnMfFA0eQ4yCMtIf8ossFM0=
X-Received: by 2002:a5b:88c:0:b0:ddd:7a62:59b0 with SMTP id 3f1490d57ef6-debcfba048amr18289847276.15.1715896679637; Thu, 16 May 2024 14:57:59 -0700 (PDT)
MIME-Version: 1.0
References: <8dac60d8-6845-47aa-83c5-c113c30b6000@nostrum.com> <7f20db7c-fbd6-4b94-a7fd-07805b0d69e0@nostrum.com> <CF619D24477ABD0762BAC91D@PSB> <debba2c7-7fd5-467c-9734-0c0dca34ed42@nostrum.com> <A3865504-5F56-41DB-84A4-677A79101A50@comcast.com> <cd5573ae-4aff-46f3-b51f-5b466b372393@nostrum.com> <0ACDF645-F5FD-46D7-8BC9-CC4299662351@comcast.com> <1191a1d4-7011-490d-b02e-1f7c6cb21136@amsl.com> <169a5c1f-fff4-43bc-8474-3922b98c5dff@gmail.com> <CABcZeBOiTk0hw=UoSUGnhaHh7=_NwvfdyboNyw_1s1bpy6oo1w@mail.gmail.com> <1FAA25DF371CCB1EC1A01EBD@PSB>
In-Reply-To: <1FAA25DF371CCB1EC1A01EBD@PSB>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 16 May 2024 14:57:23 -0700
Message-ID: <CABcZeBPeL7+jyAJc61X9kV65-9PpCuteCGbkgS8O+vSux6t6ww@mail.gmail.com>
To: John C Klensin <john-ietf@jck.com>
Content-Type: multipart/alternative; boundary="0000000000000fe6af06189954cf"
X-MailFrom: ekr@rtfm.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tools-discuss.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Robert Sparks <rjsparks@nostrum.com>, tools-discuss <tools-discuss@ietf.org>, Jay Daley <jay@staff.ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Tools-discuss] Re: [EXTERNAL] Re: Re: Fwd: Brief outage for the RPC infrastructure tomorrow (15May)
List-Id: IETF Tools Discussion <tools-discuss.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tools-discuss/otCsMG1SWwCwu8B1v_BlTFmlgZw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-discuss>
List-Help: <mailto:tools-discuss-request@ietf.org?subject=help>
List-Owner: <mailto:tools-discuss-owner@ietf.org>
List-Post: <mailto:tools-discuss@ietf.org>
List-Subscribe: <mailto:tools-discuss-join@ietf.org>
List-Unsubscribe: <mailto:tools-discuss-leave@ietf.org>

On Thu, May 16, 2024 at 2:41 PM John C Klensin <john-ietf@jck.com> wrote:

> --On Thursday, May 16, 2024 14:00 -0700 Eric Rescorla <ekr@rtfm.com>
> wrote:
> > On Thu, May 16, 2024 at 1:34 PM Brian E Carpenter <
> > brian.e.carpenter@gmail.com> wrote:
> >
> >> On 17-May-24 05:53, Jean Mahoney wrote:
> >> > Hi all,
> >> >
> >> > On 5/16/24 12:24 PM, Livingood, Jason wrote:
> >> >>>> I thought the IETF stopped supporting FTP interfaces to IETF
> >> >>>> content
> >> a few years ago?
> >> >>> The IETF did, yes - see RFC 9141.
> >> >>> The RFC Editor has not made a similar change.
> >> >>
> >> >> No time like the present to align the RFCE site then! ;-)
> >> >
> >> > [JM] The RPC is not currently planning to turn off FTP. We would
> >> > seek more community feedback before making such a decision.
> >>
> >> Turning it off if people use it would be performative, and nothing
> >> to do with security.
> >>
> >
> > I don't particularly care whether the RPC chooses to publish
> > documents via FTP [0], but this statement is not correct.
> >
> > Retrieving the documents over HTTPS provides both:
> >
> > 1. Confidentiality of which document is retrieved.
> > 2. Integrity of the document contents (to the level that this is
> > what the server currently believes).
> >
> > FTP provides neither of these.
> For the first, presumably, those using FTP either understand the
> issue and are not concerned about keeping that information
> confidential or are willing to trade the privacy for convenience.

"Presumably" is doing a lot of work here. It's not at all clear to me
that this is the case.

>   If
> "we" believe that "they" should not feel that way, the solution is an
> educational project, not shutting down FTP.

As I said, I don't much care about whether the RPC provides an FTP
service. I'm simply observing that Brian's assertion about there being
no security benefit is incorrect.

If we are concerned about the second, it would probably be
> appropriate to start publishing (and publicizing) verifiable document
> signatures that are established by the RPC.  Such a mechanism would
> avoid questions about how much one should trust one's friendly cloud
> provider and would presumably provide an integrity test on documents
> no matter how or from where they are retrieved.

This seems like a classic case of the best being the enemy of the good.

Simply serving the RFCs over HTTPS prevents attack by the local network
which provides significant additional security benefit. It's true that
signatures would be better, but actually deploying those in a meaningful
way would be a big lift, especially as it requires a much bigger change to
user behavior than just changing the URL they use. I certainly welcome
someone working on that project, but that's not a good reason not to
people to use secure transport.