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

[Stephen Farrell <[e-mail]>]

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) <[e-mail]>
To: Stephen Farrell <[e-mail]>, The IESG <[e-mail]>
CC: [e-mail] <[e-mail]>,
[e-mail]
<[e-mail]>

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:[e-mail]]
> Sent: Tuesday, June 25, 2013 8:01 PM
> To: The IESG
> Cc: [e-mail]; draft-ietf-xrblock-rtcp-xr-
> [e-mail]
> 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
>