On Thu, Jul 08, 2021, Jeremy Harris wrote:
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.
It seems there are the following possible cases to handle:
1. the other side did not offer/specify ALPN.
2. the other side did offer/specify ALPN and there is
2.1 a match
2.2 no match
but there is no way to determine case 1 for the client. At least
that's what I found out when I implemented it in my MTA.
The ALPACA authors have this recommendation:
ALPN for Clients
We also recommend that the client aborts the handshake if the server
acknowledges the ALPN extension, but does not select a protocol
from the client list.
AFAICT it's no possible to implement this with ALPN. I suggested a
possible solution on the ietf-tls list but there was no interest
in it.
Hopefully someone who understand this topic better can explain
what needs to be done?
--
Address is valid for this mailing list only, please do not reply
to it direcly, but to the list.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp