On Wed, Mar 23, 2016 at 04:19:04PM -0400, Wietse Venema wrote:

> > > 1) An optional smtp_check_tls_policy client in the Postfix SMTP
> > > client that speaks TCP or local IPC just like the SMTP server's
> > > check_policy feature.
> > > 
> > >     /etc/postfix/main.cf:
> > >   smtp_check_tls_policy = inet:127.0.0.1:12345
> > 
> > Unfortunately, this is not quite sufficient for STS.  There are
> > two complications:
> > 
> >     1.  STS policies are "validated" at time of first use, and
> >     caching of the policy is only enabled on successful delivery.
> >     2.  STS domains will likely solicit authentication failure feedback.
> > 
> > So the STS policy service will need to receive success/failure
> > reports for deliveries to domains that publish STS policy.
> > 
> > > Is this all paractical, or will we be stuck with C code?
> > 
> > Not yet clear...
> 
> What about two requests: the first to look up policy, and the second
> to report success/failure status? The second part would require a
> few new attributes, because the Postfix SMTP client currently does
> not maintain detailed attributes after TLS failure.

Yes, two requests may be suffice, there may need to be an instance
token with the first response that is returned in the second request.

It is perhaps a bit early to predict what we'll need, one thing I
did not see discussed in the STS draft is a clear definition of
success/failure when a domain has multiple MX hosts.

    1.  What happens when the initial MX RRset includes some MX
        hosts that don't match the STS policy, which is not yet
        validated?  Is that a failure?  Should those MX hosts be
        ignored?

    2.  What happens when the delivery succeeds with a second
        MX host after failing with a first?  Should the STS policy
        validated and pinned?

    3.  What is an appropriate timeout for the HTTPS policy
        request?  Is the error reporting address in DNS or HTTPS?
        Should HTTPS lookup errors be reported?

On second reading, the current text seems to suggest that fetching
authenticated policies via the HTTPS URI happens only on failure,
and that only at that point one should fetch an "authenticated"
policy.  On the other hand it talks of refreshing policies before
they expire, ... 

The present draft is clear as mud...

-- 
        Viktor.

Reply via email to