Re: [Uta] Ben Campbell's Yes on draft-ietf-uta-mta-sts-17: (with COMMENT)

[Daniel Margolis <[e-mail]>]

On Thu, May 10, 2018 at 4:34 AM Ben Campbell <[e-mail]> wrote:

> Ben Campbell has entered the following ballot position for
> draft-ietf-uta-mta-sts-17: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-uta-mta-sts/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I'm balloting "Yes" because I want to see this work published. But I have
> a few
> concerns:
>
> §3 seems to leave much of the interpretation of the TXT record as
> "implication". It should be explicit. I'd like to see the specific steps
> the
> sender is supposed to follow (perhaps the flow in §5.1 could be expanded to
> include the TXT query and interpretation?


The specific reason we kept section 5 only about "application" (and not
"fetch"). There is (I hope) a natural abstraction layer between the two.
Perhaps instead we should add a similar "control flow" subsection in
section 3 or 4, if we can figure out what should be in that subsection.
Questions below:


> For example, the idea that a non-existent record means no MTA-STS support
> is
> sort of buried in the description of multiple text records. Would it be
> reasonable to say that the sender SHOULD NOT query for policy if the id
> hasn't
> changed since a previous query?
>

Just to be clear (though I think this is what you meant), a non-existent
TXT record only means there's no new policy to fetch. It does not say that
STS is not supported, exactly--if the sender has a previously cached and
non-expired policy, the sender MUST apply that cached policy. In other
words, policy fetch failure has no meaning with respect to whether the
recipient domain has implemented STS, and what to do in this case depends
on the state of the sending MTA (whether it has a previously fetched policy
or not).

So a statement like that might bring the clarity you want? What do you
think?

With respect to your last sentence, I'm afraid I don't follow this part. A
sending MTA can certainly query for a new policy even if the TXT record's
ID hasn't changed. I see no reason to--because a working system MUST NOT
require senders to do this--and senders probably SHOULD NOT do this in
order both to a) ensure people use the DNS signalling mechanism
appropriately and b) to save traffic to the HTTPS endpoint--but it's an
operational issue and not one of correctness per se.

§3.3:
> - "When fetching a new policy or updating a policy, the HTTPS endpoint MUST
> present a X.509 certificate which is valid for the "mta-sts" I find this
> confusing. Which endpoint is doing the fetching? Which one MUST present the
> cert. Are we talking about this in the context of TLS or something else?


Yes, this is in reference to the "policy host" (i.e. mta-sts.example.com").
The HTTPS client in this context is the sending MTA. I will try to add some
clarity to that effect.


> - Why
> is checking for certificate revocation only a MAY?


This is discussed a few other places on the working group, but in short, it
seems to me the ecosystem is not exactly on the same page with respect to
revocation. From my rather limited knowledge, OCSP Must-Staple is probably
the only currently-viable option (in terms of having the security and
functional properties we want), but is not widely supported in MTA land
(e.g. Postfix does not support OCSP at all). If there's a meaningful (i.e.
in our threat model) and widely implemented/applicable approach here, we
should use it, but I don't think there is.

(For HTTPS, revocation is maybe more viable, but absent revocation support
on the SMTP TLS channel it doesn't really help to require it in one place.)


> - Does the term "sender"
> refer to the SMTP sender, or something else?
>

Yes, the SMTP sender. I can clarify this--can you help me by pointing out
the places this stands out as confusing language? Or should it just be
included in the Terminology section?


>
> §4.1: Why is checking for certificate revocation only a MAY?
>
>
> _______________________________________________
> Uta mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uta
>