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

Benjamin Kaduk <kaduk@mit.edu> Tue, 17 November 2020 06:07 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 D19603A0F09; Mon, 16 Nov 2020 22:07:57 -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 RJAydjwWzCfB; Mon, 16 Nov 2020 22:07:56 -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 BD0E73A0F0C; Mon, 16 Nov 2020 22:07:55 -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 0AH67jwi006506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Nov 2020 01:07:50 -0500
Date: Mon, 16 Nov 2020 22:07:45 -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: <20201117060745.GI39170@kduck.mit.edu>
References: <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> <CABcZeBOQxpWMSuJiiXDB0Cf62iNU+hU8Wpd_Pd_1HOgXJYc0Kg@mail.gmail.com> <3e55d1fe-62b2-c62e-a085-032ecb43addb@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3e55d1fe-62b2-c62e-a085-032ecb43addb@gmx.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/sozQxlyE3_WjGcHxnRPk57vN_A8>
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 06:07:58 -0000

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.

It appears twice so that we keep the entire "bits on wire" together, and
there's not (IMO) much incentive to try to justify deduplicating the two
locations of tls12_cid, since the incremental cost of MACing another byte
is pretty small.

> 2. Why should a "uint16 iv_length" be added?
> 2.a If it should be added, why as "uint16" instead of "uint8"
> 2.b If it should be added, why in the middle? It's not on the wire and
> so I would assume, if at all, to have that at the begin.

(Peter answered the "why have it at all" question.)

I think you are right that putting it before the "appears on wire" bits
makes a bit more sense.

I think it was uint16 out of chance/laziness, as I split the combined
"length of (IV + DTLSCiphertext.enc_content)" and just used the same width
of length field for both IV and enc_content.  Making it uint8 is probably
an improvement.

Thanks for taking a careful look,

Ben