Folks,
I have just posted a WIP PR for what I'm calling "Finished Stuffing"
https://github.com/tlswg/tls13-spec/pull/615
I would welcome comments on this direction and whether I am missing
anything important.
OVERVIEW
This PR follows on a bunch of discussions we've had about the redundancy
o
I should also mention that this makes the implementation a fair bit simpler
because:
1. You can make all the decisions on the server side immediately upon
receiving the ClientHello
without waiting for Finished.
2. You don't need to derive early handshake traffic keys.
>From an implementor's persp
I think this is a good idea. It's kind of weird, but it avoids giving the
early Finished such a strange relationship with the handshake transcript.
Also a fan of doing away with multiple PSK identities if we don't need it.
As a bonus, this removes the need to route a "phase" parameter into the
tra
Hi Folks,
The chairs want to make sure this gets some proper review. Please respond
with comments by Friday so we can make some progress on this issue.
Thanks,
J&S
On Tue, Sep 6, 2016 at 11:57 AM, David Benjamin
wrote:
> I think this is a good idea. It's kind of weird, but it avoids giving
Hi,
This proposal does require careful security review as it addresses a
known weakness in non-resumption PSK (see
https://www.ietf.org/mail-archive/web/tls/current/msg20637.html) and
also affects the security proof of PSK even in the resumption case.
Regarding the removal of multiple PSK id
On Wed, Sep 7, 2016 at 6:54 AM, Antoine Delignat-Lavaud <
anto...@delignat-lavaud.fr> wrote:
> Hi,
>
> This proposal does require careful security review as it addresses a known
> weakness in non-resumption PSK (see https://www.ietf.org/mail-arch
> ive/web/tls/current/msg20637.html) and also affec
On Wed, Sep 7, 2016 at 11:11 AM Eric Rescorla wrote:
> On Wed, Sep 7, 2016 at 6:54 AM, Antoine Delignat-Lavaud <
> anto...@delignat-lavaud.fr> wrote:
>
> Regarding whether the placeholder zeros should be part of the transcript
> for the stuffed finished, an argument against it is that it violates
On Wed, Sep 7, 2016 at 8:25 AM, David Benjamin
wrote:
> On Wed, Sep 7, 2016 at 11:11 AM Eric Rescorla wrote:
>
>> On Wed, Sep 7, 2016 at 6:54 AM, Antoine Delignat-Lavaud <
>> anto...@delignat-lavaud.fr> wrote:
>>
>>> Regarding whether the placeholder zeros should be part of the transcript
>>> fo
I don't understand the proposal.
Are you proposing to eliminate resumption_context (RC) from All its current
uses and replace it with the hello_finished extension? Or is this to affect
only certain uses of RC? Which ones?
One important property of RC is that it serves as a binding with the
origin
On Wed, Sep 7, 2016 at 4:02 PM, Hugo Krawczyk
wrote:
> I don't understand the proposal.
> Are you proposing to eliminate resumption_context (RC) from All its
> current uses and replace it with the hello_finished extension?
>
Yes.
> Or is this to affect only certain uses of RC? Which ones?
>
On Wed, Sep 7, 2016 at 7:18 PM, Eric Rescorla wrote:
>
>
> On Wed, Sep 7, 2016 at 4:02 PM, Hugo Krawczyk
> wrote:
>
>> I don't understand the proposal.
>> Are you proposing to eliminate resumption_context (RC) from All its
>> current uses and replace it with the hello_finished extension?
>>
>
>
On Wed, Sep 07, 2016 at 07:43:53PM -0400, Hugo Krawczyk wrote:
> On Wed, Sep 7, 2016 at 7:18 PM, Eric Rescorla wrote:
>
> >
> >
> > On Wed, Sep 7, 2016 at 4:02 PM, Hugo Krawczyk
> > wrote:
> >
> > I also have a problem with names. "Resumption context" is very explicit
> >> about providing, well,
I’m fine with this.
I am strongly in favor of having one PSK identity. ☺
--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Thu, Sep 8, 2016 at 5:29 AM, Ilari Liusvaara
wrote:
> On Wed, Sep 07, 2016 at 07:43:53PM -0400, Hugo Krawczyk wrote:
> > On Wed, Sep 7, 2016 at 7:18 PM, Eric Rescorla wrote:
> >
> > >
> > >
> > > On Wed, Sep 7, 2016 at 4:02 PM, Hugo Krawczyk
> > > wrote:
> > >
> > > I also have a problem wit
On Thu, Sep 08, 2016 at 09:59:22PM -0400, Hugo Krawczyk wrote:
> On Thu, Sep 8, 2016 at 5:29 AM, Ilari Liusvaara
> wrote:
>
> > On Wed, Sep 07, 2016 at 07:43:53PM -0400, Hugo Krawczyk wrote:
> >
> > - The hash has output length at most input length (true for all SHA-2
> > variants)
> >
>
> Just
On 9 September 2016 at 18:22, Ilari Liusvaara wrote:
> Basically, one can't make a distinction between static ("non-resumption)
> and dynamic ("resumption") PSKs here. Because such distinction would
> run into security problems with some other features.
You mean that there is no inherent propert
Hi Ekr,
I have no problems with the suggested change but I would like to note
that we are losing one feature with this change.
Limiting the client to only send a single psk_identity prevents the
client from sending a ticket together with the long-term PSK identity in
the same message. This w
I made a few notes on the pull request. Generally, I support the
change, but I get the sense that it may aid the cryptographic properties
if we keep the resumption_context and do not overload the resumption_psk
as much.
I have a slight (i.e., unjustified) preference for doing
ClientHello-with-blo
On Fri, Sep 09, 2016 at 02:50:59PM -0500, Benjamin Kaduk wrote:
> I made a few notes on the pull request. Generally, I support the
> change, but I get the sense that it may aid the cryptographic properties
> if we keep the resumption_context and do not overload the resumption_psk
> as much.
One p
On Fri, Sep 9, 2016 at 4:22 AM, Ilari Liusvaara
wrote:
> On Thu, Sep 08, 2016 at 09:59:22PM -0400, Hugo Krawczyk wrote:
> > On Thu, Sep 8, 2016 at 5:29 AM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > > On Wed, Sep 07, 2016 at 07:43:53PM -0400, Hugo Krawczyk wrote:
> > >
> > >
On Fri, Sep 09, 2016 at 07:33:21PM -0400, Hugo Krawczyk wrote:
> On Fri, Sep 9, 2016 at 4:22 AM, Ilari Liusvaara
> wrote:
>
> I would much prefer to have two elements associated with such keys. One is
> the key itself and the other is a binder (or whatever other name one
> chooses for it) that c
On 09/09/2016 03:19 PM, Ilari Liusvaara wrote:
> On Fri, Sep 09, 2016 at 02:50:59PM -0500, Benjamin Kaduk wrote:
>> I made a few notes on the pull request. Generally, I support the
>> change, but I get the sense that it may aid the cryptographic properties
>> if we keep the resumption_context an
On Tue, Sep 13, 2016 at 12:04:40PM -0500, Benjamin Kaduk wrote:
>
>
> On 09/09/2016 03:19 PM, Ilari Liusvaara wrote:
> > On Fri, Sep 09, 2016 at 02:50:59PM -0500, Benjamin Kaduk wrote:
>
> >> I have a slight (i.e., unjustified) preference for doing
> >> ClientHello-with-block-of-zeros rather tha
On Tue, Sep 13, 2016 at 12:15 PM, Ilari Liusvaara
wrote:
> On Tue, Sep 13, 2016 at 12:04:40PM -0500, Benjamin Kaduk wrote:
> >
> >
> > On 09/09/2016 03:19 PM, Ilari Liusvaara wrote:
> > > On Fri, Sep 09, 2016 at 02:50:59PM -0500, Benjamin Kaduk wrote:
> >
> > >> I have a slight (i.e., unjustified
On Sat, Sep 17, 2016 at 02:43:49PM -0700, Eric Rescorla wrote:
>
> In this case, I believe that the finished is computed over
> "ClientHello(groups=23,24,29;PSK=foo;shares=23:bar,29:baz,24:quux,..."
>
> But that the handshake transcript is computed over all of:
> "Client: ClientHello(groups=23,24
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
Key changes in this PR:
1. I have merged the HMAC into the PreSharedKey message, where it is
now called "PSK Binder" to make very
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
>
>
> Key changes in this PR:
>
> 1. I have merged the HMAC
On Fri, Oct 7, 2016 at 8:26 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/
On Fri, Oct 07, 2016 at 09:35:40AM -0700, Eric Rescorla wrote:
> On Fri, Oct 7, 2016 at 8:26 AM, Ilari Liusvaara
> wrote:
>
> > On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote:
> > > 4. I've taken a suggestion from David Benjamin to move the negotiation
> > > of the PSK key exchange
On Fri, Oct 7, 2016 at 10:03 AM, Ilari Liusvaara
wrote:
> On Fri, Oct 07, 2016 at 09:35:40AM -0700, Eric Rescorla wrote:
> > On Fri, Oct 7, 2016 at 8:26 AM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > > On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote:
> > > > 4.
On 10/07/2016 12:08 PM, Eric Rescorla wrote:
>
>
> On Fri, Oct 7, 2016 at 10:03 AM, Ilari Liusvaara
> mailto:ilariliusva...@welho.com>> wrote:
>
> On Fri, Oct 07, 2016 at 09:35:40AM -0700, Eric Rescorla wrote:
> > On Fri, Oct 7, 2016 at 8:26 AM, Ilari Liusvaara
> mailto:ilariliusva...@w
On Fri, Oct 7, 2016 at 1:39 PM, Benjamin Kaduk wrote:
> On 10/07/2016 12:08 PM, Eric Rescorla wrote:
>
>
>
> On Fri, Oct 7, 2016 at 10:03 AM, Ilari Liusvaara > wrote:
>
>> On Fri, Oct 07, 2016 at 09:35:40AM -0700, Eric Rescorla wrote:
>> > On Fri, Oct 7, 2016 at 8:26 AM, Ilari Liusvaara <
>> ila
On Fri, Oct 07, 2016 at 01:41:48PM -0700, Eric Rescorla wrote:
> On Fri, Oct 7, 2016 at 1:39 PM, Benjamin Kaduk wrote:
>
> > On 10/07/2016 12:08 PM, Eric Rescorla wrote:
> >
> >
> >
> > On Fri, Oct 7, 2016 at 10:03 AM, Ilari Liusvaara > > wrote:
> >
> >> On Fri, Oct 07, 2016 at 09:35:40AM -0700,
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 a
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/
On Sun, Oct 09, 2016 at 07:10:59AM -0700, 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
On Sun, Oct 9, 2016 at 8:44 AM, Ilari Liusvaara
wrote:
> On Sun, Oct 09, 2016 at 07:10:59AM -0700, Eric Rescorla wrote:
> > On Sun, Oct 9, 2016 at 6:58 AM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > > On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote:
> > > > Aft
On Fri, Oct 7, 2016 at 1:08 PM, Eric Rescorla wrote:
>
>
> On Fri, Oct 7, 2016 at 10:03 AM, Ilari Liusvaara > wrote:
>
>> On Fri, Oct 07, 2016 at 09:35:40AM -0700, Eric Rescorla wrote:
>> > On Fri, Oct 7, 2016 at 8:26 AM, Ilari Liusvaara <
>> ilariliusva...@welho.com>
>> > wrote:
>> >
>> > > On
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 communit
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
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
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
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 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 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
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
46 matches
Mail list logo
