Re: [atoca] New Version Notification for draft-barnes-atoca-escape-01.txt

[Brian Rosen <[e-mail]>]

I have reviewed this draft and have the following comments:

Overall, I think this is a helpful part in solving a large problem.  I do look forward to hearing any fallout from the discussion Art started on XML DSig, as I was unaware that there were interoperability issues with it.

The mechanism of using S/MIME, and the text describing how it is used seems clear to me.  I'm a fan of re-use, and despite the lack of support for S/MIME in some protocols that specified its use, I think here it is used appropriately and intelligently to produce an interoperable way.  I will have to go look at RFC5751to make sure we don't have any possible holes on preparing the CAP message for this process.  I get worried about trivial things like whether there must be a trailing line end at the end of the CAP message or not.

I am less enthused about the token mechanism.  There are a couple of reasons I think we need more discussion.  Let me say up front that the notion of having a trivial reject mechanism that avoids a DDoS by crypto of bad messages is a good one, so I'm more interested in finding solutions that allow us to have something like this token than in dropping it.

Forcing the alert sender to be the token inserter means there is no opportunity to have any form of transitive trust on message originators.  Using the example in the draft, a recipient would need a token list from what I expect would be a dozen U.S. federal agencies to cover what we would generically describe as a "national alert".  There is no way to have a single "U.S. Government aggregator" that could avoid this.

The token hashes have to be securely delivered to each endpoint by each originator.  This seems to me to be pretty onerous.  Clearly every endpoint has the same list of token hashes, which makes this tractable, but it does seem like a lot of mechanism will be needed to deploy.

This seems like a problem that has been solved.  What this feels like is a one time password, where the encrypt key and the decrypt keys are different.  Rather than a hash, can we really just securely pass the decrypt keys around?  Still need a hash for message integrity, but…  Maybe I'm dreaming.

I don't understand the notion (in 3.4) of allowing tokens with no signatures.  

I don't understand the notion (in 4.1) of a list of tokens.  At first, I thought that you start with a list, but choose one.  Alas, it says create a header for each of the tokens in the list.  What is that doing?

If you allow an intermediary to sign, wouldn't you want to include a token?  Would we not get back to the problem the token solves without that?  But, really, why would an intermediary sign? What would that get us?  In the past, when we have talked about intermediaries signing, it was part of a transitive trust model.  The tokens break that model.  So, if we have tokens, what is an intermediary signature used for?

Finally, I was reminded, looking at the example, why we need an area affected mechanism in some form of wrapper -- the CAP one is not processable by automatons and we need to have successive filtering on area affected to make the distribution mechanisms work.  That got me thinking of whether that, and possibly also other wrapper data needed to be protected, and thus how would it affect this mechanism.

Brian

On Sep 10, 2012, at 11:43 PM, Richard Barnes <[e-mail]> wrote:

> Dear ATOCA,
> 
> In order to respond to the chairs' call for candidate alert format documents, we have put together a revision of draft-barnes-atoca-escape.  As you may recall from earlier versions, ESCAPE uses S/MIME to wrap a CAP document, in order to add authentication for alert originators (digital signature and "alert token").  
> 
> The changes from -00 are largely to add more explanatory text, and clarify a few things technically. We haven't translated the whole thing to JOSE (yet).  Mostly, our hope is that in reading the new version, you'll be able to envision how these secure alerts can be used to build an overall alerting system.  For example, they highlight some of the things that a discover / metadata protocol might need to provide (e.g., public keys for authorities).
> 
> Comments very welcome.  There's even a list of open questions at the front!
> 
> Thanks a lot,
> --Richard
> 
> 
> 
> On Sep 10, 2012, at 11:38 PM, [e-mail] wrote:
> 
>> 
>> A new version of I-D, draft-barnes-atoca-escape-01.txt
>> has been successfully submitted by Richard Barnes and posted to the
>> IETF repository.
>> 
>> Filename:	 draft-barnes-atoca-escape
>> Revision:	 01
>> Title:		 Encoding of Secure Common Alert Protocol Entities (ESCAPE)
>> Creation date:	 2012-09-11
>> WG ID:		 Individual Submission
>> Number of pages: 17
>> URL:             http://www.ietf.org/internet-drafts/draft-barnes-atoca-escape-01.txt
>> Status:          http://datatracker.ietf.org/doc/draft-barnes-atoca-escape
>> Htmlized:        http://tools.ietf.org/html/draft-barnes-atoca-escape-01
>> Diff:            http://www.ietf.org/rfcdiff?url2=draft-barnes-atoca-escape-01
>> 
>> Abstract:
>>  Recipients of emergency alerts need to be able to verify that an
>>  alert they receive was issued by an authorized source.  The Common
>>  Alerting Protocol (CAP) provides a standard way of encoding alert
>>  information, but does not provide any security features that would
>>  support authentication of alert originators.  This document describes
>>  a security wrapper for Common Alerting Protocol objects to allow
>>  alerts to be signed by alert originators.
>> 
>>  Please send feedback to the [e-mail] mailing list.
>> 
>> 
>> 
>> 
>> The IETF Secretariat
>> 
> 
> _______________________________________________
> atoca mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/atoca