<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 1/8/2019 8:21 PM, Viktor Dukhovni
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:20190109042159.GT79754@straasha.imrryr.org">How do you
      plan to offer a built-in menu of algorithms that have not yet been
      added to OpenSSL?</blockquote>
    <p><br>
    </p>
    <p>I'm a bit confused as to why we would need to - if the underlying
      OpenSSL doesn't support a particular algorithm, then there's no
      need to disable it.</p>
    <p>The ideal would be that we ask OpenSSL what algorithms (and
      protocol versions) it supports, and we export that list to the
      user.  However, practically we've found that we couldn't do that
      even with TLS1.2, because (a) "openssl ciphers" (and the
      underlying APIs) report PSK-* and other algorithms we don't intend
      to support, and (b) the underlying OpenSSL includes support for
      algorithms that our security policies don't allow us to support. 
      Also, there's the question of whether a particular algorithm or
      protocol version is supported but disabled by default, or enabled
      by default.  For instance, today we support TLS 1.0, 1.1, and 1.2,
      but 1.0 is disabled by default.  That's a policy question that
      OpenSSL can't help us with.<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
      cite="mid:20190109042159.GT79754@straasha.imrryr.org"> And if
      users are better off leaving the list alone, why encourage that
      with a fancy UI?
    </blockquote>
    <p><br>
    </p>
    <p>That's a good question, but at the same time we have a high-level
      UI policy that we don't offer "non-fancy" UIs.</p>
    <p><br>
    </p>
    <p>
    </p>
    <blockquote type="cite"
      cite="mid:20190109042159.GT79754@straasha.imrryr.org">
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">However, as I think about it, I remember that we already need a
softcoded list of algorithms, to avoid offering (e.g.) the PSK
algorithms.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
In TLS 1.3, the handshake parameters are configured separately from
the cipherlist.  The use of (non-resumption) PSKs requires callbacks,
so they're never enabled out of the box.

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">It sounds like TLS 1.3 will need the same.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">Actually, it won't, nor did earlier versions, the ciphers were
listed by "openssl ciphers -v", but they can't get activated without
application support.
</pre>
    </blockquote>
    <p><br>
    </p>
    <p>Right... we found that when we blindly asked for the cipher list,
      it included ciphers that weren't actually operable because we
      didn't have the associated application support.  We had hoped to
      be able to use relatively simple rules to determine the list of
      allowable ciphers, but then found that we needed much more complex
      rules than were desirable.<br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris</pre>
  </body>
</html>