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

Achim Kraus <achimkraus@gmx.net> Mon, 26 October 2020 19:29 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 6D7973A0E4D; Mon, 26 Oct 2020 12:29:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.347
X-Spam-Level:
X-Spam-Status: No, score=-2.347 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.247, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 icTKlQukWyeL; Mon, 26 Oct 2020 12:29:11 -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 52A9D3A0E4C; Mon, 26 Oct 2020 12:29:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1603740545; bh=XvsPaDnuhJa+rP0tY51pJqfM+IqiqdoFh30KAlGJurM=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=Wt99qXOGVJxy29BEyvPvXr3Lj40Z5Z49Wsq0dQfyB08tkiJur86F+pZmSSOfjis6/ vy5mPSKkjNT3Bd2wIvcGMTzJPOSE9LA5ko5TuqU462ezB51fBO318eeE2vIVBhOwEC XoWFs9IKlviLyAyS+miN9FN8CMNpDBQjKgX2pKd4=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.100] ([94.216.225.66]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MhU5R-1jsrLe10ZX-00eh0D; Mon, 26 Oct 2020 20:29:05 +0100
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: "tls@ietf.org" <tls@ietf.org>, draft-ietf-tls-dtls-connection-id@ietf.org
References: <13a821d3-30cc-94b8-842c-22a87d280f09@gmx.net> <CACsn0cn4QcnaoocQeoiUXgGoAvfOs+1+Ei76z1Kuq8MMqNEh3Q@mail.gmail.com> <0327abb0-6317-b848-28d0-1fc50f4bf50e@gmx.net> <20201012200548.GD1212@kduck.mit.edu> <bab402e6-3353-d750-a849-21c91081f94e@gmx.net> <20201014212428.GP50845@kduck.mit.edu> <a7110178-6220-175e-869d-fcc44400f773@gmx.net> <CABcZeBNocUYZO9yxuG-DYh33ss+Dum1EOxHYEdww5OCR=rKFXw@mail.gmail.com> <20201024021316.GN39170@kduck.mit.edu> <082806e2-5ff2-61d3-e181-31e50daef7f2@gmx.net> <20201026165635.GQ39170@kduck.mit.edu>
From: Achim Kraus <achimkraus@gmx.net>
Message-ID: <f2c48994-35bf-3a83-d6c7-13b54c2afac4@gmx.net>
Date: Mon, 26 Oct 2020 20:29:04 +0100
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: <20201026165635.GQ39170@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:/uhloRfQTmn7rgclewoVnV0oWgqLMv+L0VEwPBjisQbBY5D32+3 H1PnIW9DuVrxHM8y5I3f5l1MWfElIHKDrUeulucabldsfZ9f5dS3Jlcz1KB/4hgNnQjfI6f sR9qIa4+4bYx5jHDd6+u/8TY6aINnDDAKjLKPADZFPOLYVnk2WQ+wrA9Ynm4Ufw2QNztZXT 7L1Lt2Hcrzddpc+TtnVuw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:spnN64WPmVA=:t6JH4m46ZWyb78vrHXAJMc 1hZgZ8U/1z78gwd9lEvs0mJrS3oh3B2IssV1DWPCTPEq075yDTaCKl96b2xe5pW/ZpV7tiJzJ 7EDTJY1wHM4KDA0CpRGPgwh75KKjEQLDfZhHMslL7axuOdulR8zDiS1UBronyDcfFJhf6egDD 8S7YSF+iXyw6Smn1RShXrwiVpi9tsTrrRaJ1zSfpUxBH6pWbgYWUwApNmomwrE1gqa0QZ8PbA /UdLR+WGZLKTsrJA/NlrUbSY8IHpMUD6ycpQ5zRutVlKde9a9+iZAjks+2OzpsV4gETp2GvsM brztnIGBbJ7RSlGsMkiNYbrQlWG8I8dsrs6kiy+kjRtvYNTF3xAF0fNkNOoQVZEtXZStJZw2R R9CinLLWwA7Dlqsi2GFOwrKczhLuzIc1D6mR4ZprSE74TgQkaz3uJfajGwyJEmmTEpIRUcyIW tlhYuGktjiSY4XWdhysHu2+iRTfdVXIS7/yXEhXv6vYsmRWWzgsAln/A060RlRXMBbvoalOcr yDRmaJelGdlXVvfgyLu2PyonZzqKsfh6R9DoPvNmb4qERBnsv91v1NjWJEgH2SRbvXLCQJN52 htEe2SHrI+opKVF3c/mZEIuo7Q53o0rkznaSQuzMc71x0j87wNxS1iJHVtkKIaBOTJkUvxWqH jQYUKWCu9VQtTb6YNdVXcizu1V4Z8Euj2+2mv/1cqlAyk6B89xkKezvt05gOWQmKts8ABfzYQ sSnJ1vSxaILigLxlOub9O1UwT0KAmljKWbGrq5jZB1I1JfxsYI5dig+QjPMkWemIK4GyCUEV5 iBr9bj7+FudoZCtsCPy53fdL63+SdKRtlh6MoWE2DUJoXPgpnWX6DrDR/q30v/5ppB5lrxiPw dNjxrVHLLQXJbFXZmZ3g==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/qcRrJ5xeykSWNXdD6xrYboC9VzY>
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: Mon, 26 Oct 2020 19:29:14 -0000

Hi Ben,

at least at your point (from the e-mail before)

 > and not have to change it again.

I agree :-).

