Re: [Uta] back to smtp-sts-04

[Daniel Margolis <[e-mail]>]

On Thu, Apr 6, 2017 at 4:11 PM, Viktor Dukhovni <[e-mail]>
wrote:

>
> > On Apr 6, 2017, at 9:17 AM, Brotman, Alexander <
> [e-mail]> 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.
>

Thanks. Fixed.


> Speaking of the policy, what should be done if the HTTPS policy
> 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.


> 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?
>

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.


> 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?
>

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.


>
> --
>         Viktor.
>
> _______________________________________________
> Uta mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uta
>