<div dir="ltr"><div class="gmail_quote">On Fri, Mar 4, 2016 at 10:33 AM, Igor Sysoev <span dir="ltr"><<a href="mailto:igor@sysoev.ru" target="_blank">igor@sysoev.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><span></span><div><span><blockquote type="cite"><div dir="ltr"><div style="font-size:small;color:rgb(51,51,153)">But still, advertising something without actually supporting it must lead to cases where sessions reuse is believed to take place without ever happening, harming performance... that was probably happening in versions < 1.5.9.<br></div></div></blockquote><div><br></div></span>I do not think that it should harm performance.</div></div></blockquote><div><br><div class="gmail_default" style="font-size:small;color:rgb(51,51,153);display:inline">​Oh
 yes it does​... I am surprised by your stance and I beg to differ.<br>Having quite some load from many clients on a 
web-server delivering content over HTTPS, it relieves a lot of pain to 
save CPU cycles by avoiding a full handshake.<br>When a client browses a website, (s)he will initiate many connections. Beyond the first one (ones with multiplexing?), session reuse kicks in. Repeat that for each client and sum all the saved CPU cycles. Even an improper (non-scientific) benchmark will show you improvement.<br><br>Session reuse is part of the effort of optimizing TLS trafic to minimize its overhead. Have a talk about it with the <a href="https://www.w3.org/2010/webperf/" target="_blank">W3C webperf group</a> if you wish, to which Ilya Grigorik (participated at nginxconf 2014) belongs. Have a look at <a href="https://istlsfastyet.com/" target="_blank">his checklist</a> too.​<br><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div dir="ltr"><div style="font-size:small;color:rgb(51,51,153)">Giving the possibility to accomodate with Outlook (and Microsoft products in general) numerous quirks is fine, but making it the default is debatable…</div></div></blockquote><div><br></div><div>I believe this is safe default and clients should not rely on resumed sessions because</div><div>1) sessions have timeout defined by server security policy,</div><div><div>2) and server has limited session storage so old sessions are removed.</div></div></div></div></blockquote><div><br><div class="gmail_default" style="font-size:small;color:rgb(51,51,153);display:inline">​Well, the mechanism behind TLS sessions is basically a trial-and-error​</div> <div class="gmail_default" style="font-size:small;color:rgb(51,51,153);display:inline">​one.​ Even for tickets I would add, if the server changed its Master Key between ticket creation and reuse.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153);display:inline">There is little-to-no overhead at trying an expired session ID/ticket which the client communicate in his initial message to the server. ID search in cache or ticket invalidation requires few overhead resource and in case of invalidation, normal protocol to initiate a new session resumes.<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153);display:inline">There is no guarantee a session exists, but there is everything to gain from it if it does.​<br clear="all"><div><div><font size="1"><span style="color:rgb(102,102,102)">---<br></span><b><span style="color:rgb(102,102,102)">B. R.</span></b><span style="color:rgb(102,102,102)"></span></font></div></div>
</div></div></div></div>