That will naturally become true, if the RFC gets released.

best regards
Achim



Am 26.10.20 um 17:56 schrieb Benjamin Kaduk:
> Hi Achim,
>
> On Sat, Oct 24, 2020 at 08:56:08AM +0200, Achim Kraus wrote:
>> Hi Ben,
>>
>>>>      Because each party sends the value in the "connection_id" extension
>>>>      it wants to receive as a CID in encrypted records, it is possible for
>>>>      an endpoint to use a globally constant length for such connection
>>>>      identifiers.  This can in turn ease parsing and connection lookup,
>>>>      for example by having the length in question be a compile-time
>>>>      constant.  Implementations, which want to use variable-length CIDs,
>>>>      are responsible for constructing the CID in such a way that its
>>>>      length can be determined on reception.  Such implementations must
>>>>      still be able to send CIDs of different length to other parties.
>>>>      Note that there is no CID length information included in the record
>>>>      itself.
>>>
>>> ...and thanks for the reminder about how we say so in the text already.
>>
>> (your example from a previous e-mail)
>>
>>   > 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>.
>>
>> I would feel much more comfortable, if you state,
>> that you consider now either
>>
>> 1. that example was not compliant to the draft,
>>
>> or
>>
>> 2. the draft is not clear enough about that.
>>
>> If 1. is true, https://github.com/tlswg/dtls-conn-id/issues/76 could be
>> closed.
>
> It is neither of those two.
>
> While the party that will be parsing packets that use a given CID value to
> identify the connection needs to be able to determine the length from the
> byte stream, the other party does not.  Accordingly, when computing the
> MAC, there is still malleability in terms of which "interpretation" of the
> byte stream was intended by the party computing the MAC.  The party
> receiving the packet (and MAC) will only use one interpretation, but the
> party generating the MAC could have been deceived into using the other
> interpretation.
>
> As I said previously, the CID values are not authenticated until the
> handshake completes, so there is a real window where this attack surface is
> exposed.  Note that I do not need to present a complete end-to-end attack
> that breaks the TLS guarantees in order for us to change the spec -- it is
> enough to have shown that the malleability of the cryptographic input
> stream is exposed to potential attack.  To leave such behavior in a
> published protocol spec would be irresponsible, in effect, publishing an
> algorithm with known weaknesses.
>
> Thanks,
>
> Ben
>