<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 11/02/2015 16:46, Salz, Rich wrote:<br>
    </div>
    <blockquote
cite="mid:240867ca3376443fae0aa6ef966b8552@ustx2ex-dag1mb2.msg.corp.akamai.com"
      type="cite">
      <blockquote type="cite">
        <pre wrap="">I agree with Viktor. His suggestion (keep RC4 in MEDIUM, suppress it
explicilty in DEFAULT) is a good one that maintains important backward
compatibility while providing the desired removal of RC4 by default. There's
no advantage to moving RC4 to LOW.
</pre>
      </blockquote>
      <pre wrap="">
Sure there is:  it's an accurate description of the quality of protection provided by the algorithm. :)
</pre>
    </blockquote>
    <tt>Is the security level (i.e. log2 of the cost of the best<br>
      known direct attack) 40 bits (historical EXPORT label), 56<br>
      bits (historical LOW label), 112 to 127 bits (historical<br>
      MEDIUM) level, or somewhere in between?</tt><tt><br>
    </tt><tt><br>
    </tt><tt>This is the real question that should guide its<br>
      classification, not if it is "lower than what is currently<br>
      recommended".<br>
      <br>
      Given the currenly available ciphers, it may make sense to<br>
      add new groups: HIGH192, HIGH256 and larger ones still. As<br>
      time progresses, the default can then move from HIGH to<br>
      HIGH192, to HIGH256 as the state of the art changes,<br>
      without redefining semantics.<br>
      <br>
      Furthermore, the various attacks on SSL3/TLS1.0 padding and<br>
      IV logic creates an ongoing need to have a widely supported,<br>
      TLS1.0 compatible stream-or-otherwise-unpadded cipher choice<br>
      as an emergency fallback as other protections are being<br>
      rolled out by all kinds of vendors.</tt><tt><br>
    </tt><br>
    <tt>For example RC4 is immune to POODLE as well as a previous<br>
      widely</tt><tt> </tt><tt>publicized attack, simply because it
      uses neither the<br>
      flawed SSL3</tt><tt> </tt><tt>padding nor the sometimes
      problematic TLS1.0 IV<br>
      selection.</tt><tt>  No other cipher provides this protection when<br>
      talking to older peers that cannot or will not upgrade to<br>
      the latest-and-greatest TLS standards.<br>
    </tt><br>
    <blockquote
cite="mid:240867ca3376443fae0aa6ef966b8552@ustx2ex-dag1mb2.msg.corp.akamai.com"
      type="cite">
      <pre wrap="">
It's also compatible with our documentation, which as was pointed out, always uses the word "currently" to describe the magic keywords.

And it's also planned for the next version which won't be available until near the end of the year.

And it's also compliant with the expected publication of the IETF RFC's that talk about TLS configuration and attacks.

Postfix can work lay the groundwork to be future-compliant by changing its default configuration to be HIGH:MEDIUM:RC4.
</pre>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  <a class="moz-txt-link-freetext" href="http://www.wisemo.com">http://www.wisemo.com</a>
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded </pre>
  </body>
</html>