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

Achim Kraus <achimkraus@gmx.net> Sun, 11 October 2020 20:41 UTC

Return-Path: <achimkraus@gmx.net>
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 BD4773A08B9; Sun, 11 Oct 2020 13:41:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.312
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 DUAupgq1pd0J; Sun, 11 Oct 2020 13:41:44 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 BF9243A08B2; Sun, 11 Oct 2020 13:41:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; 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 [192.168.178.100] ([88.64.90.178]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MEUzA-1kgXJv2Qag-00FzIn; Sun, 11 Oct 2020 22:41:33 +0200
From: Achim Kraus <achimkraus@gmx.net>
To: Watson Ladd <watsonbladd@gmail.com>, Benjamin Kaduk <kaduk@mit.edu>
Cc: "tls@ietf.org" <tls@ietf.org>, draft-ietf-tls-dtls-connection-id@ietf.org
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> <CACsn0cn4QcnaoocQeoiUXgGoAvfOs+1+Ei76z1Kuq8MMqNEh3Q@mail.gmail.com> <0327abb0-6317-b848-28d0-1fc50f4bf50e@gmx.net>
Message-ID: <de1682af-7099-8245-017a-6d09e29f3a6f@gmx.net>
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: <0327abb0-6317-b848-28d0-1fc50f4bf50e@gmx.net>
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: <https://mailarchive.ietf.org/arch/msg/tls/qfe85OZpP_oPPsa5BGykZ9am_S8>
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 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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls