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

[Art Botterell <[e-mail]>]

Thanks, Brian, that's helpful.  Sounds like it might require a bit of infrastructure to pre-distribute the hashes... is this actually the most efficient way to defend against DDoS attacks involving digital signatures?

If so, I'm thinking CAP alerts might not be the most likely or even the most critical place where this mechanism might be needed.  Isn't this a general vulnerability of any system that uses signatures?  

If so, might a defensive mechanism be worth developing on its own, as an extension or adjunct to RFC3275, rather than associating it narrowly with a particular application?

- Art

On Sep 11, 2012, at 1:22 PM, Brian Rosen wrote:

> Art
> 
> I think I can explain it.
> 
> Verifying a digital signature that uses public key crypto is expensive.  A convenient DoS attack on a client would be to forge a set of alerts that are just nonsense, but appear to be valid.  The client has to check the signature to discover that it's bad, using lots of cycles to do that.
> 
> The token provides a short cut to checking the signature that uses far fewer cycles.   Both ends have the token hash.  The sender includes the token value, which prior to sending it, was known only to the sender.  The recipient runs the hash algorithm on the value to see if it matches one of the hashes it knows.  The tokens are one time use, so a replay is not possible.
> 
> The token scheme is not foolproof because an attacker might be able to forge a token value that matches the hash (it could know all the hashes, since it might be a recipient too). Thus, you use the hash test to do trivial discard, and then if you have something that the token check says is valid, then you do the real public key signature check to make sure it's valid.
> 
> Brian
> 
> On Sep 11, 2012, at 3:36 PM, Art Botterell <[e-mail]> wrote:
> 
>> Hi Martin -
>> 
>> Not sure how one might implement digital signatures of XML without canonicalization, really, but if that "accepted wisdom" is correct, wouldn't that better be addressed by refinement or replacement of RFC3275 rather than vectoring off into development of a "splinter" specification?
>> 
>> I do observe that all the various implementers of IPAWS-compatible systems in the US have had to implement XML signatures and seem to have managed without undue difficulty.  Perhaps the available libraries have improved.
>> 
>> And I'm not clear on what it is that tokens would optimize, but hopefully Richard can explain that.
>> 
>> - Art
>> 
>> 
>> On Sep 11, 2012, at 10:01 AM, Martin Thomson wrote:
>> 
>>> Art,
>>> 
>>> It is generally accepted wisdom (in the IETF at least) that XML DSig
>>> [RFC3275] is a recipe for interoperability failure.  The primary
>>> reason for this is the dependency on XML canonicalization.
>>> 
>>> I'd be interested in hearing a different perspective.  I've used the
>>> apache library to implement an enveloped signature and it wasn't
>>> straightforward.  I'm not aware of any other implementation, but it's
>>> been a few years since I last looked.
>>> 
>>> Of course, it's a different thing to say the mechanism is broken or
>>> unusable rather than "there is no mechanism".  The former statement
>>> requires greater justification.
>>> 
>>> I'll let Richard explain the token mechanism.  It's an optimization.
>>> 
>>> --Martin
>>> 
>>> On 10 September 2012 22:20, Art Botterell <[e-mail]> wrote:
>>>> Hi Richard -
>>>> 
>>>> I'm confused by the claim that CAP "does not provide any security features that would support authentication of alert originators."
>>>> 
>>>> Section 3.3.4.1 of the OASIS CAP 1.2 specification says "The <alert> element of a CAP Alert Message MAY have an Enveloped Signature, as described by XML-Signature and Syntax Processing," and makes reference to both <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/ > and <http://www.ietf.org/rfc/rfc3275.txt>.
>>>> 
>>>> Indeed, XMLSIG has been a feature of every CAP version since 1.0.  And if that's not enough, there's also the existing OASIS EDXL-DE wrapper specification.
>>>> 
>>>> So while I'm a huge supporter of an end-to-end approach to CAP authentication, on the face of it the ESCAPE draft seems duplicative and somewhat ill-informed.  Also I fear I'm missing the point of the added "alert token" mechanism, other than to add one more maintenance task that nobody is going to want to own.
>>>> 
>>>> But possibly you've just leapt ahead too far for me to follow in a single bound.  What am I missing here?
>>>> 
>>>> - Art
>>>> 
>>>> 
>>>> On Sep 10, 2012, at 8:43 PM, Richard Barnes 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
>>>> 
>>>> _______________________________________________
>>>> atoca mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/atoca
>> 
>> _______________________________________________
>> atoca mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/atoca
>