[tsvwg] Regarding DTLS and UDP options

Joe Touch <touch@isi.edu> Fri, 14 April 2017 23:57 UTC

Return-Path: <touch@isi.edu>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBEA129B1E for <tsvwg@ietfa.amsl.com>; Fri, 14 Apr 2017 16:57:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.002
X-Spam-Level:
X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huAs0ein-6F6 for <tsvwg@ietfa.amsl.com>; Fri, 14 Apr 2017 16:57:16 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EEE812702E for <tsvwg@ietf.org>; Fri, 14 Apr 2017 16:57:16 -0700 (PDT)
Received: from [128.9.184.165] ([128.9.184.165]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3ENufZ7020161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 14 Apr 2017 16:56:42 -0700 (PDT)
References: <CACL_3VFeJs7KzG9Bchh15bfZ3CmaOPWcfisEreNoGYK5CsEJ+g@mail.gmail.com> <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> <CACL_3VFkr3mGe-yTbvHrTZcKVCpEv3FeSOyoShUxCK5+9Tdqqg@mail.gmail.com> <c79fe3d0-8567-ea7d-72fc-bd33732df60e@isi.edu> <CACL_3VHmoCSo23OWqQFq7upw749CqMK7iazXrBKZARzwbzY5mw@mail.gmail.com> <f97f08d4-0070-437a-e22a-8782497c76eb@isi.edu>
To: tsvwg <tsvwg@ietf.org>
From: Joe Touch <touch@isi.edu>
Message-ID: <4e36af95-84c3-bc7e-b18a-614f8bfab662@isi.edu>
Date: Fri, 14 Apr 2017 16:56:41 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <f97f08d4-0070-437a-e22a-8782497c76eb@isi.edu>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/iE73VrkeInnlo687NuUKI8cfJsg>
Subject: [tsvwg] Regarding DTLS and UDP options
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Apr 2017 23:57:17 -0000

Hi, all,

Christian Huitema a question about the interaction between DTLS and UDP
options during my remote presentation at IETF 98.

I took a closer look and consulted with Eric Rescorla (DTLS author). He
and I agreed as follows:
- DTLS would currently not cover UDP options; DTLS protects only the UDP
payload
- the situation is analogous to TCP options, which are not covered by TLS
I.e., both TLS and DTLS are transport *payload* security only, despite
their names.

Christian noted that this may be a reason QUIC prefers UDP (to avoid the
need to protection transport options), however QUIC does not (and
cannot) deprecate UDP payloads that are smaller than the IP payload.
That would require a change to RFC 768.

I'll add a clarification on this point to the next rev of the UDP
options document.

Joe