<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 7:44 PM, Viktor Dukhovni

      wrote:<br>

    </div>

    <blockquote type="cite"

      cite="mid:20190109034407.GR79754@straasha.imrryr.org">So what you

      get is AESGCM with SHA2 or CHACHA20 with Poly1305.<br>

      Breaks in either would be dramatic advances in cryptanalysis.</blockquote>

    <br>

    History shows that protocols, algorithms, and implementations all

    have flaws.  We assume that flaws will be discovered and design so

    that our customers can work around them.<br>

    <br>

    <blockquote type="cite"

      cite="mid:20190109034407.GR79754@straasha.imrryr.org">You could

      just provide a free-form emergency string parameter that

      users are advised to not change unless some major advance makes it

      necessary. At that time, advice can be published as to what the

      override setting should be.

      <br>

    </blockquote>

    <br>

    That doesn't sound like a 21st century user interface.<br>

    <br>

    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.  It sounds like TLS 1.3 will need the same.  That's

    unfortunate - I'd really like to treat the crypto subsystem as a

    black box - but completely survivable.<br>

    <pre>-- 

Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris</pre>

  </body>

</html>