Subject: [Uta] Recommending ALPN (was Re: [TLS] [dns-privacy] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11 ...)

From: "Martin Thomson" <[email-masked]>
Date: Fri, 30 Apr 2021 10:05:48 +1000

(dprive to bcc, because this is getting further afield)

On Fri, Apr 30, 2021, at 00:26, Salz, Rich wrote:
> >    No new protocol should use TLS without ALPN.  It only opens space for cross-protocol attacks.  Did the working group consider this possibility in their discussions?
> 
> I don't believe that message has been made as public as it should be.

I see that UTA is working on a revision of RFC 7525.  Is text on this something that would be in scope.  I only just searched for "ALPN", finding nothing, so maybe it is not in the original scope and maybe there are things that might prevent expansion of scope.

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 30 Apr 2021 09:25:39 +0300

Hi Martin,

> > >    No new protocol should use TLS without ALPN.  It only opens space for cross-protocol attacks.  Did the
> working group consider this possibility in their discussions?
> >
> I see that UTA is working on a revision of RFC 7525.  Is text on this something that would be in scope.  I only
> just searched for "ALPN", finding nothing, so maybe it is not in the original scope and maybe there are things
> that might prevent expansion of scope.

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.

Regards,
Valery.

> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 30 Apr 2021 16:46:05 +1000

> However, I believe that recommendations for using ALPN are in scope of 

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.
---

This last bit might be an update to RFC 7301, but it's important for protecting against cross-protocol attacks on clients that support protocols with ALPN identifiers where the use of ALPN is not guaranteed.

---

From: Hubert Kario <[email-masked]>
Date: Fri, 30 Apr 2021 12:38:13 +0200

On Friday, 30 April 2021 08:46:05 CEST, Martin Thomson wrote:
> 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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 30 Apr 2021 12:42:56 +0100

Hiya,

I like the text below as a starter. I'd suggest it also
include something to take into account the ECH issue
mentioned on the dpriv list [1]

S

[1] 
https://mailarchive.ietf.org/arch/msg/dns-privacy/3xL59_1P0ZHOUEYsDJ1Q22ZZVvo/

On 30/04/2021 07:46, Martin Thomson 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.
> 
> --- 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. ---
> 
> This last bit might be an update to RFC 7301, but it's important for
> protecting against cross-protocol attacks on clients that support
> protocols with ALPN identifiers where the use of ALPN is not
> guaranteed.
> 
> _______________________________________________ Uta mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/uta
>