Re: [TLS] how close are we?

[Sean Turner]

> On Oct 11, 2016, at 23:21, Peter Gutmann  wrote:
> 
> Xiaoyin Liu  writes:
> 
>> Not directly related to Rich's question, but will we settle the "TLS 1.3 -> 
>> TLS 2.0" 
>> discussion (PR #612) before WGLC? Or has this already been closed as 
>> "keeping 
>> the current name"?
> 
> The impression I got from the discussion was that most people, or at least 
> those who
> contributed, wanted 2.0, or at least something other than 1.3.  I was kinda 
> surprised 
> to see it still being referred to as 1.3.
> 
> Peter.

It’s still in the queue.  The chairs felt it best to focus on the open 
technical issues.

spt 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] how close are we?

[Peter Gutmann]

Xiaoyin Liu  writes:

>Not directly related to Rich's question, but will we settle the "TLS 1.3 -> 
>TLS 2.0" 
>discussion (PR #612) before WGLC? Or has this already been closed as "keeping 
>the current name"?

The impression I got from the discussion was that most people, or at least 
those who
contributed, wanted 2.0, or at least something other than 1.3.  I was kinda 
surprised 
to see it still being referred to as 1.3.

Peter.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Finished stuffing/PSK Binders

[Eric Rescorla]

Thanks, I'll look at this. I'll be merging this change (modulo your
comments) Friday unless there is significant objection.

-Ekr


On Tue, Oct 11, 2016 at 5:16 PM, Martin Thomson 
wrote:

> On 12 October 2016 at 00:51, Eric Rescorla  wrote:
> > See:
> > https://github.com/tlswg/tls13-spec/pull/678
>
> I'm convinced that this is the right change.  Reconstruction was
> always going to be brittle.  I will note that I don't think that the
> change gets the error codes right though.  I explained why on the PR.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] how close are we?

[Eric Rescorla]

I've got a bunch of PRs in flight that I think we need to resolve one way
or the other.
I'm expecting the chairs to address those shortly and if all goes well with
that I'll put
out -17 next week and then we should revisit this question.

Best,
-Ekr


On Tue, Oct 11, 2016 at 7:23 PM, Salz, Rich  wrote:

> I’ve been away, and sick, for most of the post three weeks.
>
>
>
> How close is this ready to WGLC?  Is it really just polishing the shiny
> bits?  I mean I can kinda understand that, but also parts of this seems
> like lsat-midnight late-night hacking.
>
>
>
> Looking for some input here.
>
>
>
>
>
> --
>
> Senior Architect, Akamai Technologies
>
> Member, OpenSSL Dev Team
>
> IM: richs...@jabber.at Twitter: RichSalz
>
>
>
> ___
> 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

Re: [TLS] how close are we?

[Xiaoyin Liu]

Not directly related to Rich's question, but will we settle the "TLS 1.3 -> TLS 
2.0" discussion (PR #612) before 
WGLC? Or has this already been closed as "keeping the current name"?


Best,

Xiaoyin



From: TLS  on behalf of Salz, Rich 
Sent: Tuesday, October 11, 2016 10:23 PM
To: tls@ietf.org
Subject: [TLS] how close are we?


I've been away, and sick, for most of the post three weeks.



How close is this ready to WGLC?  Is it really just polishing the shiny bits?  
I mean I can kinda understand that, but also parts of this seems like 
lsat-midnight late-night hacking.



Looking for some input here.





--

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

IM: richs...@jabber.at Twitter: RichSalz


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] how close are we?

[Salz, Rich]

I've been away, and sick, for most of the post three weeks.

How close is this ready to WGLC?  Is it really just polishing the shiny bits?  
I mean I can kinda understand that, but also parts of this seems like 
lsat-midnight late-night hacking.

Looking for some input here.


--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Finished stuffing/PSK Binders

[Martin Thomson]

On 12 October 2016 at 00:51, Eric Rescorla  wrote:
> See:
> https://github.com/tlswg/tls13-spec/pull/678

I'm convinced that this is the right change.  Reconstruction was
always going to be brittle.  I will note that I don't think that the
change gets the error codes right though.  I explained why on the PR.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

[Mike Bishop]

There are a couple of scenarios we need to keep in mind:

1.   Existing HTTP/1.1 exchanges over upgraded TLS clients.  If we need a 
brief RFC that says post-handshake client auth is allowed for HTTP/1.1 over TLS 
1.3, that’s fine.

