<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p><br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 4/10/2017 1:38 PM, Shumon Huque
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAHPuVdUOaKxUOKR0kwt_iYTNZQd-UoffXozHshM25HQ1Eg0gTQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">On Mon, Apr 10, 2017 at 4:06 PM,
            Daniel Kahn Gillmor <span dir="ltr"><<a
                moz-do-not-send="true"
                href="mailto:dkg@fifthhorseman.net" target="_blank">dkg@fifthhorseman.net</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex"><span class="gmail-">...</span></blockquote>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex">
              <br>
              For TLS 1.2 and earlier (i.e. all formalized versions of
              TLS today) the<br>
              client certificate is visible in the clear over the
              network during the<br>
              handshake.  This exposes your client's individual location
              information<br>
              to any passive network monitor, which is not a good thing
              for a protocol<br>
              that is intended to enhance user privacy.<br>
            </blockquote>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Yes. That's why TLS client authentication is probably a bad idea.
    The identity leak is kinda fixed in TLS 1.3, but only if the client
    refuses to negotiate down to 1.2, and that's not practical.<br>
    <br>
    <blockquote
cite="mid:CAHPuVdUOaKxUOKR0kwt_iYTNZQd-UoffXozHshM25HQ1Eg0gTQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">...
            <div>Does TLS 1.3 protect the client certificate? To
              Christian's question about </div>
            <div>alternatives to per-client certificate authentication
              in TLS, there are a few, but </div>
            <div>they are unfortunately seldom used today (Pre-shared
              key; SRP; Kerberos - </div>
            <div>spec deprecated; OpenPGP keys, etc). At the DNS layer,
              per-client authentication </div>
            <div>is possible with GSS-TSIG, but it's very complex to set
              up.<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Pretty much all the TLS client authentication schemes share the
    "identity leak in clear text" issue that DKG is mentioning. If we
    really need client auth, we need to look at a DNS level solution, or
    maybe DNS over TLS specific solution. If GSS-TSIG works, that may be
    it. If it doesn't, maybe use something else, like some TBD EDNS
    transaction. But first, we have to be really convinced that we do
    need client auth!<br>
    <br>
    -- Christian Huitema<br>
  </body>
</html>