[TLS] I-D Action: draft-ietf-tls-dtls13-43.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 Authors : Eric Rescorla Hannes Tschofenig Nagendra Modadugu Filename: draft-ietf-tls-dtls13-43.txt Pages : 71 Date: 2021-04-30 Abstract: This document specifies Version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is intentionally based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection/non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-tls-dtls13-43.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls13-43 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Uta] Recommending ALPN (was Re: [dns-privacy] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11 ...)
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: 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. --- 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 u...@ietf.org https://www.ietf.org/mailman/listinfo/uta OpenPGP_0x5AB2FAF17B172BEA.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Uta] Recommending ALPN (was Re: [dns-privacy] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11 ...)
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. --- 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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Uta] Recommending ALPN (was Re: [dns-privacy] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11 ...)
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 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. 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 > u...@ietf.org > https://www.ietf.org/mailman/listinfo/uta ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
