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

Brian Rosen <br@brianrosen.net> Wed, 12 September 2012 19:07 UTC

Return-Path: <br@brianrosen.net>
X-Original-To: atoca@ietfa.amsl.com
Delivered-To: atoca@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166BC21F8717 for <atoca@ietfa.amsl.com>; Wed, 12 Sep 2012 12:07:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYf+d9jbcy2E for <atoca@ietfa.amsl.com>; Wed, 12 Sep 2012 12:07:12 -0700 (PDT)
Received: from barmail6.idig.net (barmail6.idig.net [64.34.111.239]) by ietfa.amsl.com (Postfix) with ESMTP id 22CA021F870F for <atoca@ietf.org>; Wed, 12 Sep 2012 12:07:12 -0700 (PDT)
X-ASG-Debug-ID: 1347476746-0538de1033a92600001-FTS53d
Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail6.idig.net with ESMTP id 9rXy8f8PbNFgaba0; Wed, 12 Sep 2012 12:05:46 -0700 (PDT)
X-Barracuda-Envelope-From: br@brianrosen.net
X-Barracuda-Apparent-Source-IP: 76.74.186.184
Received: from neustargw.va.neustar.com ([209.173.53.233]:44729 helo=[192.168.133.194]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from <br@brianrosen.net>) id 1TBsFu-000HJF-Fn; Wed, 12 Sep 2012 12:05:46 -0700
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\))
From: Brian Rosen <br@brianrosen.net>
X-ASG-Orig-Subj: Re: [atoca] New Version Notification for draft-barnes-atoca-escape-01.txt
In-Reply-To: <49AC5E2B-2C83-4BAC-863E-685574E15F68@bbn.com>
Date: Wed, 12 Sep 2012 15:05:38 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <B04C639C-1D7C-4219-A2DF-EF2D13AEBAA3@brianrosen.net>
References: <20120911033801.16598.18619.idtracker@ietfa.amsl.com> <886749D5-885D-471F-A0B7-32DE09C69C5E@bbn.com> <6DDAB886-779C-4F0E-BE34-D80F34E5A456@incident.com> <CABkgnnWGN-GhVzx=0+Ch_H173=g7m2V43KqEtjRMm33LcZBRJw@mail.gmail.com> <22890A80-2C2D-43D4-A74D-081D35E08FFD@incident.com> <BA82C718-1AC9-4C31-99DB-11E70F3DE46E@brianrosen.net> <98484715-8F76-4B7A-BDC7-F876C9C30C8C@incident.com> <49AC5E2B-2C83-4BAC-863E-685574E15F68@bbn.com>
To: Richard Barnes <rbarnes@bbn.com>
X-Mailer: Apple Mail (2.1486)
X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184]
X-Barracuda-Start-Time: 1347476746
X-Barracuda-URL: http://64.34.111.239:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at idig.net
X-Barracuda-Spam-Score: 0.12
X-Barracuda-Spam-Status: No, SCORE=0.12 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=CN_BODY_332
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.108350 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 CN_BODY_332 BODY: CN_BODY_332
Cc: atoca@ietf.org
Subject: Re: [atoca] New Version Notification for draft-barnes-atoca-escape-01.txt
X-BeenThere: atoca@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." <atoca.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/atoca>, <mailto:atoca-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/atoca>
List-Post: <mailto:atoca@ietf.org>
List-Help: <mailto:atoca-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/atoca>, <mailto:atoca-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Sep 2012 19:07:13 -0000

I don't think you can use any of the OTP schemes that rely on either a sequence (usually time based) or a challenge.   Sequence doesn't work because there isn't a good way to maintain sync with zillions of recipients.  Challenge doesn't work because we can't have the client challenge the server for scalability reasons.

PKI does need some pre-distribution, but it's also hierarchical, so we don't need ALL the keys - if we trust a root, we only need to pre-distribute the root cert.  We can also use transitive trust.

Brian

On Sep 12, 2012, at 2:45 PM, Richard Barnes <rbarnes@bbn.com> wrote:

> Keep in mind that even for full public-key signatures, there are things to be pre-distributed.  Namely, you need to know which public keys correspond to trusted signers -- what's the public key for FEMA?  This can be partly addressed with PKI concepts, i.e., by distributing a CA certificate under which authority certificates are issued.  But there's still a process of pre-distributing some public keys.  Plus, as Andrew pointed out, using the One Time Password scheme from RFC 2289 would mean that an endpoint would only need to store one hash value per signer. 
> 
> --Richard
> 
> 
> 
> 
> On Sep 11, 2012, at 4:42 PM, Art Botterell wrote:
> 
>> 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 <acb@incident.com> 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 <acb@incident.com> 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, internet-drafts@ietf.org 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 atoca@ietf.org mailing list.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> The IETF Secretariat
>>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> atoca mailing list
>>>>>>> atoca@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/atoca
>>>>>> 
>>>>>> _______________________________________________
>>>>>> atoca mailing list
>>>>>> atoca@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/atoca
>>>> 
>>>> _______________________________________________
>>>> atoca mailing list
>>>> atoca@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/atoca
>>> 
>> 
>> _______________________________________________
>> atoca mailing list
>> atoca@ietf.org
>> https://www.ietf.org/mailman/listinfo/atoca
> 
> _______________________________________________
> atoca mailing list
> atoca@ietf.org
> https://www.ietf.org/mailman/listinfo/atoca