Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

Benjamin Kaduk <kaduk@mit.edu> Tue, 17 November 2020 09:16 UTC

Return-Path: <kaduk@mit.edu>
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 A87953A0BC4; Tue, 17 Nov 2020 01:16:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 5NGjihThxDfz; Tue, 17 Nov 2020 01:16:11 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C19313A0BAD; Tue, 17 Nov 2020 01:16:10 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0AH9G1G9020244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Nov 2020 04:16:05 -0500
Date: Tue, 17 Nov 2020 01:16:00 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Achim Kraus <achimkraus@gmx.net>
Cc: Eric Rescorla <ekr@rtfm.com>, Watson Ladd <watsonbladd@gmail.com>, Joseph Salowey <joe@salowey.net>, "tls@ietf.org" <tls@ietf.org>, draft-ietf-tls-dtls-connection-id@ietf.org
Message-ID: <20201117091600.GN39170@kduck.mit.edu>
References: <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> <CABcZeBOQxpWMSuJiiXDB0Cf62iNU+hU8Wpd_Pd_1HOgXJYc0Kg@mail.gmail.com> <3e55d1fe-62b2-c62e-a085-032ecb43addb@gmx.net> <20201117060745.GI39170@kduck.mit.edu> <0579646f-f468-8bed-67c6-951239aa972b@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <0579646f-f468-8bed-67c6-951239aa972b@gmx.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/NXFLGBteLgJdI0SsYBtUuT4reeA>
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, 17 Nov 2020 09:16:13 -0000

On Tue, Nov 17, 2020 at 10:09:34AM +0100, Achim Kraus wrote:
> Hi Ben,
> 
> Am 17.11.20 um 07:07 schrieb Benjamin Kaduk:
> > On Fri, Oct 30, 2020 at 01:28:12PM +0100, Achim Kraus wrote:
> >> Hi Ekr,
> >>
> >>> 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];
> >>> };
> >>>
> >>
> >> I failed to understand the reasons behind this proposal.
> >>
> >> 1. Why should the "marker" be added, if the "content_type" is already in
> >> the MAC, and this special MAC is only applied for tls12_cid records.
> >> What is the intended benefit of that?
> >
> > This is another general hygiene item; we are preserving the invariant that
> > the first byte of the MAC input is the content type -- this is at present
> > (IIRC) invariant across all TLS versions and MtE/EtM, and not something to
> > change lightly.
> 
> "All TLS versions"?

Apparently I did not remember correctly.

Sorry about that.

-Ben