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 11:49 PM Ben Campbell <[e-mail]> wrote:

>
>
> On May 10, 2018, at 8:53 AM, Daniel Margolis <[e-mail]> wrote:
>
>
>
> 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).
>
>
> 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.
>

Right, good point. The intended meaning of that phrase is that it signals
the recipient domain does not currently have an STS policy (and should skip
the rest of policy discovery); what that results in depends on whether
there is a previously cached policy. I will try to clarify this a bit more:

If the number of resulting records is not one, senders MUST assume the
recipient domain
does not have an available MTA-STS policy and skip the remaining steps of policy
discovery.  (Note that lack of an available policy does not signal opting out of
MTA-STS altogether if the sender has a previously cached policy for the
recipient domain, as discussed in (#policy-application-control-flow), "Policy
Application Control Flow".)



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

Done:

During the TLS handshake initiated to fetch a new or updated
policy from the Policy Host, the Policy Host HTTPS server MUST present a X.509
certificate which is valid for the `mta-sts` DNS-ID ([@?RFC6125]) (e.g.,
`mta-sts.example.com`) as described below, chain to a root CA that is trusted by
the sending MTA, and be non-expired.




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

Note also the following text in the Security Considerations section:

Broadly speaking, attackers may compromise the system by obtaining certificates
under fraudulent circumstances (i.e., by impersonating the legitimate owner of
the victim domain), by compromising a Certificate Authority or Delegate
Authority's private keys, by obtaining a legitimate certificate issued to the
victim domain, and similar.

One approach commonly employed by Web browsers to help mitigate against some of
these attacks is to allow for revocation of compromised or fraudulent
certificates via OCSP [@?RFC6960] or CRLs [@?RFC6818].  Such mechanisms
themselves represent tradeoffs and are not universally implemented; we
nonetheless recommend implementors of MTA-STS to implement revocation mechanisms
which are most applicable to their implementations.

Given that, should we still remove the MAY? That seemed appropriate
language ("MAY"), but I'm happy to remove it depending on your feedback--I
just wanted to call out that reasoning is somewhat covered here already.


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

Done.


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