Re: [Uta] STS policy removal
Daniel Margolis <dmargolis@google.com> Tue, 25 April 2017 17:01 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 69663129457 for <uta@ietfa.amsl.com>; Tue, 25 Apr 2017 10:01:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, RP_MATCHES_RCVD=-0.001, 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 8BsdTgZC3JSI for <uta@ietfa.amsl.com>; Tue, 25 Apr 2017 10:01:14 -0700 (PDT)
Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 4E6C112945C for <uta@ietf.org>; Tue, 25 Apr 2017 10:01:12 -0700 (PDT)
Received: by mail-it0-x22d.google.com with SMTP id f187so17853437ite.1 for <uta@ietf.org>; Tue, 25 Apr 2017 10:01:12 -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=+bF6sWEGmDqX/jBVaZz6g6Yf7NMXXX4RbeONfj3AnbY=; b=cm1BZBuijbNz+VVSsGII1OHwlMXyCLmabPXrFii6xeCSx+mFRTIJk0jqfVuk8Rs4aR bvn4c/5SkZMzGHkzCGqKi+pu7feUfqm2SLuPXFKxBXKa8uSdJGUYsnpJoUrrMQmIBvW3 PIRFR+tAFjoR3DMfOcUfxhoV16RFbqoSWIdZKwPbL+5iA/XGPFPASi5F4jPzS88riwHs tFfRhmQss4GmK5CAJzlFu6T+hOJBCKsLPAUACiyqurRId2AiNWkh531XjEyp/O3MwA8b S38qaKtl1LEjkHx+8CGALj82dniVn4IUOk1muvATgZw07OLEdEV8itSZ90v3xhAo1rsD 3aRg==
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=+bF6sWEGmDqX/jBVaZz6g6Yf7NMXXX4RbeONfj3AnbY=; b=uLa+9cEBXDKD7ycyMvEjuS35c9NFZoTsqefJl7uPJikTggO2Pv0a7qgVe1Pw68RM7b 2OMsPlNaLHvkO+HVFBmflp8CrWHvBchv4122phin8xeC03ScwxqOI+Ji26bb6gz16qM9 PYbmn6RMMaaVw6E3N6ir+lTXTyp8N+FYxfsmLZSDyKQa3n45ztkNSfofDcvd0+6IEJBb +IFUc/oPTVaEr5KDvMJ5syifZEhtW+GH0Vi2x9actfevmUt45V0uz1YXaKlGZ8HipmZV 5bPdZChP3+LQmAIwcfqVDZesMpI9NIw7ZHyjRacDP3EIX8F9YpHroMKL5stt8TUfnROe IXVA==
X-Gm-Message-State: AN3rC/40LowF1gcdH157HC8ie7zVPZaNFaOysUjbmanBq/ybLtVG9CPX ZEgNyWg1scRBedHfXKnS7DZ+tw1CoU+aI+evqA==
X-Received: by 10.36.58.14 with SMTP id m14mr1550714itm.26.1493139670803; Tue, 25 Apr 2017 10:01:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.36.111.11 with HTTP; Tue, 25 Apr 2017 10:01:09 -0700 (PDT)
In-Reply-To: <F9592600-68CB-484C-922E-3FBB2D8AE9A1@dukhovni.org>
References: <52dde16a-a3bb-5844-7daa-a349def85049@wizmail.org> <80676A32-78CB-4FFA-AEE4-94DA95102B98@dukhovni.org> <a2a6e5f5-ff3b-272b-abda-b49fe23a485d@wizmail.org> <605FE793-3D82-4C4F-9F93-D50DF4320DF5@dukhovni.org> <9402ac0a4990432f994656ddaf94b9e2@COPDCEX19.cable.comcast.com> <CE55E42E-9845-46A6-B0AA-F56CE56F2936@dukhovni.org> <CANtKdUevHbQaUga2=X0tFy4K=po=DL=pKUn-2KZQgRUPTtYAig@mail.gmail.com> <B8600601-9344-427A-B159-B57E982F3BAF@dukhovni.org> <CANtKdUdKmOisdh1j_cFuJ=VCyxJBH-GMWW4DAowC2KZjCFUk1A@mail.gmail.com> <F9592600-68CB-484C-922E-3FBB2D8AE9A1@dukhovni.org>
From: Daniel Margolis <dmargolis@google.com>
Date: Tue, 25 Apr 2017 19:01:09 +0200
Message-ID: <CANtKdUfa36QJqKFzXB+s7As+t9t5=vPbF598hGYdrri4Kw0gAg@mail.gmail.com>
To: uta@ietf.org
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="001a114414e2bab5e5054e00abb7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/2gXYawKKjn6-FAKca9ZT3McNfFo>
Subject: Re: [Uta] 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: Tue, 25 Apr 2017 17:01:18 -0000
> > > That's not the problem. The problem is that even after that time expires > the > current specification does not appear to provide a means to *ever* stop > publishing > a policy. A "report" policy will get cached and then be subject to > another timer, > lather/rinse/repeat. How does the "report" policy ever transition out of > existence, > without looking like a downgrade attack? > > Are you suggesting to rely just on eventual flushing of expired cache > entries that > fail to refresh? Yes. A "report-only" policy with a short max_age (like 1 day) means a client will continue to refresh the policy once/day and, once the time period we have already discussed has passed, will forget it in a day. In terms of optimizing this period of time, there are no options that I see: as I previously noted (though this is trimmed in your reply; just for casual readers I am referring to https://www.ietf.org/mail-archive/web/uta/current/msg01983.html), absent (complex) changes to the TXT records, senders will have to cache some policy existence data anyway, for some period of time, so they will have to cache *something* for *some period*, essentially equivalent to "some period after the expiration time we have discussed", e.g. 1 day. :) > And in the mean-time clients may burn some cycles keeping reporting > data that is unwanted, and may never be sent. > Yes, indeed. So my point was that you could solve this by having a "none" mode (i.e. neither enforce nor report), but the only part of this issue we can optimize is the one you note here (keeping reporting data); *not* (at least without reworking the DNS advertising model, which I think is needless complexity) the caching time. > There ought to be a way to cleanly stop the process without failing > retries at the > end of the cycle. A "max_age = 0" should suffice (published for the > previous > max_age + DNS TTL). > It's still not clear to me whether you are trying to save sender cache entries, sender reporting cycles, or both. I think it would be more clear to split the discussion on those two things. As I noted, you could certainly set "report=false" and "enforce=false" (effectively) by adding some mode switch for this, but the only thing it would optimize is the "keeping stats for reporting is expensive" concern. (I am not really convinced this is that expensive, but it's a fair point.) *Separately*, I do not believe "max_age=0" makes cache expiration easier. As I have already noted, senders who purge a cache entry upon seeing "max_age=0" will then...see the _mta_sts TXT record for this domain next time they check and fetch the policy! So they have to cache the policy to avoid hitting the HTTPS endpoint all the time. How do you propose this should work? It may help me to better understand your suggestion if you flesh it out a little bit more. For example, would senders cache the presence of a "max_age=0" policy for a hardcoded amount of time? > > -- > Viktor. > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta >
- Re: [Uta] back to smtp-sts-04 Viktor Dukhovni
- Re: [Uta] back to smtp-sts-04 Benjamin Kaduk
- Re: [Uta] back to smtp-sts-04 Daniel Margolis
- Re: [Uta] smtp-sts-04 JSON James Cloos
- Re: [Uta] smtp-sts-04 JSON Daniel Margolis
- Re: [Uta] back to smtp-sts-04 Daniel Margolis
- Re: [Uta] smtp-sts-04 JSON Viktor Dukhovni
- Re: [Uta] smtp-sts-04 JSON Viktor Dukhovni
- Re: [Uta] smtp-sts-04 JSON Binu Ramakrishnan
- Re: [Uta] smtp-sts-04 JSON Viktor Dukhovni
- Re: [Uta] smtp-sts-04 JSON Binu Ramakrishnan
- Re: [Uta] smtp-sts-04 JSON Salz, Rich
- Re: [Uta] back to smtp-sts-04 Peter Gutmann
- Re: [Uta] STS policy removal Viktor Dukhovni
- Re: [Uta] smtp-sts-04 JSON Viktor Dukhovni
- Re: [Uta] STS policy removal Daniel Margolis
- [Uta] mtp-tlsrpt-04 review Jeremy Harris
- Re: [Uta] mtp-tlsrpt-04 review Viktor Dukhovni
- Re: [Uta] mtp-tlsrpt-04 review Jeremy Harris
- Re: [Uta] mtp-tlsrpt-04 review Viktor Dukhovni
- Re: [Uta] mtp-tlsrpt-04 review Brotman, Alexander
- Re: [Uta] mtp-tlsrpt-04 review Jeremy Harris
- Re: [Uta] back to smtp-sts-04 Viktor Dukhovni
- Re: [Uta] mtp-tlsrpt-04 review Brotman, Alexander