[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [10.4.98.51]) 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 [10.4.98.11]) 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 ([10.55.1.51]) 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-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.55.144.45]
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-7.1.0.1679-8.0.0.1202-22670.006
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
GERMANY
www.bosch-si.de
www.blog.bosch-si.com
Tel. +49 711 811-58139
achim.kraus@bosch-si.com
Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B
Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn
- [TLS] draft-fossati-tls-iot-optimizations-00, 4.2… Kraus Achim (INST/ESY1)