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

Achim Kraus <> Sun, 11 October 2020 20:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD4773A08B9; Sun, 11 Oct 2020 13:41:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.312
X-Spam-Status: No, score=-2.312 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, NICE_REPLY_A=-0.213, 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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DUAupgq1pd0J; Sun, 11 Oct 2020 13:41:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BF9243A08B2; Sun, 11 Oct 2020 13:41:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1602448893; bh=XeAZc//lkYOiYh/2x2XulRQdoIs4l8vhrcQH22zQyus=; h=X-UI-Sender-Class:Subject:From:To:Cc:References:Date:In-Reply-To; b=Z7eOylXt8/j1xbjppEp5Z2giXj8WfMjYQhXTpCRFRc+iDPWGr7kC2TyfipSAqBHJf VV8jL5n9+zTw1Om5nXenJgcN/dWwmoAS4x+SKEiCkhK1tZtqMnWNIWadBG9OGcg3Tv gJ+aomvxiCX+U4dsUaaPiCR8akFowetVA9a8EJkY=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx004 []) with ESMTPSA (Nemesis) id 1MEUzA-1kgXJv2Qag-00FzIn; Sun, 11 Oct 2020 22:41:33 +0200
From: Achim Kraus <>
To: Watson Ladd <>, Benjamin Kaduk <>
Cc: "" <>,
References: <> <> <> <> <> <> <> <> <> <>
Message-ID: <>
Date: Sun, 11 Oct 2020 22:41:31 +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: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: de-AT-frami
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:wCAvTDx/kP0WrFKYDqBmwfJwr2nj8MJ/6jjYuqGCHrTVB/jlZyg IM2LPx964pOI78nqQ3GDUOFmDPniqjgNxVZ9n4YAlJ6UnlChCYF6TAbIlAIaLdqlDMCODhB mPSye2VRK47+aPBGmm+t4XzpSLuyXmhS8Q83Fqp+zYKu6uHzcQrwa+o8/S0BAu7u9S0OCQN 1veQ0pni2iP0NW1gGvPDg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:eEiuxG1UE/Q=:C+sKgEaTWkRUJX/V/9x4me UmOFrrgIVoIVWj9etlu8utDscndvcSvF3k5LFZ9v0lHdrExpnz6lzZnE+AY2MS9EMDITvhwYt 8S/Y6r0OIObz3ugKIvon615PrWJMQ0tonNoAY8GjsXf/ehCqESgdevsXM9q5KauQfZDLkuDeG nqbnG+zS2t621TTyHire7/IbVjYDyL3hJqUwCOvFiD070z7CQjsfONZw+rMzLn4Uni0BGSVu9 BbXKIWthQn0NNYOL+DJddzrZtjg9FlertmxDILg0ulM/0U8U99uL2Of0zYw6PrxD0ONy84TNN HyLFyYN9MFMMETxGB7tXQnX28XZHhkUhXnt7gqCaxB7ITnOjJh4qLPaMomblaUDdodhym9Rw9 KWFVi8xp5T28dy6ofqaUzXto63K0GH0UgcdqB7PHTwKfjMD8VdOBxJjLWGGAoA2SQUtHvhPPA poiiyZkyKrLKn7a56UFnVpL0IkYEODnepmUI89zrNFHrPT3tLDe2lp6EBIhoxUhzZPo3PldrZ w6X7FjtMaQp6K5nIghI+QiEk8O2x+OaEBuG1CUgEcyG0Si4zvURxCY2YAVtH+6081QL/Zg/Cc KlkMab4CayXCXDM6siOtLKwKoDC9JhZ121UjmDStQCVrFUTRVHd53Hr63VEKqegorXyDE/vtm ar40yCOuHZ3ZF1NT9s8Z34/9OnOqUaHZDMcAmwXux5jfoPOUqpzA3TCW+c+VQVVVWMhKKDitU 8utpDvKlt0AB8XpJHwKcdFO2wcANUvafjcE+IoRFJlQ0sh3hdhVKFbUDT4bc7V7hQBbxI0Qmo DjPu6cD5T/J+ZxE1Z/Xi3D3OySJzUqQD8SJ9jJyx1kl00g1mVGmlUC3mVXdMbY0cQeFPFXKCG lwHFZljTmvgCNywJqWgr8QOAtw31CE4qLZD116bUXqrxR/wKEIvif3DlIIu8FEFWgW902ZUpd AXu92GTxU6Q1+hAxPjB3b2OEgK+TM09sFkj3VUHOcE3mQOPyqkXgFxOyuvE8w2Vdk28UjXQkk 9uaa9l4uWPOeNYcfrVxyuH1ReiZRs0fyWkTCUfv0vL98zO9UO1oDrPI11DXFWKNjmdYf60c2i GMgzIbtZtrH3M7h53oz6EJSYkoYOhhxBy6o1bpjXH/lG4L1Z9Rbli/0AiU43HsVpHbiauVSby 1/iG4jywXNURu+tJAMDgJGQRbcsDREtWsqMrOKSyxXpWvd6RdAn6sUx8SjOhfPaUVYG8Bb/sF RiQ2pfYBnTnQce2GjtdUHsPkoOymuZxmhN1pyDQ==
Archived-At: <>
Subject: Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 11 Oct 2020 20:41:46 -0000

Hi Wadson,

my bad, I mislead in understanding "injective".
It's not related to "injection".

best regards
Achim Kraus

> Hi Wadson,
>> The doubt is because of where it appears not that it appears. If every
>> value was preceded by its length the encoding would obviously be
>> injective.
> I hope, this is just a "typo" or "mistake".
> Prepending the length is the change, Ben want to use to protect against
> injection. You now say, this will be "obviously injective".
>> Here though it isn't clear if two different inputs to the
>> encoding could end up the same.
> Though the MAC definition starts with "MAC_write_key", I'm pretty sure,
> all examples so far are just incomplete. They must declare, if the
> "different/ambiguous" CIDs are refer to the same "MAC_write_key" or not.
> "different MAC_write_key" => obviously "end up" different.
> "same MAC_write_key" => the decoding of the records gets ambiguous
>> In fact I think in the MAC setting
>> there almost certainly is a problem as the length of the ciphertext is
>> right after the cid length, and with some cleverness you can come up
>> with a cid and ciphertext that could be interpreted multiple ways.
>> Unfortunately I haven't followed the draft's discussions that closely.
>> I do not understand how a CID is supposed to be parsed by a recipient
>> when the length can change and the length field is not encoded, but
>> perhaps I'm misreading the intent of the [] notation in the record
>> layer of the draft.
> That's just a theroretical numbers game. No one os far made any really
> useful example from start to end. FMPOV, "CID with dynamic length" MUST
> use a unique/deterministic encoding. If that encoding ambiguous, as
> others imply/assume in their "numbers game", the whole record gets
> ambiguous.
> 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.)
> best regards
> Achim Kraus
> _______________________________________________
> TLS mailing list