attachment
<div dir="ltr"><div>Hi,<br><br></div><div>FYI - this is the technical content complete new draft of TLS/1.3 (see details<br></div><div>in change log below).<br><br></div><div>Cheers,<br></div><div>- Ira<br></div><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><br><div style="display:inline"></div><div style="display:inline"></div><div style="display:inline"></div><div></div><div></div><div></div><div></div></div></div></div></div></div>
<br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Eric Rescorla</b> <span dir="ltr"><<a href="mailto:ekr@rtfm.com">ekr@rtfm.com</a>></span><br>Date: Fri, Mar 10, 2017 at 6:34 PM<br>Subject: [TLS] draft-ietf-tls-tls13-19 posted<br>To: "<a href="mailto:tls@ietf.org">tls@ietf.org</a>" <<a href="mailto:tls@ietf.org">tls@ietf.org</a>><br><br><br><div dir="ltr">I just posted draft-19 at:<div><br><div><div> <a href="https://tools.ietf.org/html/draft-ietf-tls-tls13-19" target="_blank">https://tools.ietf.org/html/dr<wbr>aft-ietf-tls-tls13-19</a><br></div></div><div><br></div><div>This draft includes all the outstanding wire format changes that I believe we are going</div></div><div>to make before publication (changelog below). There are three remaining issues that</div><div>we need to address somehow. I've listed them and proposed resolutions.</div><div><br></div><div>1. DH Key Reuse Considerations (<a href="https://github.com/tlswg/tls13-spec/pull/768" target="_blank">https://github.com/tlswg/tls1<wbr>3-spec/pull/768</a>)</div><div>I'm not entirely confident of the analysis here and I'm not that excited about encouraging<br></div><div>people to re-use, so I propose that we simply drop this PR.</div><div><br></div><div>2. Short headers (<a href="https://github.com/tlswg/tls13-spec/pull/762" target="_blank">https://github.com/tlswg/tls1<wbr>3-spec/pull/762</a>)<br></div><div>Both the Chrome team and the Firefox team have concerns about the middlebox<br></div><div>compatibility impact of this change, and I believe if necessary we can add it as</div><div>an extension later. Thus, I propose we defer it. We can make this change directly</div><div>in DTLS 1.3, however.</div><div><br></div><div>3. The various non-X509 cert RFCs (no PR).</div><div>As Ilari points out, there is significant incompatibility between these RFCs and</div><div>TLS 1.3, so we'll probably need new versions of them if people want this functionality.</div><div>Absent objection, I'll pull them out of the "usable with TLS 1.3 list" in S 4.2</div><div>and then add some handwaving about how we can support them with new</div><div>drafts (though, as Ilari indicates, we may be able to keep cached-info with some</div><div>small text changes here).</div><div><br></div><div>In terms of implementation, we will probably try to have something for NSS</div><div>by IETF, but I doubt it will be actually in Firefox.</div><div><br></div><div>As usual, comments welcome, including anything I missed.</div><div>-Ekr</div><div><br></div><div><br></div><div>ChangeLog:<br></div><div><div> - Hash context_value input to Exporters (*)</div><div><br></div><div> - Add an additional Derive-Secret stage to Exporters (*).</div><div><br></div><div> - Hash ClientHello1 in the transcript when HRR is used. This</div><div> reduces the state that needs to be carried in cookies. (*)</div><div><br></div><div> - Restructure CertificateRequest to have the selectors in</div><div> extensions. This also allowed defining a</div><div> "certificate_authorities" extension which can be used by the</div><div> client instead of trusted_ca_keys (*).</div><div><br></div><div> - Tighten record framing requirements and require checking of them</div><div> (*).</div><div><br></div><div> - Consolidate "ticket_early_data_info" and "early_data" into a</div><div> single extension (*).</div><div><br></div><div> - Change end_of_early_data to be a handshake message (*).</div><div><br></div><div> - Add pre-extract Derive-Secret stages to key schedule (*).</div><div><br></div><div> - Remove spurious requirement to implement "pre_shared_key".</div><div><br></div><div> - Clarify location of "early_data" from server (it goes in EE, as</div><div> indicated by the table in S 10).</div><div><br></div><div> - Require peer public key validation</div><div><br></div><div> - Add state machine diagram.</div></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div>
<br>______________________________<wbr>_________________<br>
TLS mailing list<br>
<a href="mailto:TLS@ietf.org">TLS@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/tls" rel="noreferrer" target="_blank">https://www.ietf.org/mailman/<wbr>listinfo/tls</a><br>
<br></div><br></div>