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

Achim Kraus <achimkraus@gmx.net> Fri, 30 October 2020 12: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 3E1A63A0E6E; Fri, 30 Oct 2020 05:56:31 -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 EZgoaszKTZDG; Fri, 30 Oct 2020 05:56:29 -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 531413A0AAF; Fri, 30 Oct 2020 05:56:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1604062579; bh=WTD6xEhO/DyALM66Wr1rEqmR9XidAZfmYHFcjH/YVY8=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=MpVt1heYdQ+R9TczjgI4xw7vtj0h9k/mHxam+dmrRhx/2CMFWeWBdEYocwosMkFrK GCSUISqrlSoRL1M5LJ2VQyOVoJBe3/8II8OHFW+S7mQ/3w3Er2reFFphfnwFPyOH/f fjas55e50Qauuh2XQVJcWJ9s5vup0fX7Rm3EACP8=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.100] ([94.216.226.147]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MK3Rs-1knOAv0Wmk-00LWW1; Fri, 30 Oct 2020 13:56:19 +0100
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, Eric Rescorla <ekr@rtfm.com>, Benjamin Kaduk <kaduk@mit.edu>
Cc: "tls@ietf.org" <tls@ietf.org>, "draft-ietf-tls-dtls-connection-id@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> <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> <1604061544196.52783@cs.auckland.ac.nz>
From: Achim Kraus <achimkraus@gmx.net>
Message-ID: <2a8e1752-667c-2211-fe84-5e69d0999280@gmx.net>
Date: Fri, 30 Oct 2020 13:56:17 +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: <1604061544196.52783@cs.auckland.ac.nz>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: de-AT-frami
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:5lJFKdOPPfDq/ig17j7kVNdq90kb+WqlnehZIMMCt8zSFLIARHg 7+vjeWfyrgGjilSXkYdUEgmA8dPke4JF4YpyEm/lmAYnHrWfWbAwSzWXUf32hThTFwXYQDl PXtFCOdpWEsGSXV98mGh6TZLfSCtsPKuYmkDHdc6DvYZpjELYEBZ899Nf3Fg82Bwakg+60V c+WxprzRzZabkBDiyBJQg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:REfV6FpLzTw=:19wyz1zdF+LyBeJzBpLPWq rr5rMI/G32uE6nDAGCZBqlBUIyEpk96xe+gzfOd6KEMDGprrtKPKV82AfUJ2v7ZRQZ1ucInfc uev+qzM5GYNwyQj3PEXUo3JKVhpBkF25lnWwTgIHKhIc06oMMvXTIhwI6DZFJylOsLauqY3+2 nju4hIiMRImDlJUMwtn0fSn6TXu3BGp8yxUke8I5pZ0XZ2BnenY6vn4f6chGhwwVgHD8ybCfm C7t9AGFclHsWG32IlX4o9Wr2zUDaVwFxGnU3QbeuXrufyowB7HFgzj5LipaTnXxm+VAjjfcCt eErpJ+r/PRuXz9oPjs2SvIOcqC2535NhTvdGJDb6a/TnfFwxWVHjvmqqBWqOzLiHgYEruByEA ukSMEvSGMMIfQedmoNtmpcwfNfZlNKPMpPyhvTLyw4SkrfBjIFVmlcTTFdR5myMVF3dPJ9QOp l4vSF8XSl5jy32kawgWZy8Ta1lufsLevvU9VEejx7DoVeAFvtFUALm/ln2pLq7gXzS9Jq8vEm uYMrP/9UEC6YdnPGNF5vs0B24NTvZFk98i5SGfyhJyTq4pl7nfAyhsfa3lU50asahlz+UPzrb ybKbl6cdsJLY5ieiQATkVvp+BbwAS4h1RR82Bhs43RPBKZI4YxM7Kkx5K3CCo8UAXZXtfJtEC 1NA3zgpkfquq8qabLtieM1itm1MRGNGuiyVqW+qmXg39fxaKqC9YWsOU6eNnmbYKg/KvBdLe6 3Nj/kuy2Qxj9HjPAYU4nfs7Kfp/f1qtRZwlVLOk21yDHIdltnhkPhUGlmd3sEosbQIkrWLtS9 ft9xiAJd7T7PaF3yOoK5Ar8g8zJDKzJHG+XA8/nh3wy3IA6pFis34ETWY69GdO6A0N9A94Kj0 Ttr7stDtWrUHzYvKqnjw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/BbOib9e7CB0qAF7jwSssuIzVO08>
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, 30 Oct 2020 12:56:31 -0000

Hi Peter,

thanks!

 > It precedes the IV, i.e. the field that it describes.

In other contributions, it's said, that it is also important to keep the
header bytes as they are. With that, the "iv_length" should be ahead
before the header bytes starts.

And I'm still curious about the "uint16" instead of "uint8".

I'm looking forward, when this will get finished :-).

best regards
Achim Kraus


Am 30.10.20 um 13:39 schrieb Peter Gutmann:
> Achim Kraus <achimkraus@gmx.net> writes:
>
>> 2. Why should a "uint16 iv_length" be added?
>
> To make it explicit which of the bits being hashed is the IV.  This is one of
> the flaws of things like OAEP, there are a large number of implicitly-sized
> fields controlled by external, unauthenticated parameters, so you can make the
> verifier see fields as other, nearby fields (I'm using OAEP as an example
> because it's particularly bad, there are so many optional values controlled by
> external unauthenticated data that you can have all sorts of fun with it).
>
>> 2.b If it should be added, why in the middle? It's not on the wire and so I
>> would assume, if at all, to have that at the begin.
>
> It precedes the IV, i.e. the field that it describes.
>
> Peter.
>
>