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
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)
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
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
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
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
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
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
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.
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
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
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
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
> 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
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
>
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
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
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
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
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
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,
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
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:
>
>
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) ->
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
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
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*.
[*]
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
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
29 matches
Mail list logo