[TLS] draft-fossati-tls-iot-optimizations-00, 4.2, hash chain

"Kraus Achim (INST/ESY1)" <Achim.Kraus@bosch-si.com> Mon, 31 October 2016 14:00 UTC

Return-Path: <Achim.Kraus@bosch-si.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B50411295A8 for <tls@ietfa.amsl.com>; Mon, 31 Oct 2016 07:00:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id dkQhPTt_P8uz for <tls@ietfa.amsl.com>; Mon, 31 Oct 2016 07:00:10 -0700 (PDT)
Received: from smtp6-v.fe.bosch.de (smtp6-v.fe.bosch.de [IPv6:2a03:cc00:ff0:100::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E50712957D for <tls@ietf.org>; Mon, 31 Oct 2016 07:00:10 -0700 (PDT)
Received: from vsmta11.fe.internet.bosch.com (unknown []) by imta23.fe.bosch.de (Postfix) with ESMTP id 2DA671580214 for <tls@ietf.org>; Mon, 31 Oct 2016 15:00:08 +0100 (CET)
Received: from IMBVW2EXC00.bosch-si.com (vsgw22.fe.internet.bosch.com []) by vsmta11.fe.internet.bosch.com (Postfix) with ESMTP id AA4C52380B3C for <tls@ietf.org>; Mon, 31 Oct 2016 15:00:07 +0100 (CET)
Received: from IMBPW2EXD01.bosch-si.com ([fe80::d052:f355:928e:e5ba]) by IMBVW2EXC00 ([]) with mapi id 14.03.0319.002; Mon, 31 Oct 2016 15:00:36 +0100
From: "Kraus Achim (INST/ESY1)" <Achim.Kraus@bosch-si.com>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: draft-fossati-tls-iot-optimizations-00, 4.2, hash chain
Thread-Index: AdIzfyQac8NCX80aRqKr1I0Ot73Xdg==
Date: Mon, 31 Oct 2016 14:00:34 +0000
Message-ID: <BC36447FF5C62E46BEF3F124D3C1E8925E1F5C62@imbpw2exd01.bosch-si.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-
X-TMASE-MatchedRID: rRVXzim0CnrC/uSBpQr0lrThj82FPFSC6XgeomAFiRwcQXgzaVXEcnLA QqCJeWM9tIiQ8jiM3T3IFr6H5/HEpiYw947zyArgsyNb+yeIRAqfll4kkeCNba+WgCcaviqGyl3 4Qjxod9W7vD2NKQ+RHMUqW9NkGq/HePs/Cx1DJd1mVHNo7XGknS4tncCojEfcsoddizCZ8tWzMh qIZZH9F6qifjszwIdDqNhuFB/lXK9XKXIMqa7kQtD3C6F7IetUQZXZg2I8JabZxX/W2g+Ev67xW EOiLago/nE2I3N9Ii0vN0bLeC1Afpja5QCEBu6/ngIgpj8eDcCEYGTT/umyEsRB0bsfrpPIcSqb xBgG0w6+8wA2LMF0OZK8pp4Oq944R7FXjYA1rXJS0txVuPtQXQtjCsSsG3vOyMbDtjYtkzL5Luk vluyPAb/TcyWTBwHSM5I5S2mEFBjeloC7shIVXg6WpWKKS2rRYyaijWogO/1SB/rCybjKWQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/xYDUDmVrnfxEINBu_Q6HRTIql9Q>
Subject: [TLS] draft-fossati-tls-iot-optimizations-00, 4.2, hash chain
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 31 Oct 2016 14:00:12 -0000

Dear Authors,

draft-fossati-tls-iot-optimizations-00 mentions in 4.2, page 5, a hash chain (Lampert, "Password Authentication with Insecure Communication"). 

Would it be possible, to get more details about that approach?

In my opinion, DTLS needs a connection id, the record is usually secured by the MAC. 
So the hash chain providing a "password" seems for me to rely on a "identity", for which the "password" should be verified. 
But that identity is missing and the verification is done with the MAC.

Use this in reverse, I could think of something as:

connection hash := H ^ record.sequence_number (connection id)
So with an incoming record {sequence_number, connection hash} you may look up, if "connection ids" hashed
"sequence_number" times results in the provided "connection hash" and then you may verify, if one of the
candidates will verify with the MAC.  Even with defining a "sequence number window" to exclude "faraway"
sessions, I'm not sure,  how such an approach would scale for a large number of session.

So could you please provide your ideas about that hash chain?

Mit freundlichen Grüßen / Best regards

Achim Kraus

Bosch Software Innovations GmbH
Communications (INST/ESY1)
Stuttgarter Straße 130
71332 Waiblingen

Tel. +49 711 811-58139

Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B
Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn