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 >
- [TLS] AD review of draft-ietf-tls-dtls-connection… Benjamin Kaduk
- Re: [TLS] AD review of draft-ietf-tls-dtls-connec… Achim Kraus
- Re: [TLS] AD review of draft-ietf-tls-dtls-connec… Benjamin Kaduk
- Re: [TLS] AD review of draft-ietf-tls-dtls-connec… Achim Kraus
- Re: [TLS] AD review of draft-ietf-tls-dtls-connec… Achim Kraus
- [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-c… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Benjamin Kaduk
- Re: [TLS] AD review of draft-ietf-tls-dtls-connec… Benjamin Kaduk
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] AD review of draft-ietf-tls-dtls-connec… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Benjamin Kaduk
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Michael D'Errico
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Joseph Salowey
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Watson Ladd
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Ilari Liusvaara
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… antoine
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… antoine
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Michael D'Errico
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Benjamin Kaduk
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Benjamin Kaduk
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Benjamin Kaduk
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Benjamin Kaduk
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Benjamin Kaduk
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Eric Rescorla
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Benjamin Kaduk
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Benjamin Kaduk
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Eric Rescorla
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Benjamin Kaduk
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Eric Rescorla
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Benjamin Kaduk
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Peter Gutmann
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Benjamin Kaduk
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Achim Kraus
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Benjamin Kaduk
- Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dt… Eric Rescorla