Re: [Cfrg] Encrypt in place guidance

Robert Moskowitz <rgm-sec@htt-consult.com> Wed, 01 April 2020 10:58 UTC

Return-Path: <rgm-sec@htt-consult.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03923A0867 for <cfrg@ietfa.amsl.com>; Wed, 1 Apr 2020 03:58:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 6c6PwzOl5ikk for <cfrg@ietfa.amsl.com>; Wed, 1 Apr 2020 03:57:59 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 2A5453A086A for <cfrg@ietf.org>; Wed, 1 Apr 2020 03:57:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id DA10B6213F; Wed, 1 Apr 2020 06:57:56 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CzWDoxAK1Hz3; Wed, 1 Apr 2020 06:57:46 -0400 (EDT)
Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 6E42C62136; Wed, 1 Apr 2020 06:57:46 -0400 (EDT)
To: Björn Haase <bjoern.haase@endress.com>, "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>, Dan Brown <danibrown@blackberry.com>, "cfrg@ietf.org" <cfrg@ietf.org>
References: <83571efb-a32f-6a59-a496-de56716f07da@htt-consult.com> <a16dcbe63aa745e482a3f435aa8e0470@blackberry.com> <f5e4c7a3-e039-ec7d-59b7-0c581d9022e6@htt-consult.com> <9ACD4ECA-CFBF-40DC-8CB8-BB7DAEFBB42D@ll.mit.edu> <d4383234-d452-dad8-52dc-dd35dbecbb8a@htt-consult.com> <95BC6180-32C1-4943-B8BC-FF40E1F6EB10@akamai.com> <AM0PR05MB478656B70C7F4AB26A6FC57A83C90@AM0PR05MB4786.eurprd05.prod.outlook.com>
From: Robert Moskowitz <rgm-sec@htt-consult.com>
Message-ID: <3134927c-9a16-ee86-69d8-fe2f9824b0e0@htt-consult.com>
Date: Wed, 01 Apr 2020 06:57:41 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <AM0PR05MB478656B70C7F4AB26A6FC57A83C90@AM0PR05MB4786.eurprd05.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------1549ACDB2E54CBF9843C1EC3"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/0dnCxNYJ5cQqN98JC2xFxjVtMXo>
Subject: Re: [Cfrg] Encrypt in place guidance
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Apr 2020 10:58:01 -0000

There is no way the basic messages are changing and expanding as long as 
BT4 is used.

There is an auth message that can carry multiple basic messages.  We 
have a draft in DRIP:

draft-wiethuechter-drip-auth

That provides message protection.  This is up to 10 chained BT4 
broadcasts.  Or 1 BT5 broadcast.

Yes, replay attacks are pretty much built into this architecture. The 
major vendors don't get it or don't care (many are chinese companies).  
The regulators just think this is ATM a little bigger.

We do what we can with what we have.  Build each message the best way 
and make sure they all work better inside the Auth wrapper.

And this does not obviate the need for privacy of the operator 
information.  That would still need to be encrypted.

All a work in progress.  Too many SDOs and regulators involved.

On 4/1/20 2:49 AM, Björn Haase wrote:
>
> I fear that you might actually need at least some more bytes of 
> payload in order to get any sound scheme realized.
>
> For preventing replay attacks a 32 bit nonce and a 32 bit 
> authentication tag might have to be considered to form the bare 
> minimum requirement ☹.
>
> We have had a similar problem with the severely size-limited 
> BluetoothLE advertising (broadcast) packets.
>
> One option that we use is segmenting the information by splitting it 
> into several packets. This way reception of two or more separate
>
> packets is needed in order to get the full information.
>
> Mit freundlichen Grüßen I Best Regards
>
> Dr. Björn Haase
>
> ------------------------------------------------------------------------
> Senior Expert Electronics | TGREH Electronics Hardware
>
> *Endress+Hauser Liquid Analysis*
>
> Endress+Hauser Conducta GmbH+Co.KG | Dieselstrasse 24 | 70839 
> Gerlingen | Germany
> Phone: +49 7156 209 377 | Fax: +49 7156 209 221
> bjoern.haase@endress.com | www.conducta.endress.com
>
> ------------------------------------------------------------------------
>
> Endress+Hauser Conducta GmbH+Co.KG
> Amtsgericht Stuttgart HRA 201908
> Sitz der Gesellschaft: Gerlingen
> Persönlich haftende Gesellschafterin:
> Endress+Hauser Conducta
> Verwaltungsgesellschaft mbH
> Sitz der Gesellschaft: Gerlingen
> Amtsgericht Stuttgart HRA 201929
> Geschäftsführer: Dr. Manfred Jagiella
>
> ------------------------------------------------------------------------
>
> Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu 
> informieren, wenn wir personenbezogene Daten von Ihnen erheben.
>
> Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis 
> <https://www.de.endress.com/de/cookies-endress+hauser-website> nach.
>
> ------------------------------------------------------------------------
>
> Disclaimer:
>
> The information transmitted is intended only for the person or entity 
> to which it is addressed and may contain confidential, proprietary, 
> and/or privileged
> material. Any review, retransmission, dissemination or other use of, 
> or taking of any action in reliance upon, this information by persons 
> or entities
> other than the intended recipient is prohibited. If you receive this 
> in error, please contact the sender and delete the material from any 
> computer.
> This e-mail does not constitute a contract offer, a contract 
> amendment, or an acceptance of a contract offer unless explicitly and 
> conspicuously designated or stated as such.
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg