Subject: [Ecrit] Stephen Farrell's No Objection on draft-ietf-ecrit-additional-data-36: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Sun, 04 Oct 2015 14:59:59 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-ecrit-additional-data-36: 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 https://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:
https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/

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

Thanks for handling my discuss points.

-35 handled most of the stuff below just fine but I left
the comments there. I didn't check -36 for that.

- abstract: the "or by reference" point is made twice
in the abstract

- intro: floor plans? HVAC status? really? Why not
contact lists? proximity of friends? That (or
inferring as much) seems to me to be going too far, if
applied to all calls. I'd say just saying that this
could be extended in future by other standards-track
specifications is enough. (See also discuss points above)

- intro: Wedding anniversary? That's surely not
relevant to a PSAP. 

- figure 5: "prison" is out of context here, I'd suggest 
deleting it. If not, why not add hospital, power station 
and many other kinds of building? There may be some 
country specific issue or technical here, but labelling 
that with "prison" seems inappropriate to me. 

- 4.3.8: sorry I don't get the privacy argument, can
you try explain it to me?  (I didn't know it was
possible to tempt an implementation, so the language
there could be improved for sure:-)

- section 5: good that this is HTTPS only. I think
provisioning the PKI for such a thing is easily done
these days and is rightly not optional. It might be
useful to say that TLS here needs to follow BCP195.  I
agree with the earlier comment that you should be
clear as to when mutually authenticated TLS is
required. The secdir review [2] also raised similar
issues and it'd be good to see responses to that too.
(Yes, that review only arrived today so it's entirely
reasonable to not have responded so far.)

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

- section 8: the sizes of the various additional data
items here could be characteristic and leak value
information regardless of TLS or not-TLS - perhaps add
a warning that these may enable relatively simple
traffic analysis. And wouldn't it be nice if someone
had done the analysis of this potential vulnerability?
This is btw a real issue - recall that avatar icon
image size was usable to identify 30+% of contacts in
one social network even over TLS, but before the
provider canonicalised the avatar image sizes. 

- Thanks for section 9. Good job.