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

Ilari Liusvaara <ilariliusvaara@welho.com> Sun, 11 October 2020 07:51 UTC

Return-Path: <ilariliusvaara@welho.com>
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 921C63A0F6A for <tls@ietfa.amsl.com>; Sun, 11 Oct 2020 00:51:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.624
X-Spam-Level:
X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.274, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 qD16XgzC2Pt7 for <tls@ietfa.amsl.com>; Sun, 11 Oct 2020 00:51:07 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2b.welho.com [83.102.41.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55D093A0F69 for <tls@ietf.org>; Sun, 11 Oct 2020 00:51:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id EE024D00F3; Sun, 11 Oct 2020 10:51:04 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id RNLWUFz5bXQD; Sun, 11 Oct 2020 10:51:04 +0300 (EEST)
Received: from LK-Perkele-VII (87-92-140-94.rev.dnainternet.fi [87.92.140.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 5DA2A72; Sun, 11 Oct 2020 10:51:02 +0300 (EEST)
Date: Sun, 11 Oct 2020 10:51:00 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Achim Kraus <achimkraus@gmx.net>
Cc: "tls@ietf.org" <tls@ietf.org>
Message-ID: <20201011075100.GA2518649@LK-Perkele-VII>
References: <0da9b525-ec78-bef5-6ceb-5f377019ade4@gmx.net> <4ca7c2f9-1e9d-0d16-0089-649f013b4565@gmx.net> <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <13a821d3-30cc-94b8-842c-22a87d280f09@gmx.net>
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/wyC3GPLmbB0TLYHpJqFJX3MUJMQ>
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: Sun, 11 Oct 2020 07:51:10 -0000

On Sun, Oct 11, 2020 at 08:26:47AM +0200, Achim Kraus wrote:
> Hi Joe,
> 
> > [Joe]  It's unfortunate to find issues that require breaking change at
> > the end of the review cycle, especially for a draft that has taken a
> > long path to get here.   If there is an issue that is exploitable, even
> > in a corner case, someone will develop an attack, clever name, logo and
> > website and we will all have to scramble to deploy a fix.   It's better
> > to fix now rather than later.
> 
> Agreed, therefore I wrote at the begin of the discussion with Ben:
> 
> >> I would prefer, if this is not changed again without strong
> >> arguments!
> 
> > In this case, I don't have a way to
> > exploit this issue, but unless someone has a way to demonstrate that
> > this is not going to be an issue then I believe it is prudent to fix it
> > now.
> >
> 
> In my opinion, ONE change may be possible. A server may be configured to
> use only the old, only the new, or both by "try on the client's finish".
> I'm not happy with such "dirty" work-around. I would prefer to do so for
> something more the "cryptographic hygiene".
> 
> So, if the MAC is considered to be adpated again, should it not be
> discussed, why at all the cid-length should be put in?
> I asked this already in January 2019
> 
> https://github.com/tlswg/dtls-conn-id/pull/29#discussion_r246654915
> 
> The MAC contains already a overall length. Even in that discussion, no
> one mentioned the reason for adding it. So if there a doubts about
> injection, why not remove it at all?

The problem is the follows:

Take the following input to the MAC (MtE case):

<seqnum> 19 FE FD 63 01 00 05 04 00 02 FF 17

There is no way to tell from that input if it is:

- Application record on CID 63 containing 04 00 02 FF, or
- Application record on CID 63 01 00 05 containing FF.

The overall MAC length will not catch this, because the overall length
is the same in both cases.

And even if it seems that the data lengths after depad should be
different, it is unsafe to rely on depad length.


Stripping the CID length will not solve the issue. Heck, if cid length
is removed, the very above example is still ambiguous, now for:

- Application record on CID 63 01 containing 04 00 02 FF, or
- Application record on CID 63 01 00 05 containing FF.


For EtM construction, it is even worse. There is no way to check for
consistency, because CBC mode leaves end of message intact even if
IV or length are bogus, meaning all the depad and content-type checks
will pass.

The AEAD construction is not affected. Even if the design is pretty
bad, the CID is the only variable-length field in AD, so its length
can be inferred from AD length.


Swapping order of CID and its length will solve it:

<seqnum> 19 FE FD 01 63 00 05 04 00 02 FF 17

- Application record on CID 63 containing 04 00 02 FF.

<seqnum> 19 FE FD 04 63 01 00 05 00 02 FF 17

- Application record on CID 63 01 00 05 containing FF.

Tricks altering CID length are not possible, because those will
alter a byte at fixed position. And one can not alter CID without
changing its length either, as those will alter bytes at fixed
position as well.



-Ilari