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

Richard Barnes <> Thu, 05 September 2019 21:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0C208120B45 for <>; Thu, 5 Sep 2019 14:36:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 9evHs_aWaYWT for <>; Thu, 5 Sep 2019 14:36:54 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D2270120B64 for <>; Thu, 5 Sep 2019 14:36:53 -0700 (PDT)
Received: by with SMTP id v7so3236121oib.4 for <>; Thu, 05 Sep 2019 14:36:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b6CpVlO5A7s17LFm6T0+9Hevg/hYHVY8YuONvgwO9i0=; b=SXeNQYANWn8n1zf27OuwMlHVsktApTxtODR6o9mlMTbovT0Iu8jchV8Iyx8X+1YnfI XIp5z8Xtvm9uyN22SJ4AoSUgdP4zwooF87L7owmzfbRjH+VvVThGbjp3s8ha3nSWRjjZ Sx6bnr9qbFeFfq/+IbNP0SLhtT3hp4sdgUiAjq5MNtZ4OF376PdtAQ+a+VJDjCnNX9r3 RWoGPwfgeeku3zfzq6Gy3oGvyImMlslO4wVditvWwkckxlUEV9VlEFUJ+9HNM9jEQ8np cST3Zqe1OJIh2breT6HIKZKDrvrdvQNydOKpoReaC1FAoZzsED6+LvNKOuBRWR15pZ7y K7iQ==
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=b6CpVlO5A7s17LFm6T0+9Hevg/hYHVY8YuONvgwO9i0=; b=DvvRLpWZBtewgVXWKshqxiSadOX9SIssLptFCr/VfDoGj8nk3yo0GZeBxwrK7TeOYJ u6tR6/l7NhQPyr9skWFlZZVY6/y/uXkacrtWMj4iskDhiH8oGu0jAxQ4rgZo6CznGOdW 2fzOpFxgUx38JUGfd3rrJDbECilaKaDRg2z25QQRhcEpvDHUgpAetqO6jkf4f5hyZMtr W/l0YfsoqBpVgL3Tth9vgmQBxDkfpnG+CG+Ws7JWqRFndhR/537ivYV69KnrzFCSbP6B 9ekKAqSIC4M5NryMA+NTtaw/pBfKCAXGI/cX2UVQljSFZ5rCdRInt6KAx5g9azn0OTD5 CXvw==
X-Gm-Message-State: APjAAAUCkw5gWZVQgv4sueXZ7WKFOm8iOAKyVktWuieuQGWFtSQqeHxb PLkyGjge/ZBLBvIKX2kkLC540qP/ringaitBgXUw1w==
X-Google-Smtp-Source: APXvYqyCfa+UBww4ukWUAkvR0rGv0IyWSvVFhrhNk8a2d+ORpjjFtUTEJowkIK2kfE0MeMinhoN1VPZoZh+o1iwa1nc=
X-Received: by 2002:aca:4e12:: with SMTP id c18mr3907262oib.135.1567719412868; Thu, 05 Sep 2019 14:36:52 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Richard Barnes <>
Date: Thu, 05 Sep 2019 17:36:39 -0400
Message-ID: <>
To: Watson Ladd <>
Cc: Stephen Farrell <>, Eric Rescorla <>, Benjamin Kaduk <>, "<>" <>
Content-Type: multipart/alternative; boundary="000000000000b63c980591d51e53"
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 21:37:03 -0000

On Thu, Sep 5, 2019 at 2:38 AM Watson Ladd <> wrote:

> 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.

Minor clarification (which agrees with your text below): THe EKTKey message
is not encrypted with the handshake traffic key, but with the application
traffic keys, just like other post-handshake handshake messages (e.g.,

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.

Isn't this already the case with DTLS?  The application-level keys are used
to encrypt both application messages and post-handshake handshake messages.

> The other question I have is with the assertion that cut and paste of
> the same EKTCiphertext across senders is harmless.

Just for clarity: This is not related to the TLS HandshakeType request;
it's about the part of EKT that happens in the SRTP stream.

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.

If it would help make people more comfortable, I think restricting EKT to
be used only with AEAD transforms would be tolerable.  What you would
really like here is a committing encryption scheme [1], but unfortunately
there aren't any of those readily available.  And although neither GCM nor
ChaCha/Poly is committing [2], it's not clear that that matters here,
because the attacks listed in [2] require that the attacker know both keys
involved in the collision (whereas here the attacker would know neither).