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

Achim Kraus <achimkraus@gmx.net> Fri, 09 October 2020 05:56 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 91FF53A0905; Thu, 8 Oct 2020 22:56:11 -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 YiKEU8Kc2eLK; Thu, 8 Oct 2020 22:56:09 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 22AD53A082C; Thu, 8 Oct 2020 22:56:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1602222962; bh=4HoNjGMMCNxQ0wjj0QBNdXPhMwppEjkhQ9Y/BXYdqcs=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=V+xj1gpo16CsuKXd52giS/O6YklMwswVWq9gNfiPQoo9HD/3Td03L/Y7g2XV+UULK XR87IUBG7INkDuLQzZh8AkAb/1tbHa9LrGJ60uvhb5r8jYTkdeopq+1jFXjuuW6aUr 6kU5nZllXsXnmpXIxjFTcv0U7pz0MOmBSzp8+iJg=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.100] ([88.65.148.189]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M5QF5-1kPOL92f1p-001PtA; Fri, 09 Oct 2020 07:56:02 +0200
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: draft-ietf-tls-dtls-connection-id@ietf.org, "tls@ietf.org" <tls@ietf.org>
References: <0da9b525-ec78-bef5-6ceb-5f377019ade4@gmx.net> <4ca7c2f9-1e9d-0d16-0089-649f013b4565@gmx.net> <20201008233454.GF89563@kduck.mit.edu>
From: Achim Kraus <achimkraus@gmx.net>
Message-ID: <6185242d-8ba8-2d2f-5938-afad46c2e854@gmx.net>
Date: Fri, 9 Oct 2020 07:56:00 +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: <20201008233454.GF89563@kduck.mit.edu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: de-AT-frami
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:i2G8Co9HHdp9Wn/lMQ6ReK4YSGbtbttvobMnDzhhiXlDO0UMwqD vGcwOtuwUUp5FarnNCUjBOfR9bKZhjl5+UlLHlE4VYVwvUerOrZSfgbX6a5elnxtiAswVlB vqqn8mIZ/6cFdb9qLbFaH9fiPYnguBFY/yeMN19wzmB75WRmPXHw1y9hrKsNxJ7nvQ5vkpG V9CFwQyRcI0xtdhszsTSw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:3I/MHD1Xeeo=:etE+KU/L9HLy11M0MBEayc +NZ6b7VBB4gKuFLU6AXGwq9Eoi97GfhpINfa+rs3f9ID3BQFFr3QNcqNpzbNXbqDQg4Oav2Ro wHvodUTEMXJsBT+/48YAE/zVfCA11IbRrUH7DVwmUu7ZzzUFNZh3oSlkzwSIFRhuS5KOUMlav wUSD688Sc/r5CIOcTR+zekU4wP3CI9jaGI6jYGydAjhVJF+v0UxEu3Y900KKGbZllM4kKyd6c WLqYBNagxArQXOUmfFNM1yTzkIRN4FlX6uPjFo+Thwn8pljdUJKxyFLEpbrLKx6BetVbZY6hF IHmeYXEM/SxJSNLjpAHxyU6e1sA6EzhxK/xT5Bokz7tmpNv826OO5r4vFjVJt2lQAfTukl4HJ JDnkKAAg/X6vNZUnKIHkZaErUfz6fYLIXnY72AGz0sKV4HAGLYTquvv7Xv0jNgRRZKEKS6dd2 tyr4pWm3YzAAPj41BhiH5q2cPwHH9t7uKUc919mhH8B1iWVH7K1b2nEV5VGt6VRWxaZvKujjI d2INS8YNWu27dzA+C/V/XTgPC7gy8TIMW0rsBTHJ6OQcS634KrizYcV0FaU7+TbJwluy+njqQ cBfWMSozfWllgYBDKT4ymUq7DUNkXLGst64bWeikzvAT3Mwh6F54IS8u/BSqIv3CMGG+PVPRI pbQp7ESA2oKA1rifCs93pq2+GnK+7fuxiaN/IFb20gghd4sNd0tBGNE2TREf/cIfPMqR4xaTZ c54RS4zD5SH/CY4SycKdkn0m1Ab0pdGJTc2LFqY2dmPc+90634wa7UptVw/bB/TXbb2qEDOF/ 9RMoY6yNmPyl06pdYi7SlyhRyyqPss6TIS8e09QNJD0L/ftYcSdlVc60cfSEkb3XbDq3xmZvn kOScO2xs/cQ9HkPvytCc8hcTDAsL9p9lxqaPyCFtra8w1tjPnuO6V0XC8xb+63PCQhYC/Qku4 IVvWQriRl4BNp13/l+Zb2zwH/UE04CgQlEpU8rO4r8RR61LpzYpShnBtdkNujM0PnhBQEF4fQ sxjthz+Hkf3T786yEMJLsxaaTzedfZmaPSvA0T+wIFXpP0UABmHP9OJHoBzyMe0Ql/AQTkGHS 3ztz4DJY0R+QYxKnenp0CFQulQfY2QnA7c9UOWoepoAMGHUJRVRypP72bGYz/bJO0kpSmTRwo pkWWb5lCEV+aZjImvm4M7nBzOnO/B1hu2ZG93iFsJT+YVMco3VrW29TwWMxEiBAg2J3Q1uG+3 TL2b3Air9cyrL9Zb/PZVeVI8dqZPoShxmq3IPZw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Dhcd_07sOO6j-iBEHy8hByTF7EI>
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: Fri, 09 Oct 2020 05:56:12 -0000

Hi Ben,

 >> If that is going to be changed, the early adopters run into trouble with
 >> their deployments!
 >
 > I'm not sure I follow.  Are you saying that if there is a theoretical
 > problem with the construction it would have been exposed by
implementation
 > testing?

No, I don't say that.
"Early adopters" means, there people using
draft-ietf-tls-dtls-connection-id-07 in real world systems with that
current definiton of the MAC. If that MAC calculation is changed, then
they need to adapt their deployments in the field, which is not too easy
(and potential dangerous). Sure, draft-ietf-tls-dtls-connection-id-07 is
still only a draft and could be changed. But not without trouble for
those "early adopters".

 > My primary concern is not actually about a specific situation where
 > injection occurs, but rather for cryptographic hygiene -- whenever we
 > assemble an input for a cryptographic operation (especially MAC or
signing)
 > it is important to ensure that the sequence of bits used as input to the
 > cryptographic operation can only be produced by a single combination of
 > logical inputs to the protocol-level operation or message that we are
 > applying cryptographic protection to.  This property is known as
 > "injectivity", because the map from protocol-level values to bitstrings
 > (themselves used as input for cryptographic operations) is an injective
 > mapping in the mathematical sense.  I believe that I have
demonstrated that
 > the current MAC construction does not use an injective mapping and is
thus
 > not consistent with best practices.

*** protocol-level operation or message ***

I understood your example in your previous mail.
I tried to explain, that the data of your example, especially the
cid-length, is not in the message. Please, find the time to check that
current record defintion! There the CID is encoded in the protocols
tls-cid-records without the explicit CID length.

With that, I can't see the posssiblity to inject the cid-length.
It's simply not "in" and so can't be "injected".

best regards
Achim Kraus

Am 09.10.20 um 01:34 schrieb Benjamin Kaduk:
> Hi Achim,
>
> Sorry for the long silence on this front; my attention had cycled elsewhere
> and I was just overall operating slowly for a couple weeks (sick, maybe,
> but no clear symptoms).
>
> My primary concern is not actually about a specific situation where
> injection occurs, but rather for cryptographic hygiene -- whenever we
> assemble an input for a cryptographic operation (especially MAC or signing)
> it is important to ensure that the sequence of bits used as input to the
> cryptographic operation can only be produced by a single combination of
> logical inputs to the protocol-level operation or message that we are
> applying cryptographic protection to.  This property is known as
> "injectivity", because the map from protocol-level values to bitstrings
> (themselves used as input for cryptographic operations) is an injective
> mapping in the mathematical sense.  I believe that I have demonstrated that
> the current MAC construction does not use an injective mapping and is thus
> not consistent with best practices.
>
> However, in particular...
>
> On Sun, Oct 04, 2020 at 04:35:49PM +0200, Achim Kraus wrote:
>> 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!
>
> I'm not sure I follow.  Are you saying that if there is a theoretical
> problem with the construction it would have been exposed by implementation
> testing?
>
>> 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.
>
> Consider the MAC-then-Encrypt case.  We *know* that there are devices in
> the field that get TLS encryption but not MAC keys for use in monitoring
> situations (e.g., enterprises subject to particular compliance regimes).
> So it is perfectly reasonable to consider a case where a third party has
> encryption keys but not MAC keys, and is not expected to have the
> capability to modify the plaintext of the stream.  However, having stripped
> the encryption by using the keys that they already possess, it is possible
> to move a byte (or in general, multiple bytes) between the cid field in the
> outer portion of the record and the inner plaintext, without modifying the
> MAC value.  Encryption can be reapplied, again using the already-known
> keys, and the stream as received by the other TLS peer is modified,
> breaking the principle that the party not knowing the MAC key should not be
> able to modify the plaintext.
>
> (I am not entirely convinced that encrypt-then-mac is intrinsically immune,
> though a successful attack would seem to require knowledge of the
> underlying structure of the plaintext even if the specific content is not
> known.)
>
> -Ben
>