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

Richard Barnes <rlb@ipv.sx> Thu, 05 September 2019 21:36 UTC

Return-Path: <rlb@ipv.sx>
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 0C208120B45 for <tls@ietfa.amsl.com>; Thu, 5 Sep 2019 14:36:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com
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 9evHs_aWaYWT for <tls@ietfa.amsl.com>; Thu, 5 Sep 2019 14:36:54 -0700 (PDT)
Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2270120B64 for <tls@ietf.org>; Thu, 5 Sep 2019 14:36:53 -0700 (PDT)
Received: by mail-oi1-x22f.google.com with SMTP id v7so3236121oib.4 for <tls@ietf.org>; Thu, 05 Sep 2019 14:36:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; 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; d=1e100.net; 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: <20190830222401.GR84368@kduck.mit.edu> <948a07a6-87b1-9f91-d0a6-fa83a7a25e3d@cs.tcd.ie> <20190901235840.GN27269@kduck.mit.edu> <CABcZeBNuTcLSrvrhxmpOPKBxPab1UZPs4t5jc-ie8GzMqmUkLA@mail.gmail.com> <CAL02cgQbQNPBxJ68Qos300JAiwubtc6an2+6Ud6Y3H6y_fG4AA@mail.gmail.com> <6d625160-0cb4-fc62-2529-7ff1abf16b3a@cs.tcd.ie> <CACsn0ckpkUnZBcDcAUtEOc50hto7U_yLUdWbOCUi3aMXiA4vVg@mail.gmail.com>
In-Reply-To: <CACsn0ckpkUnZBcDcAUtEOc50hto7U_yLUdWbOCUi3aMXiA4vVg@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Thu, 5 Sep 2019 17:36:39 -0400
Message-ID: <CAL02cgTd2TdCUUp7_Ctyq1bKQZyp6yfWV8g2=nUsBpN7TCpKZA@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Eric Rescorla <ekr@rtfm.com>, Benjamin Kaduk <kaduk@mit.edu>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b63c980591d51e53"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/0R7rs-omJzUZT-5bdfY_3RxbrDw>
Subject: Re: [TLS] FYI: new TLS HandshakeType allocation, from draft-ietf-perc-srtp-ekt-diet
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: Thu, 05 Sep 2019 21:37:03 -0000

On Thu, Sep 5, 2019 at 2:38 AM Watson Ladd <watsonbladd@gmail.com>; 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.,
KeyUpdate).


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

--Richard

[1] https://eprint.iacr.org/2003/254
[2] https://eprint.iacr.org/2017/664.pdf