YS: some of the attacks do not depend on the client executing JavaScript, but rather on the use of cookies (bearer tokens) which can be intercepted/logged/uploaded on the server side. I don't know of bearer tokens being used in SMTP, but it doesn't look like an HTTP-only notion.
Mail sessions have very little context, and none from one session to the next. You can send multiple messages in a session but the only thing the session remembers is the set of features offered by the server at the start of the session.
POP, IMAP, and SUBMIT all use SASL authentication before you can do anything interesting, but I don't immedately see how ALPACA would take advantage of that.
YS: I don't know how to implement "great scepticism"... Specifically, if you have a human in front of a web browser maybe you could use UI indicators, but what do you do if the client is a script calling a REST API?
Beats me. What happens if the REST API uses a server that only speaks SSLv3?
YS: Agreed. My own expectation is that the TLS BCP (like other non-urgent security upgrades) will be applied during routine upgrades. Compare enterprise-wide SHA-1-to-SHA-256 migration projects.
OK, but don't get your hopes up. DKIM mail authentication has been telling people to use SHA-256 since we published the original DKIM spec in 2007, and we formally deprecated SHA-1 in RFC 8301 in January 2018. I just counted the signatures on mail I've gotten since the beginning of the year:
sha-256 9141 sha-1 1479 Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