2.   Client authentication in HTTP/2.  Slightly longer RFC for this (but 
possibly the same one) that says post-handshake client auth is allowed for 
HTTP/2, then describing how to use the context (and new HTTP/2 frames, if 
needed) to bind the PHA exchange to one or more streams.

3.   Secondary server authentication in HTTP/2.  This approach still 
doesn’t give a clean way to do this, unless we use exporters and roll our own.  
That has proven to be a little hazardous to everyone’s peace of mind, but 
remains something we can refine in the future.

What concerns me more, though, is the prospect that a lot of TLS 
implementations would simply omit support.  Obviously, it’s not used in most 
HTTP sessions, and you may be an implementation whose niche doesn’t require 
supporting it – but since the application profile allows it, you still need to 
know how to decline if asked.  If it’s allowed in HTTP, which I assume is a 
supported workload for most implementations, then it’s allowed in your 
application profile and therefore prohibiting it by default doesn’t seem like 
it buys you much.  Having a simple way to disclaim support, either at 
connection time or upon receiving a challenge, seems like it provides more 
simplicity for the implementations that want to omit it.

From: Andrei Popov
Sent: Tuesday, October 11, 2016 11:09 AM
To: Eric Rescorla ; Hannes Tschofenig 
; Mike Bishop 
Cc: tls@ietf.org
Subject: RE: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

+ Mike who has additional concerns with this.

Cheers,

Andrei

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
Sent: Tuesday, October 11, 2016 10:22 AM
To: Hannes Tschofenig 
>
Cc: tls@ietf.org
Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

I think it would be simpler (and deal with most cases) to only allow this for 
specific application
profiles (we would then allow it in HTTP/H2, perhaps with some small -bis RFC).

Here is a PR for this:
https://github.com/tlswg/tls13-spec/pull/680

Andrei, would this cause you any problem? My impression was that this use case 
was only
about HTTP/H2.

Thanks,
-Ekr



On Tue, Oct 11, 2016 at 9:37 AM, Hannes Tschofenig 
> wrote:
Hi Nick,

given my discussion with Martin in this thread
https://www.ietf.org/mail-archive/web/tls/current/msg21481.html I like
your idea of making the post-handshake messages optional since it allows
me to develop a TLS 1.3 client that is smaller in code size.

Ciao
Hannes


On 10/08/2016 03:03 AM, Nick Sullivan wrote:
> There has been a lot of discussion lately about post-handshake messages
> that do not contain application data and how to handle them. This PR is
> an attempt to make the story more explicit by adding a new
> post_handshake extension to TLS 1.3.
>
> Supporting all types of post-handshake messages can require extra
> complexity and logic, even when the features that these messages enable
> are not needed. Some types of connections/implementations don't need to
> support key updates (some unidirectional connections), session tickets
> (pure PSK implementations) and post-handshake client auth (most
> browsers). These are all currently SHOULDs in the spec and they don't
> need to be.
>
> In order to simplify the logic around dealing with post-handshake
> messages, this proposal makes support for each of these modes explicit
> via a new handshake extension. This change also makes the path to
> introducing other types of post-handshake messages in future drafts more
> explicit.
>
> PR:
> https://github.com/tlswg/tls13-spec/pull/676
>
> Nick
>
>
> ___
> 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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

[Andrei Popov]

+ Mike who has additional concerns with this.

Cheers,

Andrei

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
Sent: Tuesday, October 11, 2016 10:22 AM
To: Hannes Tschofenig 
Cc: tls@ietf.org
Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

I think it would be simpler (and deal with most cases) to only allow this for 
specific application
profiles (we would then allow it in HTTP/H2, perhaps with some small -bis RFC).

Here is a PR for this:
https://github.com/tlswg/tls13-spec/pull/680

Andrei, would this cause you any problem? My impression was that this use case 
was only
about HTTP/H2.

Thanks,
-Ekr



On Tue, Oct 11, 2016 at 9:37 AM, Hannes Tschofenig 
> wrote:
Hi Nick,

given my discussion with Martin in this thread
https://www.ietf.org/mail-archive/web/tls/current/msg21481.html I like
your idea of making the post-handshake messages optional since it allows
me to develop a TLS 1.3 client that is smaller in code size.

Ciao
Hannes


