Last Call Review of draft-ietf-tram-stun-origin-05
review-ietf-tram-stun-origin-05-opsdir-lc-chown-2015-04-26-00

Hi,

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

I would summarise this document as being Not Ready.

My concern with the draft lies with privacy aspects. While the area is not one
that I am particularly familiar with, but there would seem to be additional
potential exposure through this method, and the language of the draft seems at
odds with the language in RFC6454 (Section 7.3). I would therefore urge the AD
to review this aspect, and to determine whether the utility of the draft
outweighs the privacy concerns, and if it does, that appropriate privacy
‘knobs’ are included for those who are ‘privacy-sensitive’ (in the language of
RFC6454).

I think the rationale and tradeoffs could be more clearly stated in the
document. With recent passive pervasive monitoring threats, the IETF is now
supposed to be considering whether  given information *needs* to be transmitted
in any given protocol.

Would I as a user, for example, be able to toggle a setting that would mean my
ORIGIN would always be “null”, as per RFC6454 section 7.3? Is the use of ORIGIN
*required*, or is it just ‘desirable’? Would my application fail, or not? It
appears from Section 1 that its inclusion is ‘useful’, but not required.

Section 4 talks of TLS for avoiding eavesdropping of ORIGIN in STUN messages,
but the privacy concern is not necessarily only with transmission of the
information. I think here paragraph 3 of Section 4 is at odds with RFC6454
Section 7.3 - with this draft saying MAY wrt use of a “null” Origin, and
RFC6454 saying MUST for use of “null”. The same applies to the end of the last
paragraph in Section 4 as well.

The draft should probably use the ‘privacy-senstive’ context terminology of
RFC6454, as per Section 7.3, and describe how the user can influence the
privacy settings where they which to maximise their privacy.

Tim