[Dtls-iot] Concluding Issue #24: Replacing TLS_PSK_WITH_AES_128_CCM_8 with TLS_PSK_WITH_AES_128_CCM

Hannes Tschofenig <hannes.tschofenig@gmx.net> Fri, 31 July 2015 20:03 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 488E11ACD2A for <dtls-iot@ietfa.amsl.com>; Fri, 31 Jul 2015 13:03:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 EBCnZL7XEH0x for <dtls-iot@ietfa.amsl.com>; Fri, 31 Jul 2015 13:03:45 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94CC71ACD22 for <dtls-iot@ietf.org>; Fri, 31 Jul 2015 13:03:45 -0700 (PDT)
Received: from [192.168.131.133] ([80.92.122.31]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Meutp-1ZVuic2amv-00OTsy for <dtls-iot@ietf.org>; Fri, 31 Jul 2015 22:03:43 +0200
Message-ID: <55BBD487.4060002@gmx.net>
Date: Fri, 31 Jul 2015 22:03:19 +0200
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: "dtls-iot@ietf.org" <dtls-iot@ietf.org>
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="u5JIqIor4bWhnb25lsc7VVWestBml9v92"
X-Provags-ID: V03:K0:xHjELtgcwQ3y0dvQP+Yw4av+2hspEhRrBvvVlnDcFN98cmvREw5 S4oNZRWQP1YUsLm49PuvEXmyLckoY1HhGUxZqWp05R8MF4cL0dxgXdBGEYb0GxW0jf1kxtc uh3ZeRGn9K7dpR+VLINk7cIyf730AnsA+dKpczM09SOqxN25hn4ADxgZa8iCokfTM2j39lJ 9ZbZgeZ2P3L6hel+WEPJQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:bs0IrYRyG0A=:0sH+E7gTF3xnjRHUnMbJMd tKf6fUuq751N6l3XXhBPsJ5c43AST3KdbQRf8lE875tUEPh8QFNgGFIUNSI724my1taGdwkiw OZ8WsDrpRFQRL4FVBxdCxi4VOo7j6h1Wc97exLTwXjvS5uqEbLkNJwQQn0lnR/lb++57FKw6Q RaoftNbZPrVl8T/7mleFXIMKo3nKxsP+usI1hHKSIKBXdWZ7GezdIEmGg1kdxBBWZCBoQyuv+ gPqgcKpKq43WZQp6AZcNqBv30Rs32gDzcxhXOGhSLRX8dUY3OLSCQDSmlZR6t9cwWa1GdVXpr dulZPy8wL7JdG2wOnZ1X1i7EhAW3PGsZPK8uf0bF4VcU3C8dMAPeu/LItvQD6EHpit8N2GefV GI0Dxov4gkWn3paVjOZO8DU88Uqb+oYa8eQoqEu7KxTuP6zbjb7MQ2/dwUTChNvHmLw6eF+ay ucfHfBNnqHHAPiYh2OLgTx0aJyiRQo/ukcRSXrtZkd8kiat731pu29el9KGTAUSqRzl2KmpJ6 o1w5NGHM33vwkS2oGFoqPxeVf+ZpaH24cmgTl851ewHkTjepB99W2Nbf1qvnNOqCLZDFq32Xw /fKCaUgu36vH2/YY4uAXl6MEbX7Rh2wlkSYGRCOKiZc84F2355bBwvj0+4+oenssawBEcv8Wx 7kh//8bZxrAaOr1e1wqN+pG8Qj2N6yhnehH5v8HTV+a7CvQ==
Archived-At: <http://mailarchive.ietf.org/arch/msg/dtls-iot/Mpe2DLky9WIn5XQb6_NNuWoBU34>
Subject: [Dtls-iot] Concluding Issue #24: Replacing TLS_PSK_WITH_AES_128_CCM_8 with TLS_PSK_WITH_AES_128_CCM
X-BeenThere: dtls-iot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DTLS for IoT discussion list <dtls-iot.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtls-iot/>
List-Post: <mailto:dtls-iot@ietf.org>
List-Help: <mailto:dtls-iot-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jul 2015 20:03:47 -0000

Based on the discussion on the IRTF CFRG mailing list, see
http://www.ietf.org/mail-archive/web/cfrg/current/msg07138.html, I leave
the current recommendation unchanged.

I added a note with a reference to Section 6.2:

"
   Note that the
   shorted authentication tag increases the chance that an adversary
   with no knowledge of the secret key can present a message with a MAC
   that will pass the verification procedure.  The likelihoods of
   accepting forged data is explained in Section 5.3.5 of
   [SP800-107-rev1] and depends on the lengths of the authentication tag
   and allowed numbers of MAC verifications using a given key.
"

Ciao
Hannes