<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Mar 4, 2016 at 11:00 PM Viktor Dukhovni <<a href="mailto:openssl-users@dukhovni.org">openssl-users@dukhovni.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Mar 4, 2016, at 3:57 PM, Emilia Käsper <<a href="mailto:emilia@openssl.org" target="_blank">emilia@openssl.org</a>> wrote:<br>
><br>
> I've updated the pull to do a much more substantial cleanup.<br>
<br>
What will @STRENGTH mean in this context?  Will ignore<br>
the distinction between AES256 and AES128?</blockquote><div><br></div><div>@STRENGTH will sort it back by symmetric encryption key strength. Which is a bit of a bummer but I have no good answer for how to avoid it, because this is what @STRENGTH's contract promises to do.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What does this<br>
do to the @SECLEVEL interface which tries to provide<br>
NIST-compatible bit strengths across multiple features?<br></blockquote><div><br></div><div>@SECLEVEL will continue to work as expected, i.e., it will filter out the ones that don't meet the level.</div><div><br></div><div>(@SECLEVEL operates directly on the cert, and does nothing to the cipherlist alone. Which results in misleading output from the 'ciphers' app, but that is a separate bug.)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Or we just changing the default order, and allowing<br>
@STRENGTH to perturb it back, and @SECLEVEL to prune-away<br>
128 leaving just 256, ...<br>
<br>
In other words how does this fit into the larger picture?</blockquote><div><br></div><div>The ordering affects lists built from the predefined groups - ALL, DEFAULT, HIGH, MEDIUM, LOW etc. More generally, it sorts each cipher group separated by the ':'.</div><div><br></div><div>For example, if you do 'CAMELLIA:AES' then you get CAMELLIA ciphers sorted by this preference, followed by AES ciphers sorted by this preference., and if you do 'CAMELLIA:AES@STRENGTH' then - sadly - you get the symmetric strength-sort back.</div><div><div><br></div><div>We could add a variant of @STRENGTH that re-sorts by our internal implicit preferences (which we're allowed to change at any time), but that's not going to happen for 1.1.0.</div><div><br></div><div>It is, however, possible, to achieve the same effect in multiple ways already:</div><div>- start from DEFAULT, and remove more ciphers, e.g.</div><div><br></div><div>"DEFAULT:!3DES:!AES128"</div><div><br></div><div>- Or, if you want a superset of DEFAULT, start from ALL, and remove some ciphers:</div><div><br></div><div>"ALL:!MEDIUM:!LOW:!aNULL:!eNULL:!IDEA:!SEED"</div><div><br></div><div>Both of these operations will preserve the preferences.</div></div><div><br></div><div>Anyway, the goal here is to improve the situation *if the user does nothing*. It does not solve all the other problems of the API, but it does not make them worse.</div><div><br></div><div>Emilia</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
--<br>
        Viktor.<br>
<br>
--<br>
openssl-dev mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-dev" rel="noreferrer" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-dev</a><br>
</blockquote></div></div>