<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sun, Sep 2, 2018 at 5:09 PM John-Mark Gurney <<a href="mailto:jmg@funkthat.com">jmg@funkthat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Peter Gutmann wrote this message on Sat, Sep 01, 2018 at 13:58 +0000:<br>
> Viktor Dukhovni <<a href="mailto:cryptography@dukhovni.org" target="_blank">cryptography@dukhovni.org</a>> writes:<br>
> <br>
> >The right way to do single-suite protocols, is to tie all the choices to a<br>
> >single protocol version.  For shiny new parameters, bump the protocol<br>
> >version. Client proposes its list of protocol versions, and server chooses<br>
> >the highest supported.<br>
> <br>
> Even then, you have to be very, very careful with that.  The TLS folks have<br>
> been struggling for years with anti-rollback mechanisms, it's really hard to<br>
> do them in a manner that isn't exploitable in some combination of<br>
> circumstances.<br>
<br>
That's because they've been trying to keep backwards compatibility.<br>
If you have a protocol designed from the start, it's not at all hard.<br>
You simply integrate all protocol messages into your key generation,</blockquote><div> .....</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
have to "self downgrade" to allow broken servers to negotiate a<br>
functional channel...<br></blockquote><div> </div><div>There is a possible solution set.</div><div>*) server side enforcement and branding.  Many sites sport a security scan by "vendor"  and <br>that "certification" can be current.  <br>*) plugin like https-everywhere that lights up the search bar red when presented with an old or deprecated method.<br>*) site information like a stop light red, amber, green.   Amber can gate the need to update and start a clock even time = zero in the case of zero day attacks.<br><br>For money,  the server side can be the enforcer and disallow insecure methods.    <br>It is not uncommon for banks to demand specific versions of a browser and even java.<br>The key will be to have strong APIs so the methods behind door #2 and #3 will work<br>when door #1 has its lock broken or key compromised.</div><div><br>The number of doors likely needs to be two.   The second could be slow & use big key bit counts just as long as it is </div><div>likely to work well enough to bootstrap a client side update.   Consider that chrome, firefox, duckduck, and MS tools </div><div>depend on a browser interface to fetch their update.<br><br>Two problems:  one encryption of data in transit, privacy, security, money;<br>two is fetching and deploying updates to support #1.   The second is critical</div><div>to infrastructure design even national (international) security.<br><br><br><br><br></div></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">  T o m    M i t c h e l l</div></div></div>