It appears that Jeremy Harris <jgh(_at_)wizmail(_dot_)org> said:
Should we request a TLS ALPN identifier?
Maybe we should request two, one for SMTP and one for SUBMIT.
I asked one of the draft's authors if he knows why POP and IMAP have ALPNs
and SMTP doesn't.
I do worry about getting the ALPNs right in the common case that the same host
offers SMTP, SUBMIT, POP, and IMAP.
Current registry:
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids
Draft recommendation:
draft-ietf-uta-rfc7525bis-01.txt
- Section 5 "Applicability Statement" lists "SMTP traffic".
- Section 3.8 "Application-Layer Protocol Negotiation" says that the TLS
must support - but nothing is said about the application layer actually
making use.
Implementing a defensive-only ALPN check (refusing a TLS startup, as
server, if anything but the obvious choice of "smtp" is offered as a
requested ALPN by the client) is not hard coding for either OpenSSL
or GnuTLS. Locking out retries with downgrade to cleartext would be
more effort, but perhaps not relevant as a defence against the ALPACA
attack.
In client MTA mode I'd expect the coding to make an ALPN request to
be similarly simple. Administrative controls for
non-use/offer/require-acceptance
would probably be more work than just the library interface.
--
Cheers,
Jeremy
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp