<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    It is great that we are identifying places to improve support for
    Rust in Tor. <br>
    <br>
    Along this same line of thinking, are there other places in Tor
    where we will need to move to supporting UTF-8? For example, should
    the statefile be UTF-8 also? <br>
    <br>
    <div class="moz-cite-prefix">On 11/13/2017 01:51 PM, Nick Mathewson
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAKDKvuwwwSqozqdm1+4jMQkE9VgRJPz0jvisuhWBLwXU_JJqUg@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>Filename: 285-utf-8.txt</div>
        <div>Title: Directory documents should be standardized as UTF-8</div>
        <div>Author: Nick Mathewson</div>
        <div>Created: 13 November 2017</div>
        <div>Status: Open</div>
        <div><br>
        </div>
        <div>1. Summary and motivation</div>
        <div><br>
        </div>
        <div>   People frequently want to include non-ASCII text in
          their router</div>
        <div>   descriptors.  The Contact line is a favorite place to do
          this, but in</div>
        <div>   principle the platform line would also be pretty
          logical.</div>
        <div><br>
        </div>
        <div>   Unfortunately, there's no specified way to encode
          non-ASCII in our</div>
        <div>   directory documents.</div>
        <div><br>
        </div>
        <div>   Fortunately, almost everybody who does it, uses UTF-8
          anyway.</div>
        <div><br>
        </div>
        <div>   As we move towards Rust support in Tor, we gain another
          motivation</div>
        <div>   for standarding on UTF-8, since Rust's native strings
          strongly prefer</div>
        <div>   UTF-8.</div>
        <div><br>
        </div>
        <div>   So, in this proposal, we describe a migration path to
          having all</div>
        <div>   directory documents be fully UTF-8.</div>
        <div><br>
        </div>
        <div>2. Proposal</div>
        <div><br>
        </div>
        <div>   First, we should have Tor relays reject ContactInfo
          lines (and any</div>
        <div>   other lines copied directly into router descriptors)
          that are not</div>
        <div>   UTF-8.</div>
        <div><br>
        </div>
        <div>   At the same time, we should have authorities reject any
          router</div>
        <div>   descriptors or extrainfo documents that are not valid
          UTF-8.</div>
        <div>   Simultaneously, we can have all Tor instances reject all</div>
        <div>   non-directory-descriptor directory documents that are
          not UTF-8,</div>
        <div>   since none should exist today.</div>
        <div><br>
        </div>
        <div>   Finally, once the authorities have updated, we should
          have all Tor</div>
        <div>   instances reject all directory documents that are not
          UTF-8.  (We</div>
        <div>   should not take this step until the authorities have
          upgraded, or</div>
        <div>   else the behavior of updated and non-updated clients
          could be</div>
        <div>   distinguished.)</div>
        <div><br>
        </div>
        <div>2.1. Hidden service descriptors' encrypted bodies</div>
        <div><br>
        </div>
        <div>   For the encrypted bodies of hidden service descriptors,
          we cannot</div>
        <div>   reject them at the authority level, and so we need to
          take a slightly</div>
        <div>   different approach to prevent client fingerprinting
          attacks.</div>
        <div><br>
        </div>
        <div>   First, we should make Tor instances start warning about
          any hidden</div>
        <div>   service descriptors whose bodies, post-decryption,
          contain non-utf-8</div>
        <div>   plaintext.  At the same time, we add a consensus
          parameter to</div>
        <div>   indicate that hidden service descriptors with non-utf-8
          plantexts</div>
        <div>   should be rejected entirely:
          "reject-encrypted-non-utf-8".  If that</div>
        <div>   parameter is set to 1, then hidden service clients will
          not only</div>
        <div>   warn, but reject the descriptors.</div>
        <div><br>
        </div>
        <div>   Once the vast majority of clients are running versions
          that support</div>
        <div>   the "reject-encrypted-non-utf-8" parameter, that
          parameter can be set</div>
        <div>   to 1.</div>
        <div><br>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
tor-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a>
<a class="moz-txt-link-freetext" href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>