[Atoca] Remarks on the security discussion today

Hannes Tschofenig <Hannes.Tschofenig@gmx.net> Thu, 31 March 2011 19:34 UTC

Return-Path: <Hannes.Tschofenig@gmx.net>
X-Original-To: earlywarning@core3.amsl.com
Delivered-To: earlywarning@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id D4A913A6BA1 for <earlywarning@core3.amsl.com>; Thu, 31 Mar 2011 12:34:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.42
X-Spam-Status: No, score=-102.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 1IYdR2V6QQT9 for <earlywarning@core3.amsl.com>; Thu, 31 Mar 2011 12:34:16 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net []) by core3.amsl.com (Postfix) with SMTP id 755763A6B94 for <earlywarning@ietf.org>; Thu, 31 Mar 2011 12:34:15 -0700 (PDT)
Received: (qmail invoked by alias); 31 Mar 2011 19:35:52 -0000
Received: from dhcp-924f.meeting.ietf.org (EHLO dhcp-924f.meeting.ietf.org) [] by mail.gmx.net (mp008) with SMTP; 31 Mar 2011 21:35:52 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/MJAcaVzbMFGLbSr4s1jhvkTpsncupNE4t0uldu0 5lHpbwpXMOg6Cu
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Thu, 31 Mar 2011 21:35:48 +0200
Message-Id: <AB512223-EEE5-4105-99C9-305603FEE080@gmx.net>
To: earlywarning@ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-Y-GMX-Trusted: 0
Cc: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Subject: [Atoca] Remarks on the security discussion today
X-BeenThere: earlywarning@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." <earlywarning.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/earlywarning>, <mailto:earlywarning-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/earlywarning>
List-Post: <mailto:earlywarning@ietf.org>
List-Help: <mailto:earlywarning-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/earlywarning>, <mailto:earlywarning-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Mar 2011 19:34:18 -0000

Hi all, 

in the discussions today a few interesting remarks were raised. I wanted to share them with you. Richard, Martin and Cullen listed two aspects that need to be described in the requirements/architecture document, namely 

(1) How does the recipient/receiver learn which author/originator to trust?

In this case Richard distinguished two scenarios:

a) Tsunami warning

Here the warning may be provided to the recipient/receiver by some local entity. How does the author/originator know when it receives an alert that can indeed be trusted? It could be sent by anyone. It is not very likely that the author of the message is known.

For this specific case Richard suggested to build on the work in draft-rosen-ecrit-lost-early-warning-01.txt. The basic idea is that the receiver uses LoST to discovers organizations issuing alerts for specific geographical regions. When an alert is received then the author and/or originator fields are checked against the info previously obtained via LoST. 

b) School closed warning

Here, the recipient will have a prior relationship with the author (the school). A prior "registration" step is likely going to be required. 

(2) Transitive Trust vs. End-to-End Security

In order to ensure that the comparison between the identity information can be processed by the recipient/receiver there is a need for cryptographic assurance. During the meeting we had discussed the possibility to use transitive trust (I know my service provider and I assume that he will only accept and forward alerts it got from other trusted sources) and end-to-end security. 

In the area of end-to-end security it was noticed that the deployment reality of SIP (and XMPP) with regard to e2e security is rather weak. Security at the alert level was seen as OK but XMLDSIG was not acceptable. 

I hope my writeup makes sense (even though I am tired already).