Re: [Emailcore] Ticket #14: G.7.8. Review different size limits

Alessandro Vesely <vesely@tana.it> Tue, 13 July 2021 16:30 UTC

Return-Path: <vesely@tana.it>
X-Original-To: emailcore@ietfa.amsl.com
Delivered-To: emailcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495733A0489 for <emailcore@ietfa.amsl.com>; Tue, 13 Jul 2021 09:30:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 iZAq-50q8pz5 for <emailcore@ietfa.amsl.com>; Tue, 13 Jul 2021 09:30:36 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 173F23A044E for <emailcore@ietf.org>; Tue, 13 Jul 2021 09:30:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1626193833; bh=PlE+oBUkLn9bpNwxr+T407mtOe2PQRYlfd0qBgyi+Zo=; l=1059; h=To:References:From:Date:In-Reply-To; b=BIIpZJ7RR+OxN/qiiLrtS8KYDtyXQbmUiJaPg1EiddFN7OCqhdEz0UZtIy9kuPNKa ei4RnT4SVeYhz+FIfTP1sdNavDx65QzAqMzEAyHOdcejPXUFK89TvOq49eiiNimdYd JgzYD7b/fa32+JlGVtj6iUiksMWXHGhIBwp8Ok85JK6L5FW/6SbazWcbny9vU
Authentication-Results: tana.it; auth=pass (details omitted)
Original-From: Alessandro Vesely <vesely@tana.it>
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC056.0000000060EDBFA9.0000570F; Tue, 13 Jul 2021 18:30:33 +0200
To: emailcore@ietf.org
References: <CAHej_8miev_XV3egTgiDEm7ARyyPoKzMAH-2z=9FrDoP=JRZgQ@mail.gmail.com> <01S1CDHKSDL6005PTU@mauve.mrochek.com> <70e3923f-c3c9-8625-4009-0a4ca0fb5ab0@dcrocker.net>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <5e1490c1-a26f-3e39-b5b2-41d3f1c0c6a7@tana.it>
Date: Tue, 13 Jul 2021 18:30:33 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <70e3923f-c3c9-8625-4009-0a4ca0fb5ab0@dcrocker.net>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/emailcore/Q7ZKvb8wP2pTXFJzz3cUoqGORtk>
Subject: Re: [Emailcore] Ticket #14: G.7.8. Review different size limits
X-BeenThere: emailcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: EMAILCORE proposed working group list <emailcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emailcore>, <mailto:emailcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emailcore/>
List-Post: <mailto:emailcore@ietf.org>
List-Help: <mailto:emailcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emailcore>, <mailto:emailcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Jul 2021 16:30:43 -0000

On Tue 13/Jul/2021 17:32:50 +0200 Dave Crocker wrote:
> On 7/13/2021 5:52 AM, Ned Freed wrote:
>> I also note that X.400 has changed from "the mail system we'll all be using
>> someday" to "only used in limited government/military cases, and even those are
>> disappearing". Is it really worth mentioning at this point?


Where do those quotes come from?  Do you have a reference?  When did the change 
occur?


> It is not.


+1,


>> Finally, and most importantly, implementation techniques that impose no limits
>> on object size represent a serious security risk. I think this alone justifies
>> removing "should support" bit.


You mean "should be used"?  ("should support" doesn't appear in that paragraph).

I'm not clear what is the security risk.  Clearly, no implementation can be 
truly limitless, since the Universe itself appears to be limited.  Perhaps:

                                                            To the
    maximum extent possible, implementation techniques that impose no
    *predefined* limits on the length of these objects should be used.

?


Best
Ale
--