On May 10, 2018, at 8:53 AM, Daniel Margolis <[email protected] <mailto:[email protected]>> wrote:
> > > On Thu, May 10, 2018 at 4:34 AM Ben Campbell <[email protected] > <mailto:[email protected]>> 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 > <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/ > <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). That seems to be contradicted by the following sentence in the last paragraph of §3.2... "If the number of resulting records is not one, senders MUST assume the recipient domain does not implement MTA-STS and skip the remaining steps of policy discovery.” … since zero records in not one. > > So a statement like that might bring the clarity you want? What do you think? Possibly. For the record, I don’t have strong feelings what the procedures should be, just that they should be clear and explicit :-) > > 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. I see discussion has ensued on this point, so I will await the outcome of that. > > §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 > <http://mta-sts.example.com/>"). The HTTPS client in this context is the > sending MTA. I will try to add some clarity to that effect. That would help. It would also help to add text clarifying that “presenting a certificate” happens in the context of a TLS handshake for the HTTPS transaction. (assuming that is the intent.) > > - 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.) A possible approach here would be to forgo the MAY, and just say why might want to check for revocation and the possible consequences of not doing so. > > - 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? Basically anywhere “sender” is used without qualification. Including it in the Terminology section would probably be fine. > > > §4.1: Why is checking for certificate revocation only a MAY? > > > _______________________________________________ > Uta mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/uta > <https://www.ietf.org/mailman/listinfo/uta>
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
