<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 20 Jan 2017, at 04:38, Wes Turner <<a href="mailto:wes.turner@gmail.com" class="">wes.turner@gmail.com</a>> wrote:</div><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><br class=""></div><div class=""><div class="">Thanks! TLSConfiguration looks much easier to review; and should make other implementations easier.</div><div class=""><br class=""></div><div class="">I read a great (illustrated) intro to TLS1.3 the other day:</div><div class=""><br class=""></div><div class=""><a href="https://temen.io/resources/tls-gets-an-upgrade:-welcome-1.3/" target="_blank" class="">https://temen.io/resources/<wbr class="">tls-gets-an-upgrade:-welcome-<wbr class="">1.3/</a><br class=""></div><div class=""><br class=""></div><div class="">- 1-RTT and 0-RTT look useful.</div><div class="">- There's a reduced set of cipher suites </div><div class=""><br class=""></div><a href="https://tlswg.github.io/tls13-spec/" class="">https://tlswg.github.io/tls13-spec/</a><span class="Apple-converted-space"> </span>#rfc.section.4.3<div class=""><br class=""></div><div class="">- Are there additional parameters relevant to TLS1.3 for the TLSConfiguration object?</div><div class="">- If necessary, how should TLSConfiguration parameter fields be added?</div></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"></blockquote></div></div></blockquote><br class=""></div><div>So both 0-RTT and 1-RTT have little to no library support at this time. Certainly the three main implementations that this proposal considers (OpenSSL, SChannel, SecureTransport) have no public APIs to control this kind of functionality. Indeed, none of those implementations is shipping TLSv1.3 yet as far as I’m aware. OpenSSL has a date by which they plan to have TLSv1.3 support complete, and based on Apple’s adoption of TLS tech I’d expect to see TLSv1.3 in SecureTransport within 18 months and possibly as soon as September. The TL;DR here is that I think we should not attempt to spec APIs for 1-RTT and 0-RTT yet, until we understand how implementations plan to support it.</div><div><br class=""></div><div>As to the reduced set of cipher suites, all either do or will have IANA assigned names, and so can be managed as per the cipher enum.</div><div><br class=""></div><div>As to adding TLSConfiguration parameter fields, I think they are subject to the regular standard library update process. Generally speaking we should have a policy that adding fields should be a difficult thing to do unless there is substantial need for their addition, to avoid making the object almost impossible to manage. However, otherwise the regular standard library concerns should all apply.</div><div><br class=""></div><div>Cory</div></body></html>