On 10/08/2016 03:03 AM, Nick Sullivan wrote:
> There has been a lot of discussion lately about post-handshake messages
> that do not contain application data and how to handle them. This PR is
> an attempt to make the story more explicit by adding a new
> post_handshake extension to TLS 1.3.
>
> Supporting all types of post-handshake messages can require extra
> complexity and logic, even when the features that these messages enable
> are not needed. Some types of connections/implementations don't need to
> support key updates (some unidirectional connections), session tickets
> (pure PSK implementations) and post-handshake client auth (most
> browsers). These are all currently SHOULDs in the spec and they don't
> need to be.
>
> In order to simplify the logic around dealing with post-handshake
> messages, this proposal makes support for each of these modes explicit
> via a new handshake extension. This change also makes the path to
> introducing other types of post-handshake messages in future drafts more
> explicit.
>
> PR:
> https://github.com/tlswg/tls13-spec/pull/676
>
> Nick
>
>
> ___
> 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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

[Nick Sullivan]

The major thing that this proposal achieves is that it makes post-handshake
auth an optional part of the implementation. Instead of this, I would also
be in favor of a simpler change that modifies the text to say that
post-handshake CertificateRequest messages are fatal by default and only
permitted if the application permits their use in a given context (say if
the application is HTTP 1.1, only directly after requests).

Embedded implementations may choose to simply fail on unexpected
CertificateRequests, and that way not have to implement any code around
post-handshake finished messages or updating the transcript when one
arrives.

This default wording should also apply to other types of post-handshake
messages, though NST and KU could be exceptions that should always be
supported and non-fatal.


On Tue, Oct 11, 2016 at 9:37 AM Hannes Tschofenig 
wrote:

> Hi Nick,
>
> given my discussion with Martin in this thread
> https://www.ietf.org/mail-archive/web/tls/current/msg21481.html I like
> your idea of making the post-handshake messages optional since it allows
> me to develop a TLS 1.3 client that is smaller in code size.
>
> Ciao
> Hannes
>
>
> On 10/08/2016 03:03 AM, Nick Sullivan wrote:
> > There has been a lot of discussion lately about post-handshake messages
> > that do not contain application data and how to handle them. This PR is
> > an attempt to make the story more explicit by adding a new
> > post_handshake extension to TLS 1.3.
> >
> > Supporting all types of post-handshake messages can require extra
> > complexity and logic, even when the features that these messages enable
> > are not needed. Some types of connections/implementations don't need to
> > support key updates (some unidirectional connections), session tickets
> > (pure PSK implementations) and post-handshake client auth (most
> > browsers). These are all currently SHOULDs in the spec and they don't
> > need to be.
> >
> > In order to simplify the logic around dealing with post-handshake
> > messages, this proposal makes support for each of these modes explicit
> > via a new handshake extension. This change also makes the path to
> > introducing other types of post-handshake messages in future drafts more
> > explicit.
> >
> > PR:
> > https://github.com/tlswg/tls13-spec/pull/676
> >
> > Nick
> >
> >
> > ___
> > 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

Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

[Eric Rescorla]

I think it would be simpler (and deal with most cases) to only allow this
for specific application
profiles (we would then allow it in HTTP/H2, perhaps with some small -bis
RFC).

Here is a PR for this:
https://github.com/tlswg/tls13-spec/pull/680

Andrei, would this cause you any problem? My impression was that this use
case was only
about HTTP/H2.

Thanks,
-Ekr



On Tue, Oct 11, 2016 at 9:37 AM, Hannes Tschofenig <
hannes.tschofe...@gmx.net> wrote:

> Hi Nick,
>
> given my discussion with Martin in this thread
> https://www.ietf.org/mail-archive/web/tls/current/msg21481.html I like
> your idea of making the post-handshake messages optional since it allows
> me to develop a TLS 1.3 client that is smaller in code size.
>
> Ciao
> Hannes
>
>
> On 10/08/2016 03:03 AM, Nick Sullivan wrote:
> > There has been a lot of discussion lately about post-handshake messages
> > that do not contain application data and how to handle them. This PR is
> > an attempt to make the story more explicit by adding a new
> > post_handshake extension to TLS 1.3.
> >
> > Supporting all types of post-handshake messages can require extra
> > complexity and logic, even when the features that these messages enable
> > are not needed. Some types of connections/implementations don't need to
> > support key updates (some unidirectional connections), session tickets
> > (pure PSK implementations) and post-handshake client auth (most
> > browsers). These are all currently SHOULDs in the spec and they don't
> > need to be.
> >
> > In order to simplify the logic around dealing with post-handshake
> > messages, this proposal makes support for each of these modes explicit
> > via a new handshake extension. This change also makes the path to
> > introducing other types of post-handshake messages in future drafts more
> > explicit.
> >
> > PR:
> > https://github.com/tlswg/tls13-spec/pull/676
> >
> > Nick
> >
> >
> > ___
> > 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
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

