Re: [TLS] DTLS 1.3 AEAD additional data

Eric Rescorla <ekr@rtfm.com> Tue, 21 April 2020 18:00 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E313A08E5 for <tls@ietfa.amsl.com>; Tue, 21 Apr 2020 11:00:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 aXgJq_mHAxmE for <tls@ietfa.amsl.com>; Tue, 21 Apr 2020 10:59:58 -0700 (PDT)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 0E9DF3A08E8 for <tls@ietf.org>; Tue, 21 Apr 2020 10:59:57 -0700 (PDT)
Received: by mail-lj1-x235.google.com with SMTP id g4so6830022ljl.2 for <tls@ietf.org>; Tue, 21 Apr 2020 10:59:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WsFU9ez6pjq/kOzyVrl3fcHmzX31rQ8JqxUDmfVO5Hc=; b=pS9ZEPQJfspYxnhjCSKJS1RNO6FnPjJ7lDtOQbEga3cVhESDtePUKxGB2WblxBDjcz AAI/l9xLA5ua3td7eVHePgolMcZEngDu2+AHpTMbVFmA5C66KpEQZb7+If7/2tlgFtc4 gyL+1Dc/Yiblls0IlbZ0kB2XQfmkQiJP6bFwW2jAFANp5yEWMpXKnoSgIfdUucC2Hflc v+mU3pUE7ZtI+Bj+nJ8tZf4u7GrXs5MZExLi3jerW4hgp2yD2LHe5VQfxwXSwOAblC1c eN7E18ZTLl9xh3IboEzzvECe4bh0dNw323hokxpGN3xCFCHNJD/vE+3TiKX0GPj5CaDk Pmbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WsFU9ez6pjq/kOzyVrl3fcHmzX31rQ8JqxUDmfVO5Hc=; b=bq5iwZLlEw52QGJCBZ8aAox6/AfUdadGzx9Et4vC8Xmdaj+zT3YbXQ9o+E2aP7W6WT eeSIO346Ty6FDJPbfQp6WvwpnMl+ccdqV5uxltPalO1izXs0r/Da1Di3RTIsgOYXsYIJ jWaB/SOVb5Yn5iWmaGwiJzE99hr6y85HVijL8EH+stxp//0ObxaupRNN5baNek60N6PS Gv7LMSn1trSUtG3G2IGNyMW7MaUWxJXqtVD9+vbWdlfKEt0v7xQRxGv6vnlBa3ku6NCx Vzrsfyb2TfcmKn5FAta3wQ3rO/DrJqx4/o3qszeEBVVYzbnq/GE4I1KeSTcPl9sBXX54 82Rg==
X-Gm-Message-State: AGi0PuYog7i+ITbRikqoQGlLuOW+QvoDEG1cY/GU9c4OvEdcDGd2/lD7 gvp5P7lflkTDUJUBWVQMaDAogPbmmlGoXYJVkQ8m8A==
X-Google-Smtp-Source: APiQypLz03ZqnVkmPcXBUYFNkKp2ndYtWDHw6PYAVqnI6k81SAV7Mv/st0pUU3PWDMNo2sFw/gDJsA9c5lwchZwR/mw=
X-Received: by 2002:a2e:b0ee:: with SMTP id h14mr14497677ljl.35.1587491992800; Tue, 21 Apr 2020 10:59:52 -0700 (PDT)
MIME-Version: 1.0
References: <AM6PR08MB3318911C71C0DDB90480694A9BD50@AM6PR08MB3318.eurprd08.prod.outlook.com>
In-Reply-To: <AM6PR08MB3318911C71C0DDB90480694A9BD50@AM6PR08MB3318.eurprd08.prod.outlook.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 21 Apr 2020 10:59:16 -0700
Message-ID: <CABcZeBMs+o4BU5VhqJKmQvnkEe9RkQXRv7Ej6pVD1-e1vdMoyA@mail.gmail.com>
To: Hanno Becker <Hanno.Becker@arm.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000050a90305a3d0c869"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/9LGn7PvFgLOGEG7IrwJM1Sw2gdE>
Subject: Re: [TLS] DTLS 1.3 AEAD additional data
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Apr 2020 18:00:01 -0000

On Tue, Apr 21, 2020 at 8:39 AM Hanno Becker <Hanno.Becker@arm.com> wrote:

> Hi all,
>
> To my understanding, DTLS 1.3 defines AEAD additional data for record
> protection
> as the record header as seen on the wire. Quoting Draft 37, Section 4:
>
> ```
>    The entire header value shown in Figure 4 (but prior to record number
>    encryption) is used as as the additional data value for the AEAD
>    function.  For instance, if the minimal variant is used, the AAD is 2
>    octets long.  Note that this design is different from the additional
>    data calculation for DTLS 1.2 and for DTLS 1.2 with Connection ID.
> ```
>
> I would like to suggest that DTLS 1.3 uses a structured representation
> of the record header instead, as do all other versions of [D]TLS as
> far as I understand.
>

I am not in favor of this change as proposed. I think it is better to
protect the data that is actually on the wire than to allow for changes in
the on-the-wire representation that are not reflected in the integrity
check.


The reasons for this are as follows, in decreasing order of
> my perception of importance:
>
> - Omission of Connection ID
>
>   Regarding the presence of Connection IDs in multiple records within
>   a single datagram, Draft 37 says:
>
> ```
>    Implementations which send multiple records in the same datagram
>    SHOULD omit the connection id from all but the first record;
>    receiving implementations MUST assume that any subsequent records
>    without connection IDs belong to the same assocatiation.
> ```
>
>   This means that the Connection ID for non-initial records in a
>   datagram containing multiple records is _not_ part of the AEAD
>   additional data for those records, which seems wrong. Concretely,
>   one could inject such non-initial records into other datagrams
>   using different CIDs, and the record protection wouldn't notice it.
>

This seems like a reasonable point, though it's not clear to me that there
is an actual problem here. I'd be in favor of explicitly including the CID
in the AD as well as the header.

>
>
>   One might argue that CID shouldn't be part of the AEAD in the first
>   place, but in any case, I believe the treatment should be uniform
>   and not distinguish between initial and non-initial records in
>   a datagram.
>

We're not distinguishing it. The AD is protecting the record on the wire.


- Modularity
>
>   Decoupling the wire-presentation of the record header from
>   record protection allows to implement record protection and
>   the choice of record header independently: One piece of
>   the implementation can take care of record protection -
>   using the structured presentation of the record header - while
>   another takes care of the wire-encoding. It is even possible
>   to change the record header format in transit.
>

This seems like a defect, not a feature.


- Simplicity
>
>   At first it seems that using the record header as an
>   unstructured binary blob for AEAD makes things simpler,
>   but I don't think this is the case: Prior to record
>   decryption, the record sequence number needs to be
>   decrypted, and for that purpose, the record header already
>   has to be parsed. Hence, at the time of record decryption,
>   the record header is already be present a modified, structured
>   form, and retaining the corresponding modified binary form
>   appears to create additional complexity which would be
>   avoided if record protection would use the structured
>   header presentation.
>

I've implemented this for QUIC (I can't remember who at Mozilla did it for
DTLS) and it's not particularly difficult.


- Uniformity with other [D]TLS versions
>

I don't find this argument at all persuasive. To the contrary: we should
break with  DTLS 1.2 in any case where it's an improvement and not too
onerous.

-Ekr


>
>
> Let me know what you think,
>
> Best,
> Hanno
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>