Re: [TLS] Earlier exporters

That's my assumption as well.

On Fri, Oct 7, 2016 at 2:07 PM, Eric Rescorla <ekr@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 <nharper@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 <ekr@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
>>>
>>>
>>
>