Re: [TLS] Integrity bounds in DTLS

Martin Thomson <mt@lowentropy.net> Fri, 15 May 2020 00:51 UTC

Return-Path: <mt@lowentropy.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 0B0AF3A0820 for <tls@ietfa.amsl.com>; Thu, 14 May 2020 17:51:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-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=lowentropy.net header.b=BVJKJaJK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=iqBOWmFN
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 8bT9KElr8IK3 for <tls@ietfa.amsl.com>; Thu, 14 May 2020 17:51:28 -0700 (PDT)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DF013A0814 for <tls@ietf.org>; Thu, 14 May 2020 17:51:28 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 406602C0 for <tls@ietf.org>; Thu, 14 May 2020 20:51:25 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Thu, 14 May 2020 20:51:25 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=lo6lc1HXVOPCOsra1sKY9KpugKrFzEO 4OmCtj9Qmtyw=; b=BVJKJaJKDGu64frjE46xN+yoz3goBX1Na7Z2WEbtZs7Intj /1/SbHhsc4HgNMMO/3ekE9RcHRt59ysYfrFIALEpfP7I3aqY2VRo84F+/5KnhUe+ Y0dHe3cf3AQ0zj3i9p8vB/eG2Xl93HMTI/9LDRXxfJ2sDv9LinNMzr2LwzTe0Mtl xVRMSdkf2a9YT9WaeGLQ56AESnGi4lTC8wW+RllxwH4Gsb9vgjxeqOkuXwSwJCyA TmORRr4cfYcaS+kf1oiEHWnyE/OziS64f8bkixrkFfSKe/0fr66Fj1LUBMmgukaD ImgCOsTOyKO/66XYtasxgJApJwFMeN6e5FjppSA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=lo6lc1 HXVOPCOsra1sKY9KpugKrFzEO4OmCtj9Qmtyw=; b=iqBOWmFNAqUW4C1JQTF8Gt rotOO+bgTOQAJW2H6jvQEQN+PutuzFZK7wZ8XTJ+o/agoEZ00pBWZi9RM7KRmwwx +ljX2lrAakjNN/CeEfoea36aU0w5MMmGrOQZQ3itSnOUGLxxQdqRWFM7YHJgKb52 P6Mc8U2R7T6+oxD7v+s7SuzMthjO9og4aMQIdZ5XMQLZnIA+7GXjsYU3sqpHxZTf DmlaqhZsmtl+Bc1mpuVIG80qSHYvN4VfQtCm/b+WMOuGtcEm8GiWavQYuYMWesga TKX8n+nXgyzboapYbteSe5oJ+E7XBP3nPGuJsAHnq14viFvhs6BrLNzEW9+1VQZg ==
X-ME-Sender: <xms:jOe9XoIhSx8PgOlszpoeNkKAUlbweuVgkoLzDUauB-T3dDqe-So7kg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrleejgdefudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnheptdeghfekgeffhfetfeejke evfeetheehleegheehveelfeetfeeikeefgfejvdegnecuffhomhgrihhnpehgihhthhhu sgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:jOe9XoIs5rp3UBE73FReAwEWUeNDF58qoXQXwroZnhbqGv7Zt8pQYA> <xmx:jOe9XosXNhsES_F9zCX_vnAsWnh2K-Ul-3IZ-cbCvQi2pksiCXPjhg> <xmx:jOe9XlZUNrLSi6xFQcNHNyg6mhw0vQQCTdUHBUxRkONksacijzKcog> <xmx:jOe9Xnou3IKrOkmOxihSUxyMOmKvJCYVu4nXnsp70WZxuyBDDx8NXQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8BDB0E0128; Thu, 14 May 2020 20:51:24 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-413-g750b809-fmstable-20200507v1
Mime-Version: 1.0
Message-Id: <c1097fbc-40aa-493b-9857-992fecc48107@www.fastmail.com>
In-Reply-To: <cb6dab6a-54dc-484d-80a4-ec16a25fcdea@www.fastmail.com>
References: <0a9e740f-c20a-4def-9a61-d256cbcbf07c@www.fastmail.com> <cb6dab6a-54dc-484d-80a4-ec16a25fcdea@www.fastmail.com>
Date: Fri, 15 May 2020 10:51:06 +1000
From: Martin Thomson <mt@lowentropy.net>
To: tls@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/3oTTscKi6ytH9yo0fw_UwAvG528>
Subject: Re: [TLS] Integrity bounds in DTLS
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, 15 May 2020 00:51:31 -0000

Continuing the trend where I am the only one to post to this thread...

I just posted a proposal:

https://github.com/tlswg/dtls13-spec/pull/147

This is essentially a transcription of the work done for QUIC to DTLS.  There is one major change, in the addition of TLS_AES_128_CCM_8_SHA256.  QUIC prohibits the use of this cipher suite, so it doesn't have to worry about it.  The proposed text does not define limits for this cipher, essentially suggesting that it's not good for general use.

My personal conclusion is that this suite is fine for use in TLS, but unless we dramatically revise our expectations, it's no good for DTLS.  To that end, I'd be happier prohibiting the use of this cipher suite outright in DTLS.  I didn't put that in the proposal as I believe that would be counter to our established position, which is that this is not generally recommended, but it might have specialized uses in which it is OK.  The proposal therefore attempts to hedge by saying that you need special circumstances and further analysis before using it.

So I see two paths and one maybe option:

1. Prohibit use of TLS_AES_128_CCM_8_SHA256 in DTLS.
2. Allow TLS_AES_128_CCM_8_SHA256 in DTLS under special circumstances (the PR).
3. An unspecified proposal that allows TLS_AES_128_CCM_8_SHA256 more generally somehow.