On Friday, 30 April 2021 08:46:05 CEST, Martin Thomson wrote:
On Fri, Apr 30, 2021, at 16:25, Valery Smyslov wrote:
The original motivation for 7525bis was to update RFC 7525 in light of
TLS 1.3 appearance.
However, I believe that recommendations for using ALPN are in scope of
this document.
How about a new Section 3.7 "Application-Layer Protocol Negotiation":
---
TLS implementations MUST support the Application-Layer Protocol
Negotiation (ALPN) extension [RFC7301]. Correct use of ALPN
ensures that clients and servers agree on a negotiated protocol.
Newly defined application protocols that use TLS MUST define an
ALPN identifier and mandate the use of ALPN for negotiating the
protocol.
An existing application protocol might not have been assigned
an ALPN identifier. For other protocols the ALPN identifier
might not have been part of the original protocol definition, or
use of ALPN might have been defined originally as being
optional. In all of these cases, implementations cannot require
the use of ALPN. A server implementation MUST fail a connection
attempt with a fatal "no_application_protocol" alert if it is
configured to use a protocol that has no assigned ALPN
identifier and a client offers an
"application_layer_protocol_negotiation" extension.
---
that reads to me like a recipie for future interoperability issues
sure, if the protocol doesn't have an ALPN ID assigned now, requiring
no ALPN use is ok, but if that protocol gains an ALPN ID, the connections
from a client that knows about this ALPN ID will fail to all of the old
servers
that's Bad, as it means that those protocols can't ever get an ALPN ID
assigned
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
