Re: [secdir] Fwd: RE: Stephen Farrell's No Objection on draft-ietf-xrblock-rtcp-xr-discard-14: (with COMMENT)

No promise, I'll try.

Tnx!

Sent from my iPad

On Jun 26, 2013, at 6:14, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

> 
> Anyone interested in thinking about whether there might be
> side-channels caused by xrblock? [1] Or even in just giving
> them a general presentation on side-channels to help 'em
> figure out if they think there's an issue or not?
> 
> Once the meeting schedule is firmed up I'll maybe ask on
> saag but if someone here is interested in helping 'em
> just let me know.
> 
> Ta,
> S.
> 
> [1] http://tools.ietf.org/wg/xrblock/charters
> 
> 
> -------- Original Message --------
> Subject: RE: Stephen Farrell's No Objection on
> draft-ietf-xrblock-rtcp-xr-discard-14: (with COMMENT)
> Date: Wed, 26 Jun 2013 10:06:00 +0000
> From: Romascanu, Dan (Dan) <dromasca@avaya.com>
> To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, The IESG <iesg@ietf.org>
> CC: xrblock-chairs@tools.ietf.org <xrblock-chairs@tools.ietf.org>,
> draft-ietf-xrblock-rtcp-xr-discard@tools.ietf.org
> <draft-ietf-xrblock-rtcp-xr-discard@tools.ietf.org>
> 
> Hi,
> 
> If this is a generic problem that can possibly impact several xrblock
> documents, maybe we can have a security expert (a.k.a. co-ponderer)
> attend the XRBLOCK meeting and discuss the issue with us. We seem to
> have a pretty light wg agenda in Berlin, so it won't be a problem to
> find time on it.
> 
> Thanks and Regards,
> 
> Dan
> 
> 
> 
> 
>> -----Original Message-----
>> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
>> Sent: Tuesday, June 25, 2013 8:01 PM
>> To: The IESG
>> Cc: xrblock-chairs@tools.ietf.org; draft-ietf-xrblock-rtcp-xr-
>> discard@tools.ietf.org
>> Subject: Stephen Farrell's No Objection on draft-ietf-xrblock-rtcp-xr-
>> discard-14: (with COMMENT)
>> 
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-xrblock-rtcp-xr-discard-14: No Objection
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> 
>> Sam Hartman's secdir review [1] of xr-discard-rle-metrics raised a good
>> question that's probably better asked here, or here as well. I'm not
>> asking for any change in this or any specific xrblock document, but I
>> would ask that the WG do consider this. Sam said:
>> 
>> "Has the WG analyzed implications of providing feedback to an attacker
>> on what specific SRTP packets are discarded?  In the past we've run into
>> trouble with security systems that were too verbose in error reporting.
>> As an example, in certain public-key crypto constructions knowing
>> whether a packet produced a decoding error vs a signature error after
>> decryption can provide an attacker generating forged packets valuable
>> information to attack the system.
>> 
>> It's quite possible that SRTP doesn't have problems in this regard.  I
>> just want to confirm that the analysis has been done."
>> 
>> I think that's a good question because knowing at what stage in a
>> security protocol a message was barfed or getting timing statistics can
>> expose information about how some crypto operation went wrong, and that
>> can be exploited via statistical techniques with a sufficiently large
>> number of messages.  See for example the lucky-13 attacks against
>> certain cryptographic modes in TLS [2] or perhaps the "original" of the
>> species, the Bleichenbacher attack.  [3]
>> 
>> I suspect the best thing to do might be for the wg to try grab a
>> security person and ponder this for a bit, if that's not already been
>> done. I'm happy to try help find a co-ponderer if you want:-) Maybe we
>> can ambush one in a hallway in Berlin.
>> 
>>   [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04048.html
>>   [2] http://www.isg.rhul.ac.uk/tls/Lucky13.html
>>   [3] https://en.wikipedia.org/wiki/Adaptive_chosen-ciphertext_attack
> 
> 
> 
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview