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

Watson Ladd <> Sun, 11 October 2020 06:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9A5A63A0F1F; Sat, 10 Oct 2020 23:49:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nzvtmy1D-k_b; Sat, 10 Oct 2020 23:49:49 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 812E73A0F1E; Sat, 10 Oct 2020 23:49:49 -0700 (PDT)
Received: by with SMTP id a23so12896226ljp.5; Sat, 10 Oct 2020 23:49:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=z3GOC8iqDeiWdSsl0EqBPu6NxeV8126FL2nvIzwlT9Y=; b=oLMzPdKYfnSe+79M/xSkp88fFXJAzAWt6XgjZNHPCpHkd1tIOOULvQqsTZ49/DpLfI Rjetiye/Ksy6x6TCiFcwGGEK/I8n9LSQ+Keh+/ge9kg34dwkBPI1ayjoRP0xkMZ1yijc sfGxbK8/L9YAXhyy5Njy6xB+P8cGTi3xb8J/C0E/1SQ+i8NYfAJr4WeAhJKo4WTeuxap h4nE5GrKldAjtTTJfPm3TH7TXd9R5JbT+dj9PfnB+ytVbpw03lUf+nIPoZxfNK5SkVho L1rUXin27sG7rmNmpXv+VaeeTagXSZrhjDL5dG/s2KNik7sJGhJSz6AJ9tAmwUAiV7kK X/NQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=z3GOC8iqDeiWdSsl0EqBPu6NxeV8126FL2nvIzwlT9Y=; b=O4uSMl8cfxExZCmO/vN38fEoawydCGo10LZ6zO90xbqzWKmj6/Evuz+ZRvD72lsAhr +Y1R++OVbxIZ6dKEm25Qe484gAdh1l8AKEgjwf8CTm4LcWkt5EJ5acZYz/Sx93ThOpWL lvOCDfV92RHMpcSBu5eNWKt/eERRYmQNBRzDWcWWBPahYJVSiVK02v/ij3jgGhoPjLee HuIju4SRawDhwwXjASt+1kuoJcRdk/PssfnUoJzVHKUYqY1uHWX+YVCtn+/slB6/84qx PJqOYCVW9nLSUCS1iXFe02EKrw5eN/hoth1TlkWnXy+EJW6PIAXUYbz16LT0xu6LXA08 cUqw==
X-Gm-Message-State: AOAM533Y/XjwFcfPzwWjXXwZ9O/+ns/cCUT3HM1zrcTeKGE15P8tHL3q 5ynmZC9k5Y8Q+lSxkJV8iMlTbM933FqNj6bhL3Y=
X-Google-Smtp-Source: ABdhPJx8pKpNw5hTitdBVjsDT6hI/+TL4VokKdK53PcdeTBp/CvwQPRQr2tSKCxf0w3m2z/B2delm29PBW4SQ6s92BQ=
X-Received: by 2002:a2e:3309:: with SMTP id d9mr2808170ljc.79.1602398987388; Sat, 10 Oct 2020 23:49:47 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Watson Ladd <>
Date: Sat, 10 Oct 2020 23:49:36 -0700
Message-ID: <>
To: Achim Kraus <>
Cc: Joseph Salowey <>, "" <>, Benjamin Kaduk <>,
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 11 Oct 2020 06:49:52 -0000

On Sat, Oct 10, 2020 at 11:27 PM Achim Kraus <> wrote:
> Hi Joe,
>  > [Joe]  It's unfortunate to find issues that require breaking change at
>  > the end of the review cycle, especially for a draft that has taken a
>  > long path to get here.   If there is an issue that is exploitable, even
>  > in a corner case, someone will develop an attack, clever name, logo and
>  > website and we will all have to scramble to deploy a fix.   It's better
>  > to fix now rather than later.
> Agreed, therefore I wrote at the begin of the discussion with Ben:
>  >> I would prefer, if this is not changed again without strong
>  >> arguments!
>  > In this case, I don't have a way to
>  > exploit this issue, but unless someone has a way to demonstrate that
>  > this is not going to be an issue then I believe it is prudent to fix it
>  > now.
>  >
> In my opinion, ONE change may be possible. A server may be configured to
> use only the old, only the new, or both by "try on the client's finish".
> I'm not happy with such "dirty" work-around. I would prefer to do so for
> something more the "cryptographic hygiene".
> So, if the MAC is considered to be adpated again, should it not be
> discussed, why at all the cid-length should be put in?
> I asked this already in January 2019
> The MAC contains already a overall length. Even in that discussion, no
> one mentioned the reason for adding it. So if there a doubts about
> injection, why not remove it at all?

The doubt is because of where it appears not that it appears. If every
value was preceded by its length the encoding would obviously be
injective. Here though it isn't clear if two different inputs to the
encoding could end up the same. In fact I think in the MAC setting
there almost certainly is a problem as the length of the ciphertext is
right after the cid length, and with some cleverness you can come up
with a cid and ciphertext that could be interpreted multiple ways.
Unfortunately I haven't followed the draft's discussions that closely.

I do not understand how a CID is supposed to be parsed by a recipient
when the length can change and the length field is not encoded, but
perhaps I'm misreading the intent of the [] notation in the record
layer of the draft.

>  > Would this issue have been caught by formal verification?
> That may also be something to help, not to change still again and again.

I don't think the formal models of TLS reach the wire encoding.

Astra mortemque praestare gradatim