TLDR: the spec. was clear and easy to implement, but some test vectors
and clarification on what constitutes a Handshake Context would have
helped.
FWIW, please let me share my experience of implementing TLS 1.3.
This month, I have written a TLS 1.3 implementation (named picotls,
available at htt
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
https://www.ietf.org/mailman/listinfo/tls
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 not useful and it implies a significance
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 by saying "future versions
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 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*.
[*] One caveat: you w
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 28, 2016.
>
> Thank
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&S
___
TLS mailing list
TLS@ietf.org
https://ww
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
> arbitrary codepoints at t
> 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
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 th
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 a
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 in use
> (of cour
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 i
On Wed, Oct 12, 2016 at 3:57 PM, Eric Rescorla wrote:
> The 0-RTT traffic key incorporates the ClientHello.Random which is tied
> into the full handshake.
>
Ok, so for the replayed early data to be accepted, an adversary would also
have to swap out CH.Random and the (Finished) message, which wou
On Wed, Oct 12, 2016 at 1:01 PM, David Benjamin
wrote:
> My interpretation was:
>
> 1. Client and server remember the previous selected ALPN protocol in the
> session.
>
> 2. The client may offer whatever ALPN protocols it likes. It does not need
> to match the previous offer list, though it pres
My interpretation was:
1. Client and server remember the previous selected ALPN protocol in the
session.
2. The client may offer whatever ALPN protocols it likes. It does not need
to match the previous offer list, though it presumably will unless you've
got a persistent session cache or so.
3. T
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 Messages",
>> specifically
>> > "ClientHello ... l
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 EncryptedExtensions/CertificateRequest". I'm
> > guessin
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) ap
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 the
> > early
> > > data i
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, which may be all that
> > s
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:
>
> early_data = get_early_data()
>
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 the extension is in the HR
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) -> ZRttReader
> - ZRttReader::g
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 u
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 chan
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 spurious), presumably causing the cl
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 proceed to accept DH versus clien
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 convinced that this is the right change. Re
I agre with Ilari. Currently, the way to reject a request is more than
just saying "no, thanks.".
On 10/12/2016 10:17 AM, Ilari Liusvaara wrote:
> 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
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.
Unfortun
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 of
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 Cer
34 matches
Mail list logo
