Subject: [Uta] mtp-tlsrpt-04 review

From: Jeremy Harris <[email-masked]>
Date: Wed, 5 Apr 2017 16:00:13 +0100

The example in Appendix 9 implies that the Policy Domain
should correspond to the domain part of email addresses
attempted.  I think this should be made explicit in an
earlier section, eg. Section 3 ("A domain should") -
otherwise it could confused with the A-record domain
of an MX.

CNAME indirections should be explicitly discussed
(I'd like them permitted).

-- 
Cheers,
  Jeremy

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 5 Apr 2017 11:46:28 -0400

> On Apr 5, 2017, at 11:00 AM, Jeremy Harris <[email-masked]> wrote:
> 
> The example in Appendix 9

All I see is "Section 10, Appendix 1" and "Section 11, Appendix 2".
What is "Appendix 9"?

> (I'd like them permitted).

Where would you like to see CNAMEs permitted?

[ Oh, and by the way, it seems the authors have concluded that
  JSON policy has rough consensus.  I am not sure that's accurate,
  or at least don't think that accurately represents MTA implementors.

  Where do you stand on the JSON issue?  I am not looking forward to
  adding a JSON parser to Postfix, or requiring all the O/S platforms
  to provide a common C JSON API (is there one that is widely available)
  as a pre-requisite for installing Postfix. ]

-- 
	Viktor.

---

From: Jeremy Harris <[email-masked]>
Date: Wed, 5 Apr 2017 17:02:32 +0100

> All I see is "Section 10, Appendix 1" and "Section 11, Appendix 2".

Apologies.  Section 9, being Appendix 2.

> Where would you like to see CNAMEs permitted?

Perhaps Section 3, initial paragraph.

>   as a pre-requisite for installing Postfix. ]

I do not intend to add a JSON parser to Exim, and would make my
anti-bloat views known to any of the other Exim developers.

[I have the same views on any need for https, cf. MTA-STS]

However, I don't think using JSON for the reports defined by this
draft would require an MTA-based parser.

-- 
Cheers,
  Jeremy

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 5 Apr 2017 13:14:53 -0400

> On Apr 5, 2017, at 12:02 PM, Jeremy Harris <[email-masked]> wrote:
> 

Oops, sorry, I though you were commenting on the STS draft, not
the report draft.

> [I have the same views on any need for https, cf. MTA-STS]

Sorry that question was about STS...

-- 
	Viktor.

---

From: "Brotman, Alexander" <[email-masked]>
Date: Thu, 6 Apr 2017 13:17:00 +0000

In section 4, it mentions the Policy section should include the domain for which the policy was applied.  I can add another reference in Section 3 if that's preferred.

We can add an explicit CNAME mention. 

With regard to the JSON policy (though that's STS, not TLSRPT).  It's a small file, which given the JSON requirement, should be properly formatted.  I would think this should be relatively easy to parse with standard C string functions.

--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast
x5364

-----Original Message-----
From: Uta [mailto:[email-masked]] On Behalf Of Viktor Dukhovni
Sent: Wednesday, April 05, 2017 1:15 PM
To: [email-masked]
Subject: Re: [Uta] mtp-tlsrpt-04 review

> Apologies.  Section 9, being Appendix 2.

Oops, sorry, I though you were commenting on the STS draft, not the report draft.

>> [ Oh, and by the way, it seems the authors have concluded that  JSON 
>> policy has rough consensus.  I am not sure that's accurate,  or at 
>> least don't think that accurately represents MTA implementors.
>> 
>> to provide a common C JSON API (is there one that is widely 
>> available)  as a pre-requisite for installing Postfix. ]
> 

-- 
	Viktor.

_______________________________________________
Uta mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/uta

---

From: Jeremy Harris <[email-masked]>
Date: Thu, 6 Apr 2017 14:35:07 +0100

> In section 4, it mentions the Policy section should include the domain for which the policy was applied.  I can add another reference in Section 3 if that's preferred.

The point I'm trying to make is that the generator of reports needs to
know how to select a domain for which a particular message transmission
attempt should be reported against.  This needs to be specified.
Please give the semantics of this "domain" mentioned in both sections 3
and 4 (separately if they differ, else it needs to be clear that they
are the same; perhaps by using the term "Policy Domain" mentioned in
section 1).
-- 
Cheers,
  Jeremy

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 6 Apr 2017 10:11:51 -0400

> On Apr 6, 2017, at 9:17 AM, Brotman, Alexander <[email-masked]> wrote:
> 
> With regard to the JSON policy (though that's STS, not TLSRPT).
> It's a small file, which given the JSON requirement, should
> be properly formatted.  I would think this should be relatively
> easy to parse with standard C string functions.

Here are the line counts for the "*.[ch]" files from what appears
to be a popular JSON parsing API for C:

$ git clone https://github.com/json-c/json-c.git
$ cd json-c
$ wc -l *.[ch] | sort -n
      11 strdup_compat.h
      19 json_inttypes.h
      20 json_c_version.c
      22 json_c_version.h
      25 random_seed.h
      26 libjson.c
      31 math_compat.h
      34 json.h
      35 bits.h
      45 vasprintf_compat.h
      55 json_object_private.h
      63 arraylist.h
      71 debug.h
      83 debug.c
      89 json_util.h
      91 json_visit.h
     114 printbuf.h
     115 json_pointer.h
     133 json_visit.c
     143 arraylist.c
     154 printbuf.c
     168 json_object_iterator.c
     208 json_tokener.h
     238 random_seed.c
     239 json_object_iterator.h
     326 json_pointer.c
     326 json_util.c
     366 linkhash.h
     690 linkhash.c
     901 json_object.h
     978 json_tokener.c
    1195 json_object.c
    7014 total

That does not jive with relatively easy to parse...

JSON supports comments, elements that are integers, strings,
arrays or associative arrays (nested JSON objects).  JSON
strings are UTF-8 and allow embedded NUL octets.

Your JSON reference is to the obsolete RFC4627, the non-obsolete
reference is RFC7159.

Speaking of the policy, what should be done if the HTTPS policy
contains multiple JSON objects, no JSON objects, or broken JSON?

Is there a size limit a parser can reasonably impose on the policy
data to avoid resource exhaustion parsing absurdly large JSON input?
Could we say for example that a valid STSv1 JSON object must fit in
16K bytes or 64K bytes?

How does a domain get rid of its STS policy?  I thought we had discussed
using "max_age = 0" for this, which after being in place long enough to
assure that all previously cached policies have expired can be removed.
Or might just "404" suffice?

-- 
	Viktor.

---

From: "Brotman, Alexander" <[email-masked]>
Date: Fri, 7 Apr 2017 13:20:50 +0000

Ah, we'll make that more clear. Thank you for the feedback.

--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast
x5364

-----Original Message-----
From: Uta [mailto:[email-masked]] On Behalf Of Jeremy Harris
Sent: Thursday, April 06, 2017 9:35 AM
To: [email-masked]
Subject: Re: [Uta] mtp-tlsrpt-04 review

> In section 4, it mentions the Policy section should include the domain for which the policy was applied.  I can add another reference in Section 3 if that's preferred.

The point I'm trying to make is that the generator of reports needs to know how to select a domain for which a particular message transmission attempt should be reported against.  This needs to be specified.
Please give the semantics of this "domain" mentioned in both sections 3 and 4 (separately if they differ, else it needs to be clear that they are the same; perhaps by using the term "Policy Domain" mentioned in section 1).
--
Cheers,
  Jeremy

---

From: Daniel Margolis <[email-masked]>
Date: Sat, 22 Apr 2017 19:35:26 +0200

> Your JSON reference is to the obsolete RFC4627, the non-obsolete

Thanks. Fixed.

> contains multiple JSON objects, no JSON objects, or broken JSON?

   "If a valid TXT record is found but no policy can be fetched via
   HTTPS, and there is no valid (non-expired) previously-cached policy,
   senders MUST treat the recipient domain as one that has not
   implemented MTA-STS."

If you can't parse it, it's not a valid policy, so you fall back to
cached-non-expired or none.

Same as if there's an HTTP timeout, an HTTPS cert validation error, etc.

> Could we say for example that a valid STSv1 JSON object must fit in

It's certainly very reasonable to do so in an implementation, to be sure.
Since we already have this text on timeouts:

  "Senders MAY impose a timeout on the HTTPS GET to avoid long delays
   imposed by attempted policy updates.  A suggested timeout is one
   minute; policy hosts SHOULD respond to requests with a complete
   policy body within that timeout"

we could also say the same for a maximum size on the response. As you say,
even a very small limit like 64Kb is "absurdly large", so I am not
convinced we need to specify a hard limit (in the sense that a very
conservative--from the perspective of RAM usage--limit still provides a
huge buffer for valid policies!).

I have added some text to the above paragraph.

> Or might just "404" suffice?

Yes, I remember discussing this. But I am not sure such a mechanism is
needed.

1. Domains can publish a "report" policy (with or without a TLSRPT record!)
with a low expiration
2. They have to keep this policy published until "last time the old policy
was published" + "old policy's max_age"

The knock-on effects of this are fairly limited: a) extra record in the
sender's policy cache, and b) maybe some extra CPU cycles spent on starting
any reporting path before discovering there's no TLSRPT record to report
to.

Let's consider in comparison an implementation with a special "opt out"
mechanism (however it works). Would it avoid the above two knock-on
effects, or be easier to publish?

I think for publishing (i.e. the duration required in #2 above) the answer
is "no"; obviously the "opt out" must be published in the same way (i.e.
for the same duration) as any new policy. Similarly, because it must be
published as (effectively) a new policy, senders must still cache it (or
else hit the endpoint every time), so we're still talking about knock-on
effect (a).*

So I think the only argument for adding an explicit opt-out--which I think
is otherwise extra complexity to be avoided--is to avoid (b), i.e., to
avoid any cost of a "report-only" policy which has no reporting endpoint
defined. And I suspect that cost is low, and does not justify even the
minimal additional complexity of an "opt out".

But I may be missing something here, as usual. ;)

* In fact, you could design a behavior where the TXT record indicates if
the new policy is an "opt out" one or not, such that senders who do not
have a cached policy for the domain can be told via DNS-only not to lookup
the new policy, but senders who do have a policy MUST look it up to
determine if it is an authenticated "opt out." But the extra complexity
here is high--making the system quite hard to reason about by introducing a
new variant of the lookup flow--with limited real value.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 22 Apr 2017 22:50:01 -0400

> On Apr 22, 2017, at 1:35 PM, Daniel Margolis <[email-masked]> wrote:
> 
> If you can't parse it, it's not a valid policy, so you fall back to cached-non-expired or none.

Getting an authenticated invalid policy seems rather different from failure
to retrieve the policy.  The latter is obviously a temporary condition and
one can stick with what's cached.  On the other hand when an authentic policy
fails to parse, it seems clear whatever we had in the cache is no longer the
current policy.  So what is the right course of action is not so clear.
 
>> Or might just "404" suffice
> 
> Yes, I remember discussing this. But I am not sure such a mechanism is needed.

I rather think it is needed.  When a domain changes hands, or no longer wishes
to deal with the hassles of certificate expiration, it must be possible to
revoke the policy.

> 1. Domains can publish a "report" policy (with or without a TLSRPT record!)

What happens when that expires?  It is again found and refreshed unless there's
a way to ultimate say "no policy".

> 2. They have to keep this policy published until "last time the old policy was
> published" + "old policy's max_age"

Yes, but that's not actually policy removal.  Clients will likely still end up
collecting stats for reports, even if they later prove undeliverable or there's
no address to send them to.

> Let's consider in comparison an implementation with a special "opt out" mechanism
> (however it works). Would it avoid the above two knock-on effects, or be easier
> to publish?

It seems to me that "age=0" is simpler and more clear than "report".  Combined with
ultimate removal of the DNS TXT record the policy is eventually flushed from caches.

> I think for publishing (i.e. the duration required in #2 above) the answer is "no"; obviously the "opt out" must be published in the same way (i.e. for the same duration) as any new policy. Similarly, because it must be published as (effectively) a new policy, senders must still cache it (or else hit the endpoint every time), so we're still talking about knock-on effect (a).* 
> 
> So I think the only argument for adding an explicit opt-out--which I think is otherwise extra complexity to be avoided--is to avoid (b), i.e., to avoid any cost of a "report-only" policy which has no reporting endpoint defined. And I suspect that cost is low, and does not justify even the minimal additional complexity of an "opt out". 

How does the "report" policy ultimately go away?  When can clients stop doing
policy lookups and the HTTPS service be decommissioned?

> But I may be missing something here, as usual. ;) 

Yes, how does the refresh cycle stop...

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 22 Apr 2017 22:58:25 -0400

> Your JSON reference is to the obsolete RFC4627, the non-obsolete

So any compelling arguments for JSON from MTA implementors?

A much simpler format would be a block of lines (CRLF terminated),
with each line either a boolean propery name, or a name value pair.

	version STSv1
	mode report
	max_age 8640000
	mx mx1.example.com
	mx mx2.example.com
	...

Line length is limited to the usual 1000 bytes including the
terminating CRLF.

This simplifies parsing, because a simple line-orienter parser
can now process the entire policy.  It is no longer possible
to have multiple policies, as with JSON, because there is no
way to express multiple objects.  The JSON format is much
too general for the needs at hand.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Sun, 23 Apr 2017 14:42:56 +0200

> current policy.  So what is the right course of action is not so clear.

It's not clear, to be sure, but any other strategy is complex. If we can't
parse the new policy, do we assume a misconfiguration and fail open? It's a
corner case where the most predictable behavior, to me, would be to ignore
new policies which are unparseable. I think predictability here is a
virtue.

Of course, my intuition about expected behavior may be wrong. But if I'm
correct on what's "predictable", overriding that intuition with explicitly
specified behavior (like, "unparseable policies should be taken as a sign
that the recipient domain is confused and has opted out of STS, despite any
valid cached policy") seems not desirable to me, unless the risks are very
high.

> a way to ultimate say "no policy".

Sure, but as I explained, given *any *hypothetical "opt-out" mechanism, it
is theoretically not possible to design one which you do not have to keep
publishing until $time_you_last_had_a_different_policy +
$that_policy's_max_age has passed.

(Since I'm referring to this time below, let's call it "old policy
expiration time.")

In other words, publishing a report-only policy with a low expiration is
just as good as publishing an "opt out" policy, in the sense that in the
former case you have to publish the report-only up until the old policy has
expired everywhere, and in the latter case it's identical.

> no address to send them to.

As I discussed, the only consideration here seems to be one if, "Are the
costs of 'reporting' (i.e. stats collection, etc) sufficiently high to
warrant the need for an explicit opt-out mechanism?"

I don't personally think so, but I may be wrong here.

> mechanism

Here and below in your email, it seems your main question is (to
paraphrase), "When will senders know to stop caching a policy, even if it
is a 'report only' policy?"

In fact there are two different things to consider here:

1. When can the recipient stop publishing the "opt out" policy?
2. When can the sender stop caching the policy?

The point I attempted to make in my previous email is that #1 is invariant,
regardless of mechanism: in all cases, the recipient must publish the "opt
out" signal until the max time at which the previous policy was published
*plus* that policy's max_age has passed. (I believe this is obvious.)

However, #2 is also mostly unchanged in most of these various designs:
assuming any "opt out" indicator that uses the usual TXT "id" string as an
indicator of presence, senders will want to cache the "id" seen in order to
see if the "opt out" policy has been supplanted by an "opt in", if only to
avoid repeated policy refreshes.

(Of course senders could merely cache the last version seen for that domain
and a null policy; they don't need to cache anything else for the sake of
supporting opt-outs. And in fact, we could achieve the same security
properties as exist now by purging the cache on opt-out and instead
embedding one new boolean indicator in the TXT record, indicating that the
new policy is an opt-out policy, to be fetched only by senders who have
cached a non-opt-out policy. I trust the functioning of this approach is
obvious, but regardless, it's needless complexity and I would rather not
explain it if it's not. :) )

So the long and short of it is that one *cannot* design a system in which
the recipient does not have to publish the "opt out" signal for this amount
of time; I'm fairly sure that's an invariant.

Contrarily, one *could* design a system in which senders do not have to
cache anything at all for domains that have opted out, but, at least as far
as I can see, only by modifying the TXT record format, which is not
desirable to me.

Two questions for you:

1. Is your main concern point 1 above (i.e. when can recipients stop
publishing) or point 2 (i.e. how can we save cache space of cached "opt
out" policies)?
2. If #2, can you propose with more detail how you suggest a different
mechanism to work? Does it involve the TXT modification I describe above?
Or is there a simpler way?

---

From: Daniel Margolis <[email-masked]>
Date: Sun, 23 Apr 2017 14:48:40 +0200

In the interests of not looking like I'm ignoring your mail, just to
reiterate, I have no personal feeling about this. My read at the meeting in
Chicago was that consensus was not totally obvious, but I'm really happy to
defer to the chairs here on what the consensus seems to be or how to
unblock this.

As I have said before, while this is certainly an issue people have
legitimately strong feelings about, it's not really a *fundamental* issue,
and, speaking personally (and I think for the other authors), I would be
happy with any resolution in any direction--the main point here is to
provide some additional security to email-in-transit, not to provide
security to email-in-transit by leveraging JSON. ;)

Dan

---

From: James Cloos <[email-masked]>
Date: Sun, 23 Apr 2017 16:03:26 -0400

>>>>> "VD" == Viktor Dukhovni <[email-masked]> writes:

VD> A much simpler format would be a block of lines (CRLF terminated),
VD> with each line either a boolean propery name, or a name value pair.

CRs should not be required in such a format.

It should be possible to serve a static text file in that case, and not
have to worry about (or muck around with) line endings.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Binu Ramakrishnan <[email-masked]>
Date: Mon, 24 Apr 2017 22:34:06 +0000 (UTC)

IMO the main hurdle with key-value format is that we do not have a standard format, and by extension off-the-shelf library support. So the question is - whether to write custom kv parsers or use a standard format - JSON.
Thanks,-binu

      From: Daniel Margolis <[email-masked]>
 To: [email-masked] 
 Sent: Sunday, 23 April 2017 5:48 AM
 Subject: Re: [Uta] smtp-sts-04 JSON
   
In the interests of not looking like I'm ignoring your mail, just to reiterate, I have no personal feeling about this. My read at the meeting in Chicago was that consensus was not totally obvious, but I'm really happy to defer to the chairs here on what the consensus seems to be or how to unblock this. 
As I have said before, while this is certainly an issue people have legitimately strong feelings about, it's not really a fundamental issue, and, speaking personally (and I think for the other authors), I would be happy with any resolution in any direction--the main point here is to provide some additional security to email-in-transit, not to provide security to email-in-transit by leveraging JSON. ;) 
Dan

        version STSv1
        mode report
        max_age 8640000
        mx mx1.example.com
        mx mx2.example.com
        ...

--
        Viktor.

______________________________ _________________
Uta mailing list
[email-masked]
https://www.ietf.org/mailman/ listinfo/uta

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 24 Apr 2017 18:49:36 -0400

> On Apr 24, 2017, at 6:34 PM, Binu Ramakrishnan <[email-masked]> wrote:
> 
> IMO the main hurdle with key-value format is that we do not have a standard
> format, and by extension off-the-shelf library support. So the question is
> - whether to write custom kv parsers or use a standard format - JSON.

SMTP MTAs already parse key-value pairs in EHLO responses, and ESMTP
extensions to the MAIL FROM and RCPT TO commands.  No additional code
is required to do similar parsing of the policy in question.

JSON is not a standard "format" it is a general syntax, that can 
represent a stream of composite objects.  This is a poor fit in
terms of the libraries needed to support JSON and having to deal
with attributes that hold the wrong kind of data (list instead
of scalar) or multiple objects instead of one...

-- 
	Viktor.

---

From: Binu Ramakrishnan <[email-masked]>
Date: Tue, 25 Apr 2017 04:21:53 +0000 (UTC)

As an engineer I agree with you and would be hesitant to add additional dependencies to my software. But when we talk about IETF and standards, is it not better to promote widely accepted syntax/format?
Wondering why IETF doesn't have a RFC doc for kv pair syntax.
thanks-binu

      From: Viktor Dukhovni <[email-masked]>
 To: [email-masked] 
 Sent: Monday, 24 April 2017 3:49 PM
 Subject: Re: [Uta] smtp-sts-04 JSON

-- 
    Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 25 Apr 2017 01:19:59 -0400

> On Apr 25, 2017, at 12:21 AM, Binu Ramakrishnan <[email-masked]> wrote:
> 
> As an engineer I agree with you and would be hesitant to add additional
> dependencies to my software. But when we talk about IETF and standards,
> is it not better to promote widely accepted syntax/format?

That should be sufficient.  We should use the simplest thing that does
the job and no simpler.  Key-value fits the bill.

> Wondering why IETF doesn't have a RFC doc for kv pair syntax.

There's no reason for an RFC to describe trivial lists of pairs.

In ESMTP some of the values are xtext encoded, because the context
is restricted to US-ASCII and does not permit whitespace in the
values.

Here, if we emit one KV pair per line, there's no need for xtext.
The simplest design (perhaps either LF or CRLF terminated) is to
one line per item of multi-valued attributes like "mx".  That way,
there's no need to parse internal delimiters in a value list.

	version STSv1
	...
	mx smtp1.example.com
	mx smtp2.example.com
	...

-- 
	Viktor.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 25 Apr 2017 12:05:07 +0000

Viktor Dukhovni  <[email-masked]> writes:

>Here are the line counts for the "*.[ch]" files from what appears to be a
>popular JSON parsing API for C:
>[...]

JSON is simple to parse in the same way that LDAP is lightweight, CIFS is
common, and anything whose name begins with "People's Democratic Republic of"
is neither of the people, democratic, or a republic.

Peter.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 25 Apr 2017 12:31:24 +0000

> There's no reason for an RFC to describe trivial lists of pairs.

Sure there is, because folks will want whitespace, want to linearize it, support Unicode, etc.

The MIME parameter lists, maybe?

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 25 Apr 2017 10:20:35 -0400

> On Apr 25, 2017, at 8:31 AM, Salz, Rich <[email-masked]> wrote:
> 
>> 

As soon as you ask for a generally applicable syntax you end with
ASN.1, JSON, XML, ...  There's no shortage of power tools, but our
needs here are trivial, and the sensible thing to do is to specify
the simplest grammar that meets all the needs.

   * No nested lists
   * No multiple objects
   * No DTDs
   * No separate string, array, integer types
   * No complex libraries with CVEs (https://www.suse.com/security/cve/CVE-2015-8863/)

Parsing a line that contains a key and a value is trivial.  There's a bit
of mostly irrelevant bike-shedding over whether that syntax should be:

	<KEY> 1*<WSP> VALUE 0*<WSP> <CRLF>
or
	<KEY> 0*<WSP> = 0*<WSP> <VALUE> 0*<WSP> <CRLF>

where <CRLF> is either of <CR><LF> or just <LF>, and
each character of KEY and VALUE is ASCII alphanumeric
or one of ".", "-", "+".  The value encoding is "xtext"
from https://tools.ietf.org/html/rfc3461#section-4, but
none of the STSv1 keys require or shall permit hex-encoded
xtext characters.  Thus "+" may appear only in presently
ignored keys from some future update of the protocol in
which some additional policy element requires extended
characters.

Therefore parsers don't need, and will likely never need
to actually implement xtext, that's just there to avoid
objections that we may need (however unlikely) something
more general some day.

Speaking of extensibility, I don't see any reasonable
migration path from STSv1 to STSv2, except by changing
the .well-known URI, in which case putting the version
in the policy, rather than the URL is of little value.

I doubt any site will want to shut out all the deployed
STSv1 clients by switching to a hypothetical STSv2.

Therefore, we can either put a list of supported STS
versions in the DNS TXT record or live with STSv1 for
ever (likely the simplest approach, just add more
key/value pairs as needed and maintain a backwards
compatible interface).

A needlessly complex alternative is either multiple
blocks of key/value pairs separated by a blank line
with block specific to its own STS version, which
must come first, or, worse still, a list of JSON
objects.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 25 Apr 2017 11:08:31 -0400

> On Apr 23, 2017, at 8:42 AM, Daniel Margolis <[email-masked]> wrote:
> 
> Sure, but as I explained, given any hypothetical "opt-out" mechanism, it is
> theoretically not possible to design one which you do not have to keep publishing
> until $time_you_last_had_a_different_policy + $that_policy's_max_age has passed.

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?  And in the mean-time clients may burn some cycles keeping reporting
data that is unwanted, and may never be sent.

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).

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Tue, 25 Apr 2017 19:01:09 +0200

> 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

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.

> end of the cycle.  A "max_age = 0" should suffice (published for the

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?