Re: [tsvwg] Secdir early review of draft-ietf-tsvwg-udp-options-22

Christian Huitema <> Sun, 23 July 2023 14:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E28D2C14CEE3 for <>; Sun, 23 Jul 2023 07:55:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nobKTs0QeEcn for <>; Sun, 23 Jul 2023 07:55:20 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 9003AC151087 for <>; Sun, 23 Jul 2023 07:55:20 -0700 (PDT)
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1qNaUO-000JuB-7i for; Sun, 23 Jul 2023 16:55:18 +0200
Received: from (unknown []) by (Postfix) with ESMTPS id 4R85tn4snXz9yW for <>; Sun, 23 Jul 2023 07:55:13 -0700 (PDT)
Received: from [] ( by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <>) id 1qNaUL-0002B9-HD for; Sun, 23 Jul 2023 07:55:13 -0700
Received: (qmail 10573 invoked from network); 23 Jul 2023 14:55:12 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 23 Jul 2023 14:55:12 -0000
Message-ID: <>
Date: Sun, 23 Jul 2023 07:55:11 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0
Content-Language: en-US
To: Paul Wouters <>,
References: <>
From: Christian Huitema <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Authentication-Results:; auth=pass smtp.auth=
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.12)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT+xL+QcqXhivin+QoGjk0eUPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5wK33BxCZ4Q1O8tWwOlQNPYfYzfQXcfqmra3dmoHS4ygjfQ 6TAc55j2OGmHM0XaHONWuRWrkPihq53YqAd1ENNqBHtNXu1E6L4+KyOXc4QYanQOD0r6/AaHZiEt dTMtMlia0Lmg/jgHfCNZd+W+PXf6KxaxVYenW4+hyv6jgmy/kyue9TLOhN8AYRsvkjfngQDFr0DQ oHMZQ1g48PBQ1bz5zDkBvlIN1pUDU5DU5DggD98cjIN3reG9z0FKKQ5m2Qpw7sOVVcM1Xk+Tdz6g /UMvfWqyN3veeFIMJz/vumcqAwMU9kjfE7EFo+kP5riIEUmxU01QhuxnshSbl6nxbLZ35/xY0uvo WBEOfzq3RG28wI7w4vcwqZanLHsZM8r4s5ZjlHoGly8aneNxj+pRyx6DFxVLaXQjMXzVZeSmCuLu +pFVgpT1b21uZVckGp0ccOZtuBWXiK6eoWgQZnNLL6SbpUc7peFeo3eDQNYbhOKhzzgqmaDn5SlD Y9mmtv6e91aWBLor1oCWetcUjeG94V2Xc+WWzCElmzUZ+qVv6OUmxsDmhhVHRQKAYIAbyu4+JAGy AkCY0FEXkytlTn97OL10EnFzsC48bTEFY06/YbB87Ww8G0LoS8V3Mt1pta8qAcLtCB3G1CwpaI3Z 4ESkMWDVJEenxBoIht3V0nekAoxXAkjdts3cjB5t7kO2QuWgbQeyuLfHqAnAj7rgKH7+eCmmHOyc SA1aV9O9NFUp+8bei1ShcA6Xvva2QAVEjpqzANZUmhRJvFbdO1XaKeBsEtPNrzY+oPLYuH1SQW1h 56zXTh0sl4OFxBT1d23OUWLVuGpBtL9ewJnoHKUNLZpf7DfZK/JdWvgd2/FibEdMM0Jnxu/VcARR JJg0CPVGXFYA7xCx7SWZBpdAUArn/St00aGa08t44IPL25P8DLNzMDIRDLdvK/cKOEqlCIPGIfYQ DNLcNVwigJ23suxKKQl6t4RW
Archived-At: <>
Subject: Re: [tsvwg] Secdir early review of draft-ietf-tsvwg-udp-options-22
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 23 Jul 2023 14:55:25 -0000

On 7/22/2023 11:57 AM, Paul Wouters via Datatracker wrote:
> I found no particular security concerns and the Security Considerations
> section covers the important parts, mostly regarding DoS protection.
> I suspect if any issues show up, it will be mostly transport related,
> eg "will this make it through all the internet hops".

I think there are in fact some important security considerations, which 
should have been outlined in the security review.

The proposed UDP options allow UDP packets to carry a set of clear text 
extensions. This may be par for the course if the application is not 
running its own encrypted protocol on top of UDP, but it is concerning 
if the application is using not UDP as a transport protocol but as a 
pass-through. The obvious example is applications running QUIC over UDP, 
but this is also the case with applications running on top of DTLS.

Having a cleartext segment in an otherwise encrypted packet obviously 
allows third parties to access the cleartext data. It also allows third 
parties to modify the data, unless the authentication options are used. 
Discussions in TSVWG showed for example that a third party could insert 
a Ping request to solicit a response and measure the end-to-end RTT 
through UDP relays -- the exact attack that caused very long discussions 
of the QUIC spin bit.

More generally, having a clear text segment in an otherwise encrypted 
packet significantly increase the attack surface of the application. 
Think for example of the Heartbleed attack, using a flaw in the 
implementation of the TLS Ping option in OpenSSL.

The security consideration option includes a segment discussing DTLS 
that I find very misleading. It starts with:

    UDP options are not covered by DTLS (datagram transport-layer
    security). Despite the name, neither TLS [RFC8446] (transport layer
    security, for TCP) nor DTLS [RFC9147] (TLS for UDP) protect the
    transport layer.

The argument appears grounded in a circular reasoning: UDP is the 
transport layer, DTLS does not protect UDP, hence DTLS does not protect 
the transport layer. However, many applications using DTLS do not use 
UDP as a transport layer in the classical "7 layer model" sense. They 
use it as a pass-through. For an application that uses SCTP over DTLS 
over UDP, SCTP is the transport, not DTLS, and DTLS in that case does 
indeed protect the transport. In that case, the UDP attack surface is 
best kept to a minimum.

The security section has a paragraph starting with "Note that any user 
application that considers UDP options to affect security need not 
enable them." I am concerned that this paragraph is not strong enough. I 
think that applications relying on an encrypted transport on top of UDP 
should be conscious of the additional attack surface and not enable UDP. 
This includes applications using QUIC, or applications running a 
transport like SCTP on top of DTLS.

-- Christian Huitema