Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07
Eric Rescorla <ekr@rtfm.com> Tue, 27 October 2020 01:07 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 9B3793A1149 for <tls@ietfa.amsl.com>; Mon, 26 Oct 2020 18:07:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 S61kkSv0LxtS for <tls@ietfa.amsl.com>; Mon, 26 Oct 2020 18:07:45 -0700 (PDT)
Received: from mail-lf1-x142.google.com (mail-lf1-x142.google.com [IPv6:2a00:1450:4864:20::142]) (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 62FD93A1147 for <tls@ietf.org>; Mon, 26 Oct 2020 18:07:45 -0700 (PDT)
Received: by mail-lf1-x142.google.com with SMTP id a7so15013740lfk.9 for <tls@ietf.org>; Mon, 26 Oct 2020 18:07:45 -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=eOSuJlatdvumhqmK/PEN1CXQLqOhiP9y6Fo0+WIFA+c=; b=b8Y9iJwRH0hlqfpxciw2aWHJCfBsgcVoSWEB9034qPBb/NqNzJzzX1G23v+LtuMeBJ dUozJKKXLUdmlAclGi4enlIBdhIZBxPw8hg6ynzU2UVXCjcZZ3dWknXR7ONR3tcu90vV QrsP/VF7kH3EVzo+BZskUDiX3bL6D+uxkh9IwKJWUEKLlNyu0mY8/JvRWw0o4CixYwZE WeTooAXF/JPtNvPmIxO8NabUIej7bRvuJWJozBLXiuC3doDsyOFwJrvN1V2I07+WSWX8 4F6sb/8rCS7B3uqwBJ7Cl6uK/irAfbXjcRehzH9opnnR8mCERKqHVXiq3Nshefi9++pu WP8w==
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=eOSuJlatdvumhqmK/PEN1CXQLqOhiP9y6Fo0+WIFA+c=; b=l/PxCS4EAZwP+QxZLbdxyWR6A/f54raZ/ETTKBWIAGnfgGxUty89zcvrlWIN4uVQB/ tUyTS27Hn9WGX8G6TSjMb/8SbRjHGTmN+QFgNGI4bPPSdtNhzIL0Zn/i+Nebk/RRf58F HxraQG5S0+P7ikrG/gZz8+SQeq4tFXKMesisMfspvrcAwQHgBmMppCZMGJ/V/R+nIYX8 /VsyTwmD/KcBeLC4nzX64ZJZ6RgLaPa4bKM5mnsu7eyX+jC9GJGK8IjJY0YNGEXctZFz OnD7sVLDJSJziF0wH+dLOaCDufa9laMCvWQAfEp49b9zyFs3AOQRVXX8fkJd4F6K8CUl 6TxA==
X-Gm-Message-State: AOAM531BIfxPxBQ0SYo2r3vkVeDvTCr1ysYJ0aqmYcCoUYbMxtpOMway 9X4U/n1NJex7m7t/406LxH0+jTUrnJYx+FBvYW4UZw==
X-Google-Smtp-Source: ABdhPJzVIwSBlLSVEYNiBircwzzF9S1I7GKyRTeo0OLglemYPW0flcasqoq2ZqM3V3n5g2J9YC8S7yY90HejSxUn1z8=
X-Received: by 2002:ac2:4aca:: with SMTP id m10mr6126155lfp.26.1603760863629; Mon, 26 Oct 2020 18:07:43 -0700 (PDT)
MIME-Version: 1.0
References: <13a821d3-30cc-94b8-842c-22a87d280f09@gmx.net> <CACsn0cn4QcnaoocQeoiUXgGoAvfOs+1+Ei76z1Kuq8MMqNEh3Q@mail.gmail.com> <0327abb0-6317-b848-28d0-1fc50f4bf50e@gmx.net> <20201012200548.GD1212@kduck.mit.edu> <bab402e6-3353-d750-a849-21c91081f94e@gmx.net> <20201014212428.GP50845@kduck.mit.edu> <a7110178-6220-175e-869d-fcc44400f773@gmx.net> <CABcZeBNocUYZO9yxuG-DYh33ss+Dum1EOxHYEdww5OCR=rKFXw@mail.gmail.com> <20201024021316.GN39170@kduck.mit.edu> <CABcZeBPP_PFWtaNB4Wr+2MoY2+8Mh1Vxt9A-Hp5LaCg9DiLCFw@mail.gmail.com> <20201027010029.GG39170@kduck.mit.edu>
In-Reply-To: <20201027010029.GG39170@kduck.mit.edu>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 26 Oct 2020 18:07:07 -0700
Message-ID: <CABcZeBOQxpWMSuJiiXDB0Cf62iNU+hU8Wpd_Pd_1HOgXJYc0Kg@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Achim Kraus <achimkraus@gmx.net>, Watson Ladd <watsonbladd@gmail.com>, Joseph Salowey <joe@salowey.net>, "tls@ietf.org" <tls@ietf.org>, draft-ietf-tls-dtls-connection-id@ietf.org
Content-Type: multipart/alternative; boundary="00000000000094e5fb05b29cac3e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/_cJ9IMA-enGZY9wwPYd1DMlU_V0>
Subject: Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07
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, 27 Oct 2020 01:07:48 -0000
On Mon, Oct 26, 2020 at 6:00 PM Benjamin Kaduk <kaduk@mit.edu> wrote: > On Mon, Oct 26, 2020 at 05:38:33PM -0700, Eric Rescorla wrote: > > On Fri, Oct 23, 2020 at 7:13 PM Benjamin Kaduk <kaduk@mit.edu> wrote: > > > > > Hi Ekr, > > > > > > Thanks for chiming in. > > > > > > On Thu, Oct 15, 2020 at 08:59:43AM -0700, Eric Rescorla wrote: > > > > > > > > - I agree with Ben that the current construction has some awkward > > > > properties and that prefixing the length field would remedy that. > It's > > > > been quite some time since we had this discussion but as I recall the > > > > rationale was to protect the bits on the wire as-is rather than some > > > > reconstructed version of them (see a number of long discussions on > > > > this topic), so just prefixing the CID length is also not ideal. > > > > > > I think the current scheme is unfortunately using fields put together > in a > > > rather different order than the actual bits on the wire (more below). > > > > > > > Right. I forgot that we also preserved the TLS order of the seqnum. > > > > > > > > > > > > This is a little goofy but it has (I think) the properties that (1) > the > > > > bytes appear > > > > in the MAC in the order they appear on the wire (2) fixed-length > metadata > > > > appears in > > > > the front (the seq_num already does) (3) the duplicated tls12_cid in > the > > > > front avoids confusion with MAC input for other records. > > > > > > I like (1) and (2) and agree with (3), though I'm having a little > trouble > > > lining up your figure with the DTLSCiphertext structure, which I'll > repeat > > > here so I'm not flipping back and forth as much: > > > > > > struct { > > > ContentType special_type = tls12_cid; > > > ProtocolVersion version; > > > uint16 epoch; > > > uint48 sequence_number; > > > opaque cid[cid_length]; // New field > > > uint16 length; > > > opaque enc_content[DTLSCiphertext.length]; > > > } DTLSCiphertext; > > > > > > Ah, your proposal looks more natural if I compare it to the current > AEAD > > > "additional_data" from the -07: > > > > > > # additional_data = seq_num + > > > # tls12_cid + > > > # DTLSCipherText.version + > > > # cid + > > > # cid_length + > > > # length_of_DTLSInnerPlaintext; > > > > > > If I could try to synthesize your key points (as I understand them), > hewing > > > more strictly to the "bits on the wire" philosophy would suggest > having us > > > use: > > > > > > additional_data: > > > struct { > > > uint8 marker = tls12_cid; > > > uint8 cid_len; > > > uint8 content_type = tls12_cid; \ > > > uint16 DTLSCiphertext.version; | appears on wire > > > uint64 seq_num; // includes epoch | > > > opaque cid[cid_len]; / > > > uint16 length_of_DTLSInnerPlaintext; > > > }; > > > > > > > > Mostly. > > > > I would expect the length here to not be DTLSInnerPlaintext but rather > the > > length field that appears on the wire, as in TLS 1.3. Do you agree with > > that? If not, let's discuss. If so, we can talk about the others. > > Good catch, the length on the wire makes more sense. (I presume I just > cribbed from the -07 here and didn't think hard enough. > So I think that the following is right for MtE. struct { uint8 marker = tls12_cid; uint8 cid_len; uint8 content_type = tls12_cid; \ uint16 DTLSCiphertext.version; | appears on wire uint64 seq_num; // includes epoch | opaque cid[cid_len]; / uint16 length_of_DTLSInnerPlaintext; DTLSInnerPlaintext.content; \ DTLSInnerPlaintext.real_type; | entirety of DTLSInnerPlaintext DTLSInnerPlaintext.zeros; / }; As for EtM Encrypt-then-MAC: struct { uint8 marker = tls12_cid; uint8 cid_len; uint8 content_type = tls12_cid; \ uint16 DTLSCiphertext.version; | appears on wire uint64 seq_num; // includes epoch | opaque cid[cid_len]; / uint16 iv_length; opaque IV[iv_length]; uint16 enc_content_length; opaque enc_content[enc_content_length]; }; This seems kind of unfortunate in that the 7366 version is much more faithful to the wire, so I still have to think about this one some more, I think... -Ekr
- [TLS] AD review of draft-ietf-tls-dtls-connection… Benjamin Kaduk
- Re: [TLS] AD review of draft-ietf-tls-dtls-connec… Achim Kraus
- Re: [TLS] AD review of draft-ietf-tls-dtls-connec… Benjamin Kaduk
- Re: [TLS] AD review of draft-ietf-tls-dtls-connec… Achim Kraus
- Re: [TLS] AD review of draft-ietf-tls-dtls-connec… Achim Kraus
- [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-c… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Benjamin Kaduk
- Re: [TLS] AD review of draft-ietf-tls-dtls-connec… Benjamin Kaduk
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] AD review of draft-ietf-tls-dtls-connec… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Benjamin Kaduk
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Michael D'Errico
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Joseph Salowey
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Watson Ladd
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Ilari Liusvaara
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… antoine
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… antoine
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Michael D'Errico
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Benjamin Kaduk
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Benjamin Kaduk
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Benjamin Kaduk
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Benjamin Kaduk
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Benjamin Kaduk
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Eric Rescorla
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Benjamin Kaduk
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Benjamin Kaduk
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Eric Rescorla
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Benjamin Kaduk
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Eric Rescorla
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Benjamin Kaduk
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Peter Gutmann
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Benjamin Kaduk
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Benjamin Kaduk
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Eric Rescorla