Subject: [Json] Stephen Farrell's No Objection on draft-ietf-json-text-sequence-11: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Mon, 15 Dec 2014 05:52:20 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-json-text-sequence-11: 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.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- abstract: 2nd 0x1E should be 0x0A I guess. That really
needs fixing so could well be a DISCUSS but is probably
so obvious it'll happen without that:-) But let me know
if you prefer this be a DISCUSS for tracking purposes.

- 2.1 doesn't say anything about 0x00 which often creates
security issues. Worth a note? Not sure myself. 

- 2.2: thanks for the  ctrl-^ info - that's good. Would it be
worth adding that in e.g. vim/vi you should precede that
ctrl-^ with ctrl-v so as to get the right value into your
file?

- 2.3: I think SHOULD NOT abort is too strong - did the wg
consider saying they SHOULD or MAY abort and giving the log
example as a counter example? It just seems safer to me if
the default behaviour is to abort. However, I'm not that
certain of this point, so this isn't a discuss.

- section 3: 2nd sentence, I think what you really should be
saying is that parsing one of these does not necessarily give
you a good input to a MAC or signature verification process
as you might or might not still have canonicalisation issues. 

- section 3: I think you ought mention the potential here for
careless code to be vulnerable to buffer overruns. We've seen
that too often to ignore it I'd argue.

- Most of the above plus a few others are also noted in
the secdir review [1]. I'm sure the author/shepherd/AD 
will engage with the reviewer there too. 

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05300.html

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 15 Dec 2014 21:15:04 +0000

Thanks, Stephen.

If this gets marked as update needed, I'll make sure all the comments are addressed before it proceeds.  I think the author is motivated to do this quickly.

Thanks,
Kathleen 

Sent from my iPhone

> On Dec 15, 2014, at 1:52 PM, "Stephen Farrell" <[email-masked]> wrote:
>

---

From: Pete Resnick <[email-masked]>
Date: Mon, 15 Dec 2014 15:51:37 -0600

> If this gets marked as update needed, I'll make sure all the comments are addressed before it proceeds.  I think the author is motivated to do this quickly.

Kathleen, much as I would be delighted for you to make sure all the 
comments are addressed, I think you are confusing this document with 
draft-joseffson. :-) (How amusing that we have draft-ietf-json..., 
draft-ietf-jose..., and draft-joseffson..., all on the same telechat.)

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Nico Williams <[email-masked]>
Date: Mon, 15 Dec 2014 17:26:42 -0600

Will fix after the telechat.

> security issues. Worth a note? Not sure myself. 

Not sure.  We could list all the byte values that are not permitted, but
yes, NUL is the most interesting one as far as security bugs go.

> ctrl-^ with ctrl-v so as to get the right value into your

Sure.

> certain of this point, so this isn't a discuss.

Pete Resnick also wants this to not be "SHOULD NOT".  It should be fine
to make it OPTIONAL to continue (though it's desirable for some apps).

> as you might or might not still have canonicalisation issues. 

That's... not what I was trying to say, though I agree that there is no
canonical form for this format, just as there isn't for JSON itself (why
doesn't RFC7159 say this?  oh well).

> that too often to ignore it I'd argue.

Well, I didn't want to list all of those sorts of bugs.  It should
suffice to say that the input is as good as untrusted.

If there's boilerplate for all the types of bugs worth mentioning, let
me know.  (If there isn't then maybe there should be.  In any case, it's
not just buffer overflows.  There could be integer overflows, double
frees and other dangling pointer dereferencing, null pointer
dereferencing, and other bugs.)

>    [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05300.html

I'll respond to that separately.

Thanks,

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 15 Dec 2014 23:28:53 +0000

All good, just on this bit...

> dereferencing, and other bugs.)

Sadly not that I know of. If you happen to know of a
victim^H^H^H^H^Hvolunteer do let me know:-)

S.

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 15 Dec 2014 23:28:55 +0000

Sorry, I'll go back to being on vacation now :-)

Sent from my iPhone

> On Dec 15, 2014, at 9:51 PM, Pete Resnick <[email-masked]> wrote:
> 
> Kathleen, much as I would be delighted for you to make sure all the comments are addressed, I think you are confusing this document with draft-joseffson. :-) (How amusing that we have draft-ietf-json..., draft-ietf-jose..., and draft-joseffson..., all on the same telechat.)
> 
> pr
> 
> --

---

From: John Cowan <[email-masked]>
Date: Mon, 15 Dec 2014 19:10:24 -0500

> victim^H^H^H^H^Hvolunteer do let me know:-)

Since someday it may happen that a victim must be found,
I've got a little list,
I've got a little list ....

-- 
John Cowan          http://www.ccil.org/~cowan        [email-masked]
In the sciences, we are now uniquely privileged to sit side by side
with the giants on whose shoulders we stand.  --Gerald Holton