Re: [TLS] Application layer interactions and API guidance

2016-10-12 Thread Kyle Rose
On Wed, Oct 12, 2016 at 2:03 PM, Ilari Liusvaara wrote: > > There's my confusion. I misinterpreted both the Zero-RTT diagram and the > > table of handshake contexts under "Authentication Messages", specifically > > "ClientHello ... later of

[TLS] ALPN with 0-RTT Data

2016-10-12 Thread Kyle Nekritz
Currently the draft specifies that the ALPN must be "the same" as in the connection that established the PSK used with 0-RTT, and that the server must check that the selected ALPN matches what was previously used. I find this unclear if 1) the client should select and offer one (and only one)

Re: [TLS] Application layer interactions and API guidance

2016-10-12 Thread Eric Rescorla
On Wed, Oct 12, 2016 at 12:55 PM, Kyle Rose wrote: > On Wed, Oct 12, 2016 at 2:03 PM, Ilari Liusvaara > wrote: > >> > There's my confusion. I misinterpreted both the Zero-RTT diagram and the >> > table of handshake contexts under "Authentication

Re: [TLS] ALPN with 0-RTT Data

2016-10-12 Thread Kyle Nekritz
Reordering the ALPN offer has a couple advantages: * It explicitly defines the protocol that the 0-RTT data is using on that connection. Without this, both the client and the server must independently store the ALPN in use (of course the server can put it in the ticket). While this should work

Re: [TLS] ALPN with 0-RTT Data

2016-10-12 Thread David Benjamin
On Wed, Oct 12, 2016 at 5:07 PM Kyle Nekritz wrote: > > Reordering the ALPN offer has a couple advantages: > > * It explicitly defines the protocol that the 0-RTT data is using on that > connection. Without this, both the client and the server must independently > store the ALPN

Re: [TLS] Application layer interactions and API guidance

2016-10-12 Thread Ilari Liusvaara
On Tue, Oct 11, 2016 at 09:41:55PM -0400, Kyle Rose wrote: > > > > 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

Re: [TLS] Finished stuffing/PSK Binders

2016-10-12 Thread Ilari Liusvaara
On Tue, Oct 11, 2016 at 07:48:05PM -0700, Eric Rescorla wrote: > 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

Re: [TLS] Finished stuffing/PSK Binders

2016-10-12 Thread Martin Thomson
On 12 October 2016 at 19:50, Ilari Liusvaara wrote: > I also noticed another edge case: What is to prevent server from > omitting key share group (emitting a cookie, so the restart is > not spurious), presumably causing the client to blank its key_share > and then

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

2016-10-12 Thread Ilari Liusvaara
On Wed, Oct 12, 2016 at 03:10:54AM -0400, Daniel Kahn Gillmor wrote: > > I don't think it's too much to ask that implementations be able to > reject a post-handshake CertificateRequest gracefully, even if they have > no intention of ever implementing a proper Client Certificate response.

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

2016-10-12 Thread David Benjamin
Even without the Finished computation, rejecting a CertificateRequest would hit the same unboundedness problem the previous generation of KeyUpdate had. Our implementation currently treats all post-handshake CertificateRequests as a fatal error. I think the only context where we'd conceivably

Re: [TLS] Finished stuffing/PSK Binders

2016-10-12 Thread Ilari Liusvaara
On Wed, Oct 12, 2016 at 09:43:05PM +1100, Martin Thomson wrote: > On 12 October 2016 at 19:50, Ilari Liusvaara wrote: > > I also noticed another edge case: What is to prevent server from > > omitting key share group (emitting a cookie, so the restart is > > not

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

2016-10-12 Thread Daniel Kahn Gillmor
On Tue 2016-10-11 13:26:02 -0400, Nick Sullivan wrote: > 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

[TLS] PR#634: Registry for TLS protocol version ID

2016-10-12 Thread Sean Turner
Al, David Garrett has generated PR#634 (https://github.com/tlswg/tls13-spec/pull/634) to "explicitly [rename] the protocol version fields as IDs and defines a registry for all values, as they're really just arbitrary codepoints at this point.” Note that there are no bits on the wire changes

Re: [TLS] PR#634: Registry for TLS protocol version ID

2016-10-12 Thread Salz, Rich
> David Garrett has generated PR#634 (https://github.com/tlswg/tls13- > spec/pull/634) +1 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR#634: Registry for TLS protocol version ID

2016-10-12 Thread Eric Rescorla
On Wed, Oct 12, 2016 at 3:26 PM, Sean Turner wrote: > Al, > > David Garrett has generated PR#634 (https://github.com/tlswg/ > tls13-spec/pull/634) to "explicitly [rename] the protocol version fields > as IDs and defines a registry for all values, as they're really just >

Re: [TLS] Early code-point assignment request for draft-davidben-tls-grease-01

2016-10-12 Thread Eric Rescorla
I am fine with this. -Ekr On Wed, Oct 12, 2016 at 4:34 PM, Joseph Salowey wrote: > We have received a request for early code-point assignment of values for > draft-davidben-tls-grease-01. Please respond to this list of you have > concerns about these assignments by October

[TLS] PR #672: Finished Stuffing/PSK Binder

2016-10-12 Thread Sean Turner
All, We’re looking to land PR#672 (aka Finished Stuffing/PSK Binder): https://github.com/tlswg/tls13-spec/pull/672 It looks there’s been some discussion, but that the issues have been largely resolved. Please send any comments you have by Friday (10/14) so that we can address them. Barring

[TLS] Early code-point assignment request for draft-davidben-tls-grease-01

2016-10-12 Thread Joseph Salowey
We have received a request for early code-point assignment of values for draft-davidben-tls-grease-01. Please respond to this list of you have concerns about these assignments by October 28, 2016. Thanks, J ___ TLS mailing list TLS@ietf.org

Re: [TLS] Finished stuffing/PSK Binders

2016-10-12 Thread Ilari Liusvaara
On Wed, Oct 12, 2016 at 10:13:57AM -0500, Benjamin Kaduk wrote: > On 10/12/2016 09:27 AM, Ilari Liusvaara wrote: > > On Wed, Oct 12, 2016 at 09:43:05PM +1100, Martin Thomson wrote: > > > That would waste a bit of space with extensions signaling support > > for some rewrites if the server doesn't

Re: [TLS] Application layer interactions and API guidance

2016-10-12 Thread Ilari Liusvaara
On Wed, Oct 12, 2016 at 01:51:25PM -0400, Kyle Rose wrote: > On Wed, Oct 12, 2016 at 1:02 PM, Ilari Liusvaara > wrote: > > > > By this point in the connection, there is proof that early_data has not > > > been replayed. The application doesn't necessarily know this when

Re: [TLS] Application layer interactions and API guidance

2016-10-12 Thread Kyle Rose
On Wed, Oct 12, 2016 at 1:02 PM, Ilari Liusvaara wrote: > > By this point in the connection, there is proof that early_data has not > > been replayed. The application doesn't necessarily know this when the > early > > data is first delivered, but it can find out later,

Re: [TLS] Finished stuffing/PSK Binders

2016-10-12 Thread Benjamin Kaduk
On 10/12/2016 09:27 AM, Ilari Liusvaara wrote: > On Wed, Oct 12, 2016 at 09:43:05PM +1100, Martin Thomson wrote: >> On 12 October 2016 at 19:50, Ilari Liusvaara >> wrote: >> >> Maybe we should require text for every extension that can appear in >> the HRR: what to do if

Re: [TLS] Application layer interactions and API guidance

2016-10-12 Thread Ilari Liusvaara
On Wed, Oct 12, 2016 at 11:54:59AM -0400, Kyle Rose wrote: > On Wed, Oct 12, 2016 at 4:11 AM, Ilari Liusvaara > wrote: > > Ok, I see where you're going with this. I'm not sure whether I would put > the ALP filtering logic in the API or do something more like: > >

Re: [TLS] Application layer interactions and API guidance

2016-10-12 Thread Kyle Rose
On Wed, Oct 12, 2016 at 4:11 AM, Ilari Liusvaara wrote: > For when 0-RTT has become boring enough for me to implement, I would > think the server-side interface I put in would be something like the > following: > > - ServerSession::getReplayable0RttReader(alp_list) ->

Re: [TLS] PR#634: Registry for TLS protocol version ID

2016-10-12 Thread Dave Garrett
On Wednesday, October 12, 2016 07:00:34 pm Eric Rescorla wrote: > This PR involves two changes: > > 1. Attaching the term "ID" to version and defining new enum code points. > 2. Creating a registry > > The first of these seems obfuscatory and unhelpful. The second just seems > unnecessary. Other

Re: [TLS] PR#634: Registry for TLS protocol version ID

2016-10-12 Thread Eric Rescorla
On Wed, Oct 12, 2016 at 5:55 PM, Martin Thomson wrote: > On 13 October 2016 at 10:00, Eric Rescorla wrote: > > I would prefer we not merge this PR. > > I concur, though I would prefer if we stopped using the strange { 3, 3 > } notation for versions, it's

Re: [TLS] PR#634: Registry for TLS protocol version ID

2016-10-12 Thread Martin Thomson
On 13 October 2016 at 10:00, Eric Rescorla wrote: > I would prefer we not merge this PR. I concur, though I would prefer if we stopped using the strange { 3, 3 } notation for versions, it's not useful and it implies a significance to the separation that just doesn't exist*. [*]

Re: [TLS] PR#634: Registry for TLS protocol version ID

2016-10-12 Thread Martin Thomson
On 13 October 2016 at 11:59, Dave Garrett wrote: > One added feature we get with this registry definition is a range of > codepoints for private experimental use. Formal definition might not be > strictly needed here, though it shouldn't hurt. The same can be achieved

Re: [TLS] PR#634: Registry for TLS protocol version ID

2016-10-12 Thread Martin Thomson
On 13 October 2016 at 12:07, Eric Rescorla wrote: > I assume you would prefer hex, i.e., 0x0303? Yeah, that would be nice: it's recognizably the same as the old one that way. ___ TLS mailing list TLS@ietf.org