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