Re: [ietf-smtp] why are we reinventing mta-sts ?

Tony Finch <dot@dotat.at> Tue, 08 October 2019 13:59 UTC

Return-Path: <dot@dotat.at>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875921200A3 for <ietf-smtp@ietfa.amsl.com>; Tue, 8 Oct 2019 06:59:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 eaZTU-fXgaRU for <ietf-smtp@ietfa.amsl.com>; Tue, 8 Oct 2019 06:59:47 -0700 (PDT)
Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [131.111.8.133]) (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 8D22A12007C for <ietf-smtp@ietf.org>; Tue, 8 Oct 2019 06:59:47 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:60246) by ppsw-33.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1iHq1g-000aLQ-hg (Exim 4.92.3) (return-path <dot@dotat.at>); Tue, 08 Oct 2019 14:59:44 +0100
Date: Tue, 08 Oct 2019 14:59:44 +0100
From: Tony Finch <dot@dotat.at>
To: Keith Moore <moore@network-heretics.com>
cc: ietf-smtp@ietf.org
In-Reply-To: <07145df5-1b27-ba93-4a9f-9d878032cbd5@network-heretics.com>
Message-ID: <alpine.DEB.2.20.1910081444050.8949@grey.csi.cam.ac.uk>
References: <20191007162824.64ED8BB6CA1@ary.qy> <53D231EA-D749-4437-9759-6F1B3ECC6142@network-heretics.com> <alpine.OSX.2.21.99999.368.1910071506250.38715@ary.qy> <CAOEezJQt-6GNJ08MsZ5PUOBD6mf9CBXc8duu7xVLDxirzeqauQ@mail.gmail.com> <5b90d08f-8277-6c50-d069-4709880f932f@network-heretics.com> <alpine.DEB.2.20.1910081229230.8949@grey.csi.cam.ac.uk> <07145df5-1b27-ba93-4a9f-9d878032cbd5@network-heretics.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="1870870841-355943452-1570542462=:8949"
Content-ID: <alpine.DEB.2.20.1910081447450.8949@grey.csi.cam.ac.uk>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/LTg9vEggglEKSD7jgd9W0YXzw80>
Subject: Re: [ietf-smtp] why are we reinventing mta-sts ?
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Oct 2019 13:59:49 -0000

Keith Moore <moore@network-heretics.com> wrote:
> On 10/8/19 7:34 AM, Tony Finch wrote:
> >
> > The DNS protocol has to have special logic for every RRtype that appears
> > at a delegation, so you would need some kind of signalling to indicate
> > that this is OK for all the parties involved. (I have not thought about
> > the details of what would be required...)
>
> I'm curious about this.   I thought all of the logic required was on the
> server end.

The DOTNS spec has decide if the records are like NS (appear both below
and above the cut) or like DS (above the cut only) so that resolvers are
able to know where to ask for them. For this to make sense from a DNSSEC
point of view the above-the-cut DOTNS records should probably be signed by
the parent zone (like DS) rather than being an unsigned non-authoritative
hint (like NS), so validators have to handle the zone cut correctly when
checking the RRSIG(DOTNS) signer name. There are probably other things
that need careful thought.

> > You also need to upgrade EPP so that registrars can get the extra records
> > into the registry database so that the registry can put them in the TLD.
>
> Ah, that makes sense.
>
> But I've been convinced for at least 20 years that the DNS protocol needed an
> upgrade path anyway, and that having new kinds of "NS" records was the only
> good way to do it.   So to me the effort required to add support for new
> delegation records seems like a necessary investment.

You are right. Sadly the experience of adding DS records has not been at
all successful: there hasn't been enough carrot/stick to implement the
upgrade on a sensible timescale. There would need to be quite a big change
of attitude for it to be worth trying something similar again.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Shetland Isles: South or southwest 4 to 6. Rough or very rough, but moderate
in shelter. Rain or showers. Good, occasionally poor.