Re: ALPN: implementation / behaviour

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.