That's my assumption as well. On Fri, Oct 7, 2016 at 2:07 PM, Eric Rescorla <e...@rtfm.com> wrote:
> I was assuming that there were two exporters: > > Export() --> the same API as in 1.2 and computed as described here > Export0RTT -> A new API that computes the early_exporter. > > > -Ekr > > On Fri, Oct 7, 2016 at 1:59 PM, Nick Harper <nhar...@google.com> wrote: > >> Does the wording of this PR mean that the value from the exporter changes >> depending on whether it's run before or after exporter_secret can be >> computed? I think it would be better to keep an RFC 5705-style exporter >> that remains constant for the connection. The 0-RTT exporter from an API >> perspective can be a separate thing that a caller has to explicitly choose >> to use. >> >> On Fri, Oct 7, 2016 at 8:10 AM, Eric Rescorla <e...@rtfm.com> wrote: >> >>> Please see the following PR: >>> https://github.com/tlswg/tls13-spec/pull/673 >>> >>> This includes various changes to make exporters/resumption work better. >>> >>> Basically: >>> 1. Add a 0-RTT exporter and change the transcript for the regular >>> exporter so it >>> only includes the transcript up to ServerFinished. This gives it >>> parity with the >>> rest of the traffic keys. If we need an exporter with the full >>> transcript we can >>> always add it later >>> >>> 2. Point out that you can predict ClientFinished for NST when not doing >>> Client auth. This lets you issue tickets on the server's first >>> flight, while still >>> ensuring that if you do client auth you still bind resumption to the >>> client's >>> full transcript. >>> >>> These are pretty straightforward changes, so absent objections I'll merge >>> them early next week. >>> >>> -Ekr >>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >>> >> >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