[Hannes Tschofenig]

Hi Nick,

given my discussion with Martin in this thread
https://www.ietf.org/mail-archive/web/tls/current/msg21481.html I like
your idea of making the post-handshake messages optional since it allows
me to develop a TLS 1.3 client that is smaller in code size.

Ciao
Hannes


On 10/08/2016 03:03 AM, Nick Sullivan wrote:
> There has been a lot of discussion lately about post-handshake messages
> that do not contain application data and how to handle them. This PR is
> an attempt to make the story more explicit by adding a new
> post_handshake extension to TLS 1.3.
> 
> Supporting all types of post-handshake messages can require extra
> complexity and logic, even when the features that these messages enable
> are not needed. Some types of connections/implementations don't need to
> support key updates (some unidirectional connections), session tickets
> (pure PSK implementations) and post-handshake client auth (most
> browsers). These are all currently SHOULDs in the spec and they don't
> need to be.
> 
> In order to simplify the logic around dealing with post-handshake
> messages, this proposal makes support for each of these modes explicit
> via a new handshake extension. This change also makes the path to
> introducing other types of post-handshake messages in future drafts more
> explicit.
> 
> PR:
> https://github.com/tlswg/tls13-spec/pull/676
> 
> Nick
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Zero-RTT Data & PSK

[Eric Rescorla]

This LGTM. Absent objections I will merge tomorrow

On Tue, Oct 11, 2016 at 9:22 AM, Hannes Tschofenig <
hannes.tschofe...@gmx.net> wrote:

> I gave it a try, see
> https://github.com/tlswg/tls13-spec/pull/668/commits/
> 91e5b39e5f0ce62a90effdbaf4e3c90ed0d81245
>
>
> Ciao
> Hannes
>
>
> On 10/10/2016 11:59 PM, Eric Rescorla wrote:
> > I agree with MT. Hannes, if you want to clean up the text to take into
> > account MT's comments, I will merge
> >
> > On Sat, Sep 10, 2016 at 3:35 AM, Martin Thomson
> > > wrote:
> >
> > On 9 September 2016 at 23:37, Hannes Tschofenig
> > >
> wrote:
> > > I am wondering why I cannot use Zero-RTT with just PSK-based
> authentication
> > > (without a prior ticket change).
> >
> > I think that you would need to bind more things to the key in that
> > case, but I assume that it would be OK if you did so.  You already
> > need to pair a PSK with a hash, but if you paired it with a whole
> > cipher suite instead and also the ALPN (which could be null), then I
> > see no reason not to permit 0-RTT for pure PSK.  (I think that cipher
> > suite + ALPN is sufficient, but someone can correct me if I missed
> > anything.)
> >
> > ___
> > 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

Re: [TLS] Zero-RTT Data & PSK

[Hannes Tschofenig]

I gave it a try, see
https://github.com/tlswg/tls13-spec/pull/668/commits/91e5b39e5f0ce62a90effdbaf4e3c90ed0d81245


Ciao
Hannes


On 10/10/2016 11:59 PM, Eric Rescorla wrote:
> I agree with MT. Hannes, if you want to clean up the text to take into
> account MT's comments, I will merge
> 
> On Sat, Sep 10, 2016 at 3:35 AM, Martin Thomson
> > wrote:
> 
> On 9 September 2016 at 23:37, Hannes Tschofenig
> > wrote:
> > I am wondering why I cannot use Zero-RTT with just PSK-based 
> authentication
> > (without a prior ticket change).
> 
> I think that you would need to bind more things to the key in that
> case, but I assume that it would be OK if you did so.  You already
> need to pair a PSK with a hash, but if you paired it with a whole
> cipher suite instead and also the ALPN (which could be null), then I
> see no reason not to permit 0-RTT for pure PSK.  (I think that cipher
> suite + ALPN is sufficient, but someone can correct me if I missed
> anything.)
> 
> ___
> TLS mailing list
> TLS@ietf.org 
> https://www.ietf.org/mailman/listinfo/tls
> 
> 
> 



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Finished stuffing/PSK Binders

[Eric Rescorla]

On Sun, Oct 9, 2016 at 7:10 AM, Eric Rescorla  wrote:

>
>
> On Sun, Oct 9, 2016 at 6:58 AM, Ilari Liusvaara 
> wrote:
>
>> On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote:
>> > After the discussion on PR #615, I took another pass at this with some
>> > help from the research community. Please see:
>> >
>> >https://github.com/tlswg/tls13-spec/pull/672
>> >
>>
>> Also, an observation: This seems to interact in somewhat annoying way
>> with stateless HRR.
>>
>> Basically, CH reconstruction no longer works properly, so one needs to
>> have a  freezeable PRF hash (and most implementations of hashes can not
>> be frozen).
>>
>
> I've been coming to the conclusion that CH reconstruction is a bad idea.
> It's
> tricky to get right and in the common case involves a lot of bloat in the
> CH
> (because of duplicating the Key Shares). I think we would be better off
> just
> removing it and replacing (rather than appending to ) KeyShares in HRR.
> This was primarily intended as an attempt to avoid the need to continue
> the hash in any case.
>

See:
https://github.com/tlswg/tls13-spec/pull/678

-Ekr


> Best,
> -Ekr
>
>
> And server not supporting PSK does not help here.
>>
>>
>> (BTW: Simlar thing comes up if you try to freeze an established TLS
>> session: Currently you need to freeze a hash due to post-handshake
>> authentication, even if you don't support it. Nothing else in TLS
>> 1.2 or 1.3 needs hash freezing for established session).
>>
>>
>> -Ilari
>>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

[Tom Ritter]

On 8 October 2016 at 11:54, Eric Rescorla  wrote:
> I could go either way on this. It seems like this pushes complexity from the
> client to the server.
>
> Consider the case of NST. Presently, a client which doesn't want resumption
> can just ignore NST,
> but in your proposed change, the server needs to read this extension and
> then conditionally send
> NST, and the client still needs the logic to detect unexpected handshake
> messages and abort
> on them.
>
> As I said, I could go either way, and I do think it's potentially useful to
> be able to say "I won't do
> post-handshake client auth" and even more useful to be able to say "I would
> do post handshake
> message X which will be invented in 2018" (but of course we can register an
> extension for
> that then), but less useful to say "I don't like NST or KU"


I'm concerned about the information this exposes on the wire. We've
added Record Content Type protection, so things like post-handshake
client auth can't be detected on the wire (modulo behavior/length
attacks, for which we can attempt protection with padding.)

But now we're going to say in the client's plaintext "Yea, I might
want post-handsake client auth".  And it seems like the percentage of
clients who will say that will be few and far between... leading to
more fingerprinting and a step back from where we were.

-tom

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

[Martin Thomson]

On 11 October 2016 at 14:30, Benjamin Kaduk  wrote:
> So, on the balance, I think I'm starting to lean against this specific
> proposal and more towards the text changes that David wants.

Yes, I would rather not take NST or KU out of the mandatory set of 1.3
features.  I'm happy to have post-handshake authentication require
opt-in though.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Application layer interactions and API guidance

[Martin Thomson]

On 11 October 2016 at 07:57, Kyle Rose  wrote:
> FWIW, Patrick McManus made a pretty eloquent and convincing case in Berlin
> that the web is substantially broken without retry logic in the browsers,
> that naturally make application-level replay mitigation a necessity. But I
> don't think (nor do I think he claimed) that the same is true of all
> protocols or systems that might use TLS. So while 0-RTT-obliviousness may be
> okay for browsers in particular given the other constraints under which they
> operate, it is probably not good to bake that into the API for the general
> case.

The 0-RTT API in NSS allows a server to detect this transition.  The
problem that I think David was referring to is that the specific
instant of the transition is lost when the multiple layers of stack
that sit on top of TLS get involved.

If an HTTP client sends a request that relies on HPACK state that was
established during 0-RTT, is it a 0-RTT request?  I'm going to go with
probably not.

If an HTTP client sends the first octets of a message in 0-RTT but
completes the request after the handshake completes, is it 0-RTT?  I
suspect that this again is not a concern.

I agree that we should make it clear that 0-RTT data needs to be
treated specially.  I would like to see someone propose some text
rather than read more vague emails on the subject.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls