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

Benjamin Kaduk <kaduk@mit.edu> Mon, 26 October 2020 16:56 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 EC95A3A0D32; Mon, 26 Oct 2020 09:56:45 -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 3Kyt9wkSO50P; Mon, 26 Oct 2020 09:56:44 -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 4809A3A0D2A; Mon, 26 Oct 2020 09:56:43 -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 09QGuaUE004870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 26 Oct 2020 12:56:40 -0400
Date: Mon, 26 Oct 2020 09:56:35 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Achim Kraus <achimkraus@gmx.net>
Cc: "tls@ietf.org" <tls@ietf.org>, draft-ietf-tls-dtls-connection-id@ietf.org
Message-ID: <20201026165635.GQ39170@kduck.mit.edu>
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> <082806e2-5ff2-61d3-e181-31e50daef7f2@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <082806e2-5ff2-61d3-e181-31e50daef7f2@gmx.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/126uei_hlCm3gwW6yPEspxONBDk>
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: Mon, 26 Oct 2020 16:56:46 -0000

Hi Achim,

On Sat, Oct 24, 2020 at 08:56:08AM +0200, Achim Kraus wrote:
> Hi Ben,
> 
> >>     Because each party sends the value in the "connection_id" extension
> >>     it wants to receive as a CID in encrypted records, it is possible for
> >>     an endpoint to use a globally constant length for such connection
> >>     identifiers.  This can in turn ease parsing and connection lookup,
> >>     for example by having the length in question be a compile-time
> >>     constant.  Implementations, which want to use variable-length CIDs,
> >>     are responsible for constructing the CID in such a way that its
> >>     length can be determined on reception.  Such implementations must
> >>     still be able to send CIDs of different length to other parties.
> >>     Note that there is no CID length information included in the record
> >>     itself.
> >
> > ...and thanks for the reminder about how we say so in the text already.
> 
> (your example from a previous e-mail)
> 
>  > Attempting to construct a trivial example on the fly, (hex)
> 
>  > 01 01 02 02 01 <513 bytes of plaintext content>
> 
>  > could be cid_length=1, cid=0x01, length_of_DTLSInnerPlaintext=0x0202,
>  > DTLSInnerPlaintext.content = 0x01 <513 bytes>, or it could be
>  > cid_length=2, cis=0x0101, length_of_DTLSInnerPlaintext=0x0201,
>  > DTLSInnerPlaintext.content = <513 bytes>.
> 
> I would feel much more comfortable, if you state,
> that you consider now either
> 
> 1. that example was not compliant to the draft,
> 
> or
> 
> 2. the draft is not clear enough about that.
> 
> If 1. is true, https://github.com/tlswg/dtls-conn-id/issues/76 could be
> closed.

It is neither of those two.

While the party that will be parsing packets that use a given CID value to
identify the connection needs to be able to determine the length from the
byte stream, the other party does not.  Accordingly, when computing the
MAC, there is still malleability in terms of which "interpretation" of the
byte stream was intended by the party computing the MAC.  The party
receiving the packet (and MAC) will only use one interpretation, but the
party generating the MAC could have been deceived into using the other
interpretation.

As I said previously, the CID values are not authenticated until the
handshake completes, so there is a real window where this attack surface is
exposed.  Note that I do not need to present a complete end-to-end attack
that breaks the TLS guarantees in order for us to change the spec -- it is
enough to have shown that the malleability of the cryptographic input
stream is exposed to potential attack.  To leave such behavior in a
published protocol spec would be irresponsible, in effect, publishing an
algorithm with known weaknesses.

Thanks,

Ben