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

Benjamin Kaduk <kaduk@mit.edu> Wed, 14 October 2020 21:24 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 223053A10A0; Wed, 14 Oct 2020 14:24: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 QRa_VLoFprqE; Wed, 14 Oct 2020 14:24:43 -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 3808A3A109E; Wed, 14 Oct 2020 14:24:42 -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 09ELOTu9025792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Oct 2020 17:24:38 -0400
Date: Wed, 14 Oct 2020 14:24:28 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Achim Kraus <achimkraus@gmx.net>
Cc: 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: <20201014212428.GP50845@kduck.mit.edu>
References: <20201008233454.GF89563@kduck.mit.edu> <6185242d-8ba8-2d2f-5938-afad46c2e854@gmx.net> <20201009212240.GK89563@kduck.mit.edu> <fe7eab66-a14a-5f18-46be-7bae471c3b20@gmx.net> <CAOgPGoBWRyqQUNk3JQx2_Cna-7s-A7gENVwW-sh8+tRoJ_=V_Q@mail.gmail.com> <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <bab402e6-3353-d750-a849-21c91081f94e@gmx.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/T786-9sYnrAiANUnOYjW7LdtUkA>
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: Wed, 14 Oct 2020 21:24:45 -0000

On Tue, Oct 13, 2020 at 06:41:50AM +0200, Achim Kraus wrote:
> Hi Ben,
> 
> >
> >> Just as forecast:
> >> Without agreement, that the CIDs must be encoded using deterministic
> >> interpretation, which in my opinion obsoletes these "number games",
> >> next Summer either Raccoon or Kenny will write up their next
> >> "time side channel attack" on this.
> >> (The ambiguity will end up in try out the MAC for both "different
> >> MAC_write_key" and so create a time signal. Or with "same MAC_write_key"
> >> the receiver will not know by the failing MAC, which interpretation is
> >> the right. I guess, this will end up in decrypt twice, also obvious time
> >> signal.)
> >
> > Just to check my understanding: your forecast of an attack is predicated on
> > implementations that accept both potential MAC calculations proposed (CID
> > length before CID and CID length after CID)?  I do not think we should
> > allow things to progress to a state where accepting both forms is
> > encouraged, precisely because it leads to this sort of difficulty.   Hence,
> > my suggestion to assign a different extension codepoint, so an
> > implementation knows exactly which procedure to use.
> >
> 
> My concerns are based on permit ambiguous CIDs.

Ah, I think I understand better now (based on this and the rest of your
note).  I do not think we should allow such ambiguous CIDs, since (as you
note) they would require some "trial decryption" processing and the ensuing
time channels.  That said...

>  > 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>.
> 
> That results in my opinion in cid 01 and cid 01 01 being valid for the
> same peer and same time.

The attack does not require that both are valid for the same peer at the
same time -- the attack can still occur when the party producing the MAC is
induced to use the "wrong" (invalid CID) interpretation of the byte stream
but then the version with valid CID is presented to the party verifying the
MAC.  If the internal structure (including length encoding) of the CID is
opaque to the party producing the MAC, that party cannot validate the data
used as input to the MAC.

(Sorry for duplicating this previous paragraph here and on the github
issue.)

-Ben