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

Achim Kraus <achimkraus@gmx.net> Sun, 04 October 2020 14:35 UTC

Return-Path: <achimkraus@gmx.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 882813A02BB; Sun, 4 Oct 2020 07:35:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id osghGLp2UTqr; Sun, 4 Oct 2020 07:35:56 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net []) (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 DDD993A017E; Sun, 4 Oct 2020 07:35:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1601822150; bh=oApbH0KgquSiwVjj9UK1+p1qOg/Mjwf2t+C6aDJFvvA=; h=X-UI-Sender-Class:Subject:References:To:Cc:From:Date:In-Reply-To; b=eW+wlR2IRMv4iLPPSX4pcnBjs74lI/254isAFlPxcmzPjkGNLgerT6zw+9O+/5X6c 6dK9uUrs0rlXeMhcKcOM7tdR8mZ5THuRBA+VoOmzD1BAtK9ngBmYL44ZENBVqU/UL1 S0MyxC8oXZHMGt2monCm6nqyddf91UcLPlR1NWwY=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by mail.gmx.com (mrgmx004 []) with ESMTPSA (Nemesis) id 1MjjCL-1knRaH2Gtf-00lFnw; Sun, 04 Oct 2020 16:35:50 +0200
References: <0da9b525-ec78-bef5-6ceb-5f377019ade4@gmx.net>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: draft-ietf-tls-dtls-connection-id@ietf.org, "tls@ietf.org" <tls@ietf.org>
From: Achim Kraus <achimkraus@gmx.net>
X-Forwarded-Message-Id: <0da9b525-ec78-bef5-6ceb-5f377019ade4@gmx.net>
Message-ID: <4ca7c2f9-1e9d-0d16-0089-649f013b4565@gmx.net>
Date: Sun, 4 Oct 2020 16:35:49 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <0da9b525-ec78-bef5-6ceb-5f377019ade4@gmx.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:BXtBWncrhmbYXFV4hcmIzPter2TOmY61MKE8A//a5f6PbQhw4tv p5PIwXJD6I/6fIvrzV2V7FeNBR60pVjDog0FobO5wiyRmG9h6Ehbhksx90N3P5WTNkXThOB NEsIX0DJxwmav4h5QFqQ8zRUCWg34PtgVvuZwaajbrao3w1qBQ20btHTepE89LV+g0yD9xA 6uDN7LMLyHZsCH5r8tqRg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:CXUaltPVwmQ=:6IsQMbdyW9J+vqP3XV1crg FjRsG2QdmguUNffiFEt1vpJf+jX9htNZG+uW4uLfCcZ21pmu7GvpupZD79Fiz28gkZd6/LT03 TmyDtiE+y13DHwi+9PikyCEdXKi/g16EJVts2oymGk6Ghy6/cLG+NzCwzce1OMkvKSR8uR9gX e4ps/0OCjA93DWLNz3rfFX5+7h2zthrbLxvHUdWSwv4G1/uBM0/5u9iGlqbJ73aw9t4rk6WDb 28E/rZxxOaPeAhc9E4tp/SrOgOHnJPy2deJm3C5QS35A+JGQgISn8Vr+FzqfjTUtB8OeLVEr8 jwHHLvq9trHKxLEYV4xyPT9mEVbY8sidd6YUHCB97P3FgjyJxkG6amHsjD3XLyz7uBkChLMTY gs9xbrSft5J+2eol0AhItpZFRF0o6cxnQR58TqDXCfFASPketOXb2jzWq85dg7CF0xvLsUa7O /kN47Hn0mBAooeKa4+ms7R/8rLrk0U2/M+HqsqPHlPpSDJHqJvu0BA/c0BPkvSDlhxy55kFtw QV1p4FAEl4mVZurhbRvB2V3DuhvSCFNn3Ue2ZPlmeEhyk5sTA5HfnCQiNs4xg5iwjB75nIQjo YIfFmDNfLb8ztg/dMHNiT2uTFj/o4BbzSX32/C/xP9LMi9TMrWryLXWKl2hJoqKeA/hwsd4SF LgvqiaSnR20KME8mKo0hm9KN9tFxKmpl8J9VmrdGDbtPjFtNPNWriSArB4w9NgASxgwyTl663 I8sL2PsnbnLRzNkpLdHb4Fw9fPzI7Lma1TwL0GsO0b1md5IyQv5vdfz8L6UC9hPH6yxGiCC2Y puTXJ+E3XXv+VHs16CwDxswT5kLU7idcy16+9Em+W45wk+W9Kgn2Nh+q3GXn7qxqgyz/YO8Lw jfEgHHRNSstkT+RSTnseSFVJ7RL9luX3Oftqsyv0FLpHNuL6wAlfjdf9/QUtwrn1/qNdX7KNc lsmOLSXHotoK1YJxjKwJRUWtmZuriChvtNHVYHhTe57B05CDkaH/x3Q77woqCOCrXCABpDi52 JgUVh6zKG4Su8xjQ0W//55sPzEiGebtC3+VjaI4S1oSowUuIBNi1lnYuT20uqb3QKgbfy4Mop PWLAxgLJ4trCknU2Mou3byIK5ZNeVAhvB3tGuTndFeJB5IgRDoWKoIxfwOERmK/otodNNgG/S KLMdWYTnQA9u9USzSBEE0d9mK4dYLKe6z10ns565BY63XTa6LfMu7+YQaNAtSBeuvx92ByZfm YMP0qVpgWh6Sr66eykJAKBYEMvRySAhhfgZ/rEg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/sCZOlcWcZ1Lw3YNndDpoHfjDvno>
Subject: [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, 04 Oct 2020 14:35:59 -0000

Hi Ben,

any progress on the cid-length / calculate MAC topic?

As I wrote, though the cid-length itself is not "on the wire" (it's only
the cid), I can't see, that the cid-length could be injected.
Do I oversee soemthing?

best regrads
Achim Kraus

-------- Weitergeleitete Nachricht --------
Betreff: Re: [TLS] AD review of draft-ietf-tls-dtls-connection-id-07
Datum: Wed, 16 Sep 2020 08:31:19 +0200
Von: Achim Kraus <achimkraus@gmx.net>
An: Benjamin Kaduk <kaduk@mit.edu>
Kopie (CC): draft-ietf-tls-dtls-connection-id@ietf.org, tls@ietf.org

Hi Ben,


>>> The TLS 1.2 notation is "seq_num" for the implicit sequence number, but
>>> DTLS 1.2 says that the MAC input is the concatenation of the DTLS epoch
>>> and the DTLS (explicit) sequence number.  I do not see this
>>> concatenation given the name "seq_num" anywhere, so I think we need to
>>> reformulate this expression.
>>>              cid +
>>>              cid_length +
>>> Does this construction preserve injectivity?  It seems easier to reason
>>> about when the length of an element is always before or always after the
>>> element itself, but we put the length first for some of the other
>>> fields (that appear after these) so there seems to be some malleability.
>> That order was also discussed a lot.
>> https://github.com/tlswg/dtls-conn-id/pull/29
>> I would prefer, if this is not changed again without strong arguments!
> Thanks for the pointer!
> I am not sure that the specific question about injectivity was raised
> there, though.  (The topic of whether "seq_num" includes epoch was raised
> but I did not see a clear resolution on my first reading, just
> https://github.com/tlswg/dtls-conn-id/pull/29#discussion_r246152379)
> Specifically, the question of "injectivity" is referring to a scenario
> where I can use different actual values for (cid, cid_length,
> length_of_DTLSInnerPlaintext, etc.) but have a collision in the constructed
> cid + cid_length + length_of_DTLSInnerPlaintext + ...
> (Hmm, we should probably say that length_of_DTLSInnerPlaintext is a 2-byte
> field...)
> 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>.  The possibility of such a
> collision weakens the cryptographic protection and should be avoided.

If that is going to be changed, the early adopters run into trouble with
their deployments!

The cid length is not on the wire, so on the wire is (cid 01 01)

> 01 01 02 01 <513 bytes of plaintext content>

Therefore I don't understand, WHO will inject something, which is not on
the wire. For me that would only be the peer's implementation, which
extracts it's "own" CID wrong, or a "spoofed CID" (maybe that's the time
to read my proposal about a CID Authentication Code, issue #74.). But
with the wrong CID, the wrong keys would be selected and the MAC will
fail anyway. So, I can't see that collision.

best regards

TLS mailing list