IETF Logo Mail Archive

Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal.

Daniel Margolis <dmargolis@google.com> Thu, 10 August 2017 18:28 UTC

Return-Path: <dmargolis@google.com>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C0D132405 for <uta@ietfa.amsl.com>; Thu, 10 Aug 2017 11:28:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 Koj7ZJwyZDDi for <uta@ietfa.amsl.com>; Thu, 10 Aug 2017 11:28:55 -0700 (PDT)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 DE44F1323A4 for <uta@ietf.org>; Thu, 10 Aug 2017 11:28:54 -0700 (PDT)
Received: by mail-io0-x22f.google.com with SMTP id o9so12765598iod.1 for <uta@ietf.org>; Thu, 10 Aug 2017 11:28:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=VXalmUdq9+ALPKAlb+Wk9Z9o3W5Bd5OaI2WeHuqpwFk=; b=kfW+eu6547YRceIDmt/K8bBQCP1SXb86gCu12Ie4am2Nj84L7zDr0lAZ4n9fp8OuzY oI1Q0UpaURfNUEeFkW+w3Ixf8hW/0b4jjVZdPdN4eNCPFAlQ87timFDBPvy+ZrdsaptW INpf8+479zL8/Kvh9o1qriZcZQn2mbM5lrkqUlw3f989YRDHUm5dcNynRKW3M0I8skFF k9WzfPV6fUnUPhrdA9m08Yh0/mzPFSdZTDTGoihSG+XoA7Znjz9QPU/+aKhENvh2/rS3 fQweNcV/1drkeUAgrjnM8+ingGhEaMeYU97vw4IqbUCwGDxZjlIiGMMICa6ZjfZ2WwUU leyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=VXalmUdq9+ALPKAlb+Wk9Z9o3W5Bd5OaI2WeHuqpwFk=; b=RCMzjrHas9NKQGSTKmnKsxaex9PaLVw33731i4RypTFf1oW+Z+OgaPNK3aKjNcoIhe KujIdue5mGJ1nL1ureiKTac2/xvKP12NOxXxnp4R6z3nSWnYdtvcxzsEseIOL+Ydk0KY R7Yv0lERWcgsEk6ObK0Gx98LpHoZwRZWZPHTe4eCZOYznvCCY13EOjDxksJcmkg1UmxF vZnoNBUiesrE8PrJcRacOX5jVG3Fs2eI8Ol33ta49FZ+hfR89HmGsWm7BWa4K4LNAdGv 18H17IY1YQmE0XOgNWK1flVPNRN/4c3km5Rlcstq7NeqWI+LSSGW/CgLEsnZiKFBoXT8 ry8g==
X-Gm-Message-State: AHYfb5jljodk+7MZszd7+3UhayzQ0QD4DrKLCIQZQMPBT3JHJOrzAeXe BbKD0x6YLpLEuBzKIYZCn5ggLW4GmjsBp8I=
X-Received: by 10.107.134.87 with SMTP id i84mr10584870iod.293.1502389733395; Thu, 10 Aug 2017 11:28:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.133.159 with HTTP; Thu, 10 Aug 2017 11:28:51 -0700 (PDT)
In-Reply-To: <20170810174656.GX8146@mournblade.imrryr.org>
References: <20170808210631.GO8146@mournblade.imrryr.org> <CANtKdUfcn=Z73pxXTov70e2+-0kc9Q6PGTchS=aUhRR0V+RNMw@mail.gmail.com> <9408F973-F6F0-41CD-9A81-82185686E24C@dukhovni.org> <CANtKdUc6PaDyBOcG_LhvezbnZ8JEv=xFf=MosQWSY8dg4MxjLg@mail.gmail.com> <20170809174827.GQ8146@mournblade.imrryr.org> <CANtKdUdqHM-bu_Z_GVcCN_Jca9SNNNdBkQKPOOtX_a=zW_EJZA@mail.gmail.com> <20170809183310.GU8146@mournblade.imrryr.org> <CANtKdUcqcoKjRctyGJ6Qc41vOxEvt8Knzjc6CZGn-0jqN9g5BA@mail.gmail.com> <6050C765-D3FB-4037-930A-43FE00A5CB89@dukhovni.org> <CANtKdUcc5mBNeUd9kPg_VemcbX4vdDwfvVgoXrr=nQtYLDeStQ@mail.gmail.com> <20170810174656.GX8146@mournblade.imrryr.org>
From: Daniel Margolis <dmargolis@google.com>
Date: Thu, 10 Aug 2017 11:28:51 -0700
Message-ID: <CANtKdUf0OqHkXq3PPGbRQFNRezU5+KarcQKfREdGAo1Hq+XVSw@mail.gmail.com>
To: uta@ietf.org
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="001a113f0b826835b705566a5e48"
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/qDY4KlabasuXP5Yqoe9A8H2XROo>
Subject: Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal.
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Aug 2017 18:28:57 -0000

Your point about the administrator of the Policy Domain was exactly my
point, yes. And if an NXDOMAIN result is never "significant"--i.e. if it
only exists for people not actually using STS--then we don't have to
imagine implementors are ever concerned with SOA TTL. So adding
significance in this sense means people have to be aware of NXDOMAIN TTLs
(which to be honest I had to lookup just now to confirm my recollection
that it comes from SOA!).

Again, not a big deal; it's an extra knob, which I generally have been
trying to avoid, but it's not a very complicated extra knob, so it's hardly
a big deal. *shrug*

Feedback from others is welcome. I am very much without a strong opinion on
this one.

On Thu, Aug 10, 2017 at 10:46 AM, Viktor Dukhovni <ietf-dane@dukhovni.org>
wrote:

> On Thu, Aug 10, 2017 at 10:02:41AM -0700, Daniel Margolis wrote:
>
> > Also, note that this slightly oddifies the _DNS_ caching story; the
> > NXDOMAIN TTL is derived from the SOA record, so unlike a "real" TXT
> record,
> > the TTL on the "null" record comes (obviously) from a different place,
> > which is a little bit (but only a little bit) weird in terms of usability
> > of the configuration parameters, so to speak.
>
> Yes, the negative TTL is from the SOA, but the TXT record TTL is
> not something the sending MTA has to concern itself with, the TTLs
> are handled transparently by the resolver.  The difference might
> plausibly matter to the administrator of the receiving domain, who
> might want to adjust the negative TTL, but he might do that regardless
> of whether we refresh cached (!= "none") policies even when the
> TXT is not present.  That is, if you want a shorter or longer
> negative TTL, you would do tune it regardless of how we decide this
> question.
>
> > If anyone else has read this far on the thread, I'm happy to get feedback
> > on this proposal from others on the list.
>
> Yes, please!
>
> --
>         Viktor.
>
> _______________________________________________
> Uta mailing list
> Uta@ietf.org
> https://www.ietf.org/mailman/listinfo/uta
>

v2.23.0 | Report a Bug | By Email