Skip to main content

Telechat Review of draft-ietf-jsonpath-iregexp-06
review-ietf-jsonpath-iregexp-06-secdir-telechat-ounsworth-2023-06-18-00

Request Review of draft-ietf-jsonpath-iregexp
Requested revision No specific revision (document currently at 08)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2023-06-20
Requested 2023-06-12
Authors Carsten Bormann , Tim Bray
I-D last updated 2023-06-18
Completed reviews Secdir Last Call review of -06 by Mike Ounsworth (diff)
Genart Last Call review of -06 by Russ Housley (diff)
Secdir Telechat review of -06 by Mike Ounsworth (diff)
Artart Early review of -03 by Shuping Peng (diff)
Assignment Reviewer Mike Ounsworth
State Completed
Request Telechat review on draft-ietf-jsonpath-iregexp by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/WyjJSMpuMz-yqhp-Ru03YqOT9TY
Reviewed revision 06 (document currently at 08)
Result Ready
Completed 2023-06-18
review-ietf-jsonpath-iregexp-06-secdir-telechat-ounsworth-2023-06-18-00
As I stated on PR #27, I am good with these changes; thank you for adding the
extra discussion to avoid people thinking that I-Regexps fully closes off these
attack threats.

---
Mike Ounsworth

-----Original Message-----
From: Carsten Bormann <cabo@tzi.org>
Sent: Thursday, May 25, 2023 5:59 AM
To: Mike Ounsworth <Mike.Ounsworth@entrust.com>
Cc: Tim Bray <tbray@textuality.com>; secdir@ietf.org;
draft-ietf-jsonpath-iregexp.all@ietf.org; jsonpath@ietf.org;
last-call@ietf.org; "Martin J. Dürst" <duerst@it.aoyama.ac.jp> Subject: Re:
[EXTERNAL] Secdir last call review of draft-ietf-jsonpath-iregexp-06

Hi Mike,

> On 2023-05-15, at 18:40, Mike Ounsworth <Mike.Ounsworth@entrust.com> wrote:
>
> If you put any sort of paragraph to that effect, then I’ll be happy.

Actually, this thread turned into a number of new paragraphs.

In PR #27 [1], new text has been added specifically about resource consumption
(time and space) based attacks.  This text is a bit longer than I wanted
because it has to distinguish the two cases I-Regexp specific implementation
vs. re-use of existing Regexp implementation, and there is no simple perfect
way to handle twisted applications of range-quantifiers.  Thanks to Martin
Dürst for preparing much of this text in his original comment.

PR #26 [2] picks up the comments made by Rob Sayre and generalizes the concerns
in a way that is useful in this specification.  We now reference STD 63 (RFC
3629), interestingly as an informative reference, as this discusses related
issues in more detail than would fit this specification.

Thank you for getting this thread started with your comment!

Comments on the two PRs will be appreciated.

Grüße, Carsten

[1]:
https://urldefense.com/v3/__https://github.com/ietf-wg-jsonpath/iregexp/pull/27__;!!FJ-Y8qCqXTj2!ftDjXHWUMZfZDAwCOB-GHJoVLwB9qCwCNfEdN01DQ4VIoLt_xMQcX2Vpig_1UCGrf5iRV4VvZlr-bTw$
[2]:
https://urldefense.com/v3/__https://github.com/ietf-wg-jsonpath/iregexp/pull/26__;!!FJ-Y8qCqXTj2!ftDjXHWUMZfZDAwCOB-GHJoVLwB9qCwCNfEdN01DQ4VIoLt_xMQcX2Vpig_1UCGrf5iRV4Vvm_Z_rb4$

Any email and files/attachments transmitted with it are confidential and are
intended solely for the use of the individual or entity to whom they are
addressed. If this message has been sent to you in error, you must not copy,
distribute or disclose of the information it contains. Please notify Entrust
immediately and delete the message from your system.