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

Benjamin Kaduk <kaduk@mit.edu> Tue, 27 October 2020 01:12 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 4A0A03A115D; Mon, 26 Oct 2020 18:12:35 -0700 (PDT)
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 dCOyLC7FJMAU; Mon, 26 Oct 2020 18:12:33 -0700 (PDT)
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 973F73A115A; Mon, 26 Oct 2020 18:12:33 -0700 (PDT)
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 09R1COoT017494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 26 Oct 2020 21:12:28 -0400
Date: Mon, 26 Oct 2020 18:12:23 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Eric Rescorla <ekr@rtfm.com>
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
Message-ID: <20201027011223.GH39170@kduck.mit.edu>
References: <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> <CABcZeBOQxpWMSuJiiXDB0Cf62iNU+hU8Wpd_Pd_1HOgXJYc0Kg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABcZeBOQxpWMSuJiiXDB0Cf62iNU+hU8Wpd_Pd_1HOgXJYc0Kg@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/xr_rPLXJOxx_4wUi5mF38i-oM2k>
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:12:35 -0000

On Mon, Oct 26, 2020 at 06:07:07PM -0700, Eric Rescorla wrote:
> 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;            /
> };

Sounds good.

> 
> 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...

Yeah, I was not super happy with that one as I wrote it (hence my comment
about it), but I also wasn't around when 7366 was being written, so I don't
have much else to draw on.

-Ben