Re: [TLS] FYI: new TLS HandshakeType allocation, from draft-ietf-perc-srtp-ekt-diet

Watson Ladd <> Thu, 05 September 2019 06:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B73D12006E for <>; Wed, 4 Sep 2019 23:38:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 fHgKmW4DKtuQ for <>; Wed, 4 Sep 2019 23:38:51 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AA3F512003E for <>; Wed, 4 Sep 2019 23:38:50 -0700 (PDT)
Received: by with SMTP id a4so1156051ljk.8 for <>; Wed, 04 Sep 2019 23:38:50 -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=//AP1SARVYB6K/SHcsQwTxPmNsBVuV5ZhUQnDGzjZaI=; b=StJE0NqTWzrQD2rUSa++AXq0F2opSX7pbHNznMAWM1JSYONvA651YdUeuJzklu1wbG 3AfFjh5rRoKIgWY5ai7iepJEkGhSZWGJNxarrjvh+7dOlgxR9qxvgkE+Lwtp124f0NQH tl0XM2TZHltPNLOM0ESa+RNkTozNV5ZGXtdkIfDl41VnFLgtjDNlOsFWOzHJdvngpwL7 OLlEbvR9YXdZ4W1jdcNyrzdwdfs0lWFXlNWtKb7PTMKMXthS5LgkFJuXBFQQmXRK/pY4 bFsIN04wQLeSnpz3pbZLVYbFK7IKleNjeJHMfuGVKCo5HqzXaIN/yNzv3ApkGCVq3cIl Ojcw==
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=//AP1SARVYB6K/SHcsQwTxPmNsBVuV5ZhUQnDGzjZaI=; b=FP9yvhJ8aOAHo0WswybvKiqVshroJAX93w6dItydhmY0oqMW99351lZh3R0rfc7hg9 RqKDPUfp7b13TvAAs1nrE4jVe06OXTPipmuKX8GL+RMauc0Q+tSrC7fntKWuHCfKFzdT H24JEXKMBfRyWc5AKCkTsg4HZA543BoQ3kEXjz29bytIrzHeerjLMQTSoTZyZZC9lzA/ lL4t2l3hptH2KnGreT8ymm+ISniveH5xGmYNmCpyyZw6KtjK6yMrJE+bjCY069QMmOLS p8pdAX9KGb+J4eZU7Frz9EVzH+o793RohWkA/sFEmUiiVGWTKmqYRZtyNDbxT3PTU266 ksGg==
X-Gm-Message-State: APjAAAX36u+cVKQeLRL7gJr2XMli1bfOQb+QQM6MHRJLjqRbeMySJoSb +DrMsBFlKQxWPKbsMG8Eu7akeG9hneoCrrMsraI=
X-Google-Smtp-Source: APXvYqzq3IQwiVFas4a7kjCLoC0I/FwpWuckbBPKh7wjaASgBR/2lPueQnxL7zfIYKTq73GqYFwlwGLI5rUu70upuD8=
X-Received: by 2002:a2e:331a:: with SMTP id d26mr913498ljc.239.1567665528835; Wed, 04 Sep 2019 23:38:48 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Watson Ladd <>
Date: Wed, 04 Sep 2019 23:38:37 -0700
Message-ID: <>
To: Stephen Farrell <>
Cc: Richard Barnes <>, Eric Rescorla <>, Benjamin Kaduk <>, "<>" <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [TLS] FYI: new TLS HandshakeType allocation, from draft-ietf-perc-srtp-ekt-diet
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: Thu, 05 Sep 2019 06:38:53 -0000

I wish I understood the analysis of TLS 1.3 better, but a core feature
of the protocol is compositionality: the keys from the handshake are
fresh, unlike in TLS 1.2 where they were used to encrypt the Finished
thus posing an obstacle to analysis. Here the handshake key gets used
to encrypt a message that has nothing at all to do with the handshake:
probably fine, but not obviously fine. What's more of a problem is
that the application level keys are now used multiple times: first to
encrypt part of the handshake (the EKTKey message) and then
potentially other data (RFC 5764 doesn't say you close the channel and
only do SRTP). That breaks compositionality. Safer would be to derive
separate keys for everything.

The other question I have is with the assertion that cut and paste of
the same EKTCiphertext across senders is harmless. The data obtained
will not be random. In some cases (say if unauthenticated counter mode
is being used) it will have a very predictable relation to the
original data, and the resulting errors may leak information. These
sorts of attacks have a long history of happening: it may be more of
an issue for other parts of this whole effort, but I don't think it's
as harmless as the draft says.