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

Achim Kraus <achimkraus@gmx.net> Tue, 17 November 2020 09:09 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 43BDE3A0A1F; Tue, 17 Nov 2020 01:09:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.6
X-Spam-Level:
X-Spam-Status: No, score=-0.6 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.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 Tj4jwW8f4xoE; Tue, 17 Nov 2020 01:09:44 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 B4D313A0822; Tue, 17 Nov 2020 01:09:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1605604177; bh=v5ePJjFfTHbmGvauRT+2ks0z+KUdT2r3aIgVDPuTuIc=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=antAWOMImzGpGbAXGmvvMh0y3Um6Qx7k2gLLKUjx4VG7P9bA87u0sZY5x6I7R0e07 0xcACE8MIbQBXYaxCsBsTFl8U2ocFzvZAxahVhDTSk8rfvRiOet2MM9sAaf9mP1z+S agE3qZ2QAuzjs/VcApzIP5gFYAlvoehAsGZ74bOI=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.100] ([94.216.238.237]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MaJ3t-1kkGRB3xVV-00WFLh; Tue, 17 Nov 2020 10:09:37 +0100
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Eric Rescorla <ekr@rtfm.com>, Watson Ladd <watsonbladd@gmail.com>, Joseph Salowey <joe@salowey.net>, "tls@ietf.org" <tls@ietf.org>, draft-ietf-tls-dtls-connection-id@ietf.org
References: <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> <CABcZeBPP_PFWtaNB4Wr+2MoY2+8Mh1Vxt9A-Hp5LaCg9DiLCFw@mail.gmail.com> <20201027010029.GG39170@kduck.mit.edu> <CABcZeBOQxpWMSuJiiXDB0Cf62iNU+hU8Wpd_Pd_1HOgXJYc0Kg@mail.gmail.com> <3e55d1fe-62b2-c62e-a085-032ecb43addb@gmx.net> <20201117060745.GI39170@kduck.mit.edu>
From: Achim Kraus <achimkraus@gmx.net>
Message-ID: <0579646f-f468-8bed-67c6-951239aa972b@gmx.net>
Date: Tue, 17 Nov 2020 10:09:34 +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: <20201117060745.GI39170@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:t/EV34VLHIHIWDrZlgmNOpZgH3PAUyMH8PXJRJ5A87cQXXHVlGq FgRKg6clSZ3unBuQymfArn1WnWPKXi9/PuTqDRHubjaq0l1xGircJRvpGH0SLMAdrkunM2l D1WNFIf2uAfsFPnf9nyqRqSxT1adTmLCqxkdQyQyfanPARqgDDHe9qIicivKqYDOd0KMN61 gXxe5Gzixnv7yoFhfdvUw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:ZIaW4faN8sk=:GcBcBwjQ+zy5mKKumUSJvi kH/Q4S4cgusPtGgcg+zFyQthAI5CFLSe+iZN5iJN82ZeBH4amMaRj0Upj65Dc4YkQ9aP3KqoC +W5uv3sXlNTgO0/zUqCh2GAg6er9akkq3JAEYFaF6F/DoFtstRdpYCEHQDvBwb883HUUGnfYY 6ayx185Vz6AxbtqTPJseiB1nJ9Q5vGaF3MOj9yHq4Gf6VBO0AR/u6pWjimIHWhm7qy1tMBx5Z LqZyf8eih5TT+5P0RL3YN45QvWccYD7XCDLMeXuNrtk3ZuIt8qvWgsIr7wlFsqX5SEPuPuUvg luVZun79ku9TP0QjmyPcGHS+ieSS30PgUL1F7rNB0wzVAeqADeY02m0ej1isrbrJyqEdC5yhx p6t0t6w98FQNrwnJGSTj59eCfuM1hXG75M1f49gnOk1P5Ar9fIgY2N6XAhaKVc3rwPave2Us+ I7rpqDs2r5D1xGKAqlq9ygJ8yI+OJBAsu7m8eQ2n9U9RNjWBdKhNC3zEpQ4RR+vP6977wPdSD +9ogJoua5/99zynFukOXwyPVXGjWIypCtx6zregTH2yz92BhrlgVgFhxfsDD78XwRuueusyPk 42vFQ/TtVVch9kM31qvZxWjRHY0F5oKgo9SIb+/M3/axvqnZfqk47LqANlUysiG0ihV3x+sPV A5RKlV9JTwBkf6OgEPZp+K9Rlgu51LyprAtxf2S8mTO/cV+x1CM4AioT2ETCfwpRGs2M0qY3q ijE/LuJWouOSHTn2VIvW2xSSu6kOtu8ke9xH1gKgzlRSt8ApMeHl9wSf6OybXjZpJ07pVGFjE FgVGSPZGKYrQhLlmoUcbh8RUp6BGs1f44/25WxVk+QTpZgxkS5JOqasIJeNYZSHoIJiaJ/EgO fkqIZDdL8IC0K4ztQ/1w==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/dGFayBTqdkLG0oFbYlzkkuvs7g8>
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: Tue, 17 Nov 2020 09:09:48 -0000

Hi Ben,

Am 17.11.20 um 07:07 schrieb Benjamin Kaduk:
> On Fri, Oct 30, 2020 at 01:28:12PM +0100, Achim Kraus wrote:
>> Hi Ekr,
>>
>>> As for EtM
>>>
>>> Encrypt-then-MAC:
>>> struct {
>>>     uint8 marker = tls12_cid;
>>>     uint8 cid_len;
>>>     uint8 content_type = tls12_cid;      \
>>>     uint16 DTLSCiphertext.version;       |  appears on wire
>>>     uint64 seq_num; // includes epoch    |
>>>     opaque cid[cid_len];                 /
>>>     uint16 iv_length;
>>>     opaque IV[iv_length];
>>>     uint16 enc_content_length;
>>>     opaque enc_content[enc_content_length];
>>> };
>>>
>>
>> I failed to understand the reasons behind this proposal.
>>
>> 1. Why should the "marker" be added, if the "content_type" is already in
>> the MAC, and this special MAC is only applied for tls12_cid records.
>> What is the intended benefit of that?
>
> This is another general hygiene item; we are preserving the invariant that
> the first byte of the MAC input is the content type -- this is at present
> (IIRC) invariant across all TLS versions and MtE/EtM, and not something to
> change lightly.

"All TLS versions"?

TLS 1.2, RFC 5246

https://tools.ietf.org/html/rfc5246#section-6.2.3.1

The MAC is generated as:

       MAC(MAC_write_key, seq_num +
                             TLSCompressed.type +
                             TLSCompressed.version +
                             TLSCompressed.length +
                             TLSCompressed.fragment);


https://tools.ietf.org/html/rfc5246#section-6.2.3.3

The additional authenticated data, which we denote as
    additional_data, is defined as follows:

       additional_data = seq_num + TLSCompressed.type +
                         TLSCompressed.version + TLSCompressed.length;


So, as far as I see, at least the TLS 1.2 variant doesn't do that.
RFC6347 doesn't change that, so DTLS 1.2 also doesn't do that.

Maybe you precise the "all" to a set of versions to make it easier to
check it?

best regards
Achim