On Thu, Jul 20, 2017 at 06:02:00PM +0200, Chris Newman wrote:
> It'd be helpful to have an example workflow, possibly early in the document.
> Something like:
>
> Example:
> recipient: [email protected]
> Determine policy domain [section reference], in this case example.com
> Look up DNS TXT record in _mta-sts.example.com (_mta-sts TXT record in
> policy domain). [section reference].
> If failure or invalid record, stop.
This introduces a downgrade attack on already cached data. The
TXT record alone cannot suppress already cached policy.
> If valid cached policy record, skip forward to SMTP connection.
Any cached data is used unless a TXT record indicates a different
policy id than the one cached. In which case an attempt is made
(perhaps in the background) to obtain a fresh policy.
> Connect to https server at mta-sts.example.com (mta-sts host in policy
> domain). [section reference]
> ...
This sort of thing was supposed to be covered in the state machine
description at the end...
> This reference needs to be changed to draft-ietf-jsonbis-rfc7159bis, or you
> need to explicitly require use of UTF-8 charset, or reference I-JSON (RFC
> 7493). With RFC 7159 there's a requirement to support and detect UTF-16LE,
> UTF-16BE, UTF-32LE, UTF-32BE charsets (and possibly other Unicode encodings)
> that I find highly problematic for interoperability.
No non-ascii data is presently anticipated, but for future proofing
the encoding should be assumed UTF-8.
> > 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"
> > host (as described below), chain to a root CA that is trusted by the
>
> After reading the document, I'm not sure I understand how to construct the
> DNS FQDN that I need to pass to the TLS API in order to validate the mta-sts
> host. In the example workflow above, I made a guess. But the document
> presently never says how to construct the FQDN explicitly.
There is no single FQDN. The certificate is matched against any
of the names in the "mx" attribute. The SNI should be taken from
the MX hostname.
> > The certificate MAY be checked for revocation via the Online
> > Certificate Status Protocol (OCSP) [RFC2560], certificate revocation
> > lists (CRLs), or some other mechanism.
>
> Is there a reason this is a MAY rather than a SHOULD?
Postfix will not implement either CRL checks (reliably maintained
CRLs are an exotic beast) or OCSP. We could implement support for
stapled OCSP, but I am not aware of much support for that on the
server side.
> The abbreviation "SAN" doesn't appear in RFC 5280. Please expand it to
> subjectAltName which does appear.
I prefer "subject alternative name (SAN)" and then "SAN" thereafter.
A "terminology" section entry may be appropriate.
> > DNS-ID matching the "mx" pattern. The MX's certificate MAY also be
> > checked for revocation via OCSP [RFC2560], certificate revocation
> > lists (CRLs), or some other mechanism.
>
> Is there a reason this is a MAY rather than a SHOULD?
See above.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
