On Fri, Sep 05, 2014 at 05:59:12PM -0400, Phillip Hallam-Baker wrote:
> > SMTP is not that latency sensitive. Because SMTP starts in cleartext,
> > servers can and do refuse to STARTTLS with clients they are going
> > to reject due to poor IP reputation.
> >
> > There are other advantages. For example, the server learns the
> > client's EHLO name before TLS, allowing it to base TLS policy (like
> > requests for the client certificate) on the the client's EHLO name.
> > And of course clients that fail to interoperably negotiate TLS can
> > fall back to cleartext.
> >
> > All told, STARTTLS is a good fit for SMTP, which unlike HTTP is
> > not nearly as sensitive to latency.
>
> Very good points and points that designers of DNS privacy approaches
> would do to bear in mind. Any protocol that has a server performing a
> public key transaction without any form of authentication on the
> request is going to end up being killed by DoS.
Postfix can also rate limit run-away clients that rapidly create
uncached sessions, rather than reuse established sessions. This
behaviour can be "stress-dependent", when the service process limit
has recently been reached. While not widely deployed by default,
such counter-measures are good to have up one's sleeve.
> So the trick is to pull the authentication out of the DNS query loop
> so it can be amortized.
Similiar ammortization ideas in DJB's MinimaLT, suggestions for
short-term re-use of ECDH exponents with 25519, ... Also in much
more mundane process-reuse in Postfix, where each service handles
100 or so requests by default before exiting, ammortizing start-up
cost.
--
Viktor.
_______________________________________________
Endymail mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/endymail
