Re: [TLS] Finished stuffing/PSK Binders

[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 the extension is in the HRR, and what to do if
>> it isn't.
> Or have every extension be "no change" if not present, and do the
> specified thing to CH if prsent and known, abort if present and
> unknown.

This is an instance of the "require text for every extension" case,
though I think either would work.

> That would waste a bit of space with extensions signaling support
> for some rewrites if the server doesn't use those but retries the
> handshake.
>

I'm having trouble parsing this.  The idea is that the client would
waste some space in the new CH because the server doesn't have a way to
indicate that the client only needs to send a subset of what it sent the
first time around?

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

Re: [TLS] Finished stuffing/PSK Binders

[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 use those but retries the
> > handshake.
> >
> 
> I'm having trouble parsing this.  The idea is that the client would
> waste some space in the new CH because the server doesn't have a way to
> indicate that the client only needs to send a subset of what it sent the
> first time around?

Well, depends on the extension...

Actually, not a major issue, given that there is usually a great amount
of bloat in the second CH (just to make it look like CH, instead of
just transporting what is needed).


-Ilari

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

Re: [TLS] Finished stuffing/PSK Binders

[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 spurious), presumably causing the client to blank its key_share
> > and then proceed to accept DH versus client's previously sent share?
> 
> How about: If key_share isn't in the HRR, the client should replay
> it's old key_share verbatim.  Though I agree that the text should say
> as much.

Yeah, would work.

> Maybe we should require text for every extension that can appear in
> the HRR: what to do if the extension is in the HRR, and what to do if
> it isn't.

Or have every extension be "no change" if not present, and do the
specified thing to CH if prsent and known, abort if present and
unknown.

That would waste a bit of space with extensions signaling support
for some rewrites if the server doesn't use those but retries the
handshake.


-Ilari

___
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 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 client's previously sent share?

How about: If key_share isn't in the HRR, the client should replay
it's old key_share verbatim.  Though I agree that the text should say
as much.

Maybe we should require text for every extension that can appear in
the HRR: what to do if the extension is in the HRR, and what to do if
it isn't.

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

Re: [TLS] Finished stuffing/PSK Binders

[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 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.
> >
> Thanks, I'll look at this. I'll be merging this change (modulo your
> comments) Friday unless there is significant objection.

Well, if reject with in-list group is spurious or not depends on if
there is some hello-altering extension other than key share group
(it isn't if any other extension alters CH).


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 client's previously sent share?

(That kind of thing really plays hell if client has explicit list
of keypairs it considers active for connection).


-Ilari

___
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] 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] 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] Finished stuffing/PSK Binders

[Hugo Krawczyk]

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 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 parameters out of the PSK itself and into a
>> > > > separate message. This cleans things up and also lets us drop the
>> > > > currently non-useful auth_mode parameter.
>> > >
>> > > Eeh... From the text, it seems to currently require the kex modes
>> > > extension if PSK extension is present. Which seems worse than useless
>> > > if the meaning is to get rid of the kex mode parameter from PSK
>> > > extension (since you will have the value anyway, but need to dig it
>> > > from another extension... Blech).
>> >
>> > I guess this is a matter of taste, but what convinced me was that:
>> >
>> > 1. It put all the logic on the server side.
>> > 2. It removed the auth mod parameter.
>> >
>> > Maybe david can say more.
>>
>> I mean if server is to accept PSK, it must now go fishing for another
>> extension, check that it is present and pay attention to values there.
>> As opposed to having the data in where it is needed.
>>
>
> This is a reasonable argument (and the reason I stuffed the binder here).
> However, David's argument was that this applied to *all* PSKs even new
> ones.
>
>
> -Ekr
>
> > > Also, didn't notice what prevents pathology like this (I presume this
>> > > is not allowed):
>> > >
>> > > (Assume PSK with 0RTT allowed, using AES-128-GCM-SHA256)
>> > >
>> > > ClientHello[Ciphers=CHACHA20-POLY1305-SHA256, EarlyDataIndication]
>> --->
>> > > [0-RTT data, encrypted using AES-128-GCM-SHA256]
>> > > <-- ServerHello[Cipher=CHACHA20-POLY1305-SHA256]
>> > > <-- EncryptedExtensions[EarlyDataIndication]
>> > >
>> > > Note the record protection algorithm mismatch.
>> > >
>> >
>> > Yes, this is forbidden by the combination of:
>> >
>> > "The parameters for the 0-RTT data (symmetric cipher suite,
>> > ALPN, etc.) are the same as those which were negotiated in the
>> connection
>> > which established the PSK.  The PSK used to encrypt the early data
>> > MUST be the first PSK listed in the client's "pre_shared_key"
>> extension."
>> > (though I think I just recently added cipher suite).
>> >
>> > and:
>> > "Any ticket MUST only be resumed with a cipher suite that is identical
>> > to that negotiated connection where the ticket was established."
>>
>> If 0-RTT is used with manually provisioned PSKs (might not be allowed
>> currently, but might be allowed soon), does that still hold?
>>
>> Also, I think it is problematic that externally provisioned PSKs can
>> be used with any protection with given prf-hash, while NST-provisioned
>> PSKs can only be used with one protection and prf-hash.
>>
>> 0-RTT requirements are separate matter, since those would apply to all.
>>
>> The original purpose of resumption-as-PSK was AFAIK to unify the two
>> mechanisms to simplify things. Therefore those two should be as similar
>> as possible.
>>
>> >
>> > Also, to straightforwardly prove that collision resistance of HKDF and
>> > > HMAC (as used) follows from collision resistance of the underlying
>> hash
>> > > function, yon need to take the output to be at least the hash output
>> > > size. As otherwise it is not guaranteed that any collision in HKDF or
>> > > HMAC can be reduced into collision of the underlying hash.
>> > >
>> >
>> > Right. I have some text here but please feel free to suggest more.
>>
>> Yes, but the text says 256 bit output is enough. One isn't guaranteed
>> to be able to reduce such collision to collision of >256 bit hash.
>>
>> (In fact, if the hash is e.g. 384 bit, 256-bit collisions are extremely
>> unlikely to reduce).
>>
>
> Right. I can update.
>


​
​I think that allowing truncation (e.g. for SHA-512) with at least 256-bit
output should be fine too without forcing implementations to work with,
say, 512-bit keys.
While I agree that we don't have generic reductions from collision
resistance of a hash function to its truncations, such (long enough)
truncations are believed to inherit collision resistance. For example,
SHA-512 is "officially" allowed to be truncated and it is the way SHA-384
is defined. Also, a collision on a 256-bit truncated output would be a
MAJOR weakness for any hash function, in particular "breaking" the
treatment of the function as a random oracle (such weakness must lead to
abandoning that hash function).

What do cryptanalysts think?

Hugo
​
 ​


>
> -Ekr
>
>
>>
>>
>>
>> -Ilari
>>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS 

Re: [TLS] Finished stuffing/PSK Binders

[Eric Rescorla]

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:
> > > > 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.
> >
>
> That creates a bit of a edge case, where the server might need to pull
> client's share accross retry.
>
> (Since if group is OK, the group is not included in HRR, which presumably
> causes the client to blank its KeyShare).
>

I think we would change that rule, probably.

-Ekr


>
>
> Also, doing some size calculations:
>
> ClientHello with "smallest group" rule is ~200 bytes with reasonable
> parameters (I got a dump of one TLS 1.3 draft-16 CH from my TLS stack,
> it is 265 bytes, but would be 196 with "smallest group" rule).
>
> The amount of space needed to freeze (octet) SHA-256 is 32+63+8=103
> octets. And the space needed to freeze (octet) SHA-384 is 64+127+16=207
> bytes (for full SHA-256 and SHA-384, add one more byte).
>
> So if selecting ciphersuite using SHA-384, the state size might be
> comparable to ClientHello size.
>
>
> -Ilari
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Finished stuffing/PSK Binders

[Ilari Liusvaara]

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 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.
> 

That creates a bit of a edge case, where the server might need to pull
client's share accross retry.

(Since if group is OK, the group is not included in HRR, which presumably
causes the client to blank its KeyShare).



Also, doing some size calculations:

ClientHello with "smallest group" rule is ~200 bytes with reasonable
parameters (I got a dump of one TLS 1.3 draft-16 CH from my TLS stack,
it is 265 bytes, but would be 196 with "smallest group" rule).

The amount of space needed to freeze (octet) SHA-256 is 32+63+8=103
octets. And the space needed to freeze (octet) SHA-384 is 64+127+16=207
bytes (for full SHA-256 and SHA-384, add one more byte).

So if selecting ciphersuite using SHA-384, the state size might be
comparable to ClientHello size.


-Ilari

___
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 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.

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] Finished stuffing/PSK Binders

[Ilari Liusvaara]

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).

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] Finished stuffing/PSK Binders

[Eric Rescorla]

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 <
>> ilariliusva...@welho.com>
>> > 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 parameters out of the PSK itself and into a
>> > > > separate message. This cleans things up and also lets us drop the
>> > > > currently non-useful auth_mode parameter.
>> > >
>> > > Eeh... From the text, it seems to currently require the kex modes
>> > > extension if PSK extension is present. Which seems worse than useless
>> > > if the meaning is to get rid of the kex mode parameter from PSK
>> > > extension (since you will have the value anyway, but need to dig it
>> > > from another extension... Blech).
>> >
>> > I guess this is a matter of taste, but what convinced me was that:
>> >
>> > 1. It put all the logic on the server side.
>>
>
> I was going to ask whether this also includes the decision on whether to
> send a Certificate to authenticate the server (even for PSK modes), but it
> looks like this change is intentionally removing the ability to do PSK
> keyex and auth with a certificate?
>

Yes, while preserving the ability to add it later by adding a PskAuthMode
extension parallel to this one.

-Ekr


> > 2. It removed the auth mod parameter.
>> >
>> > Maybe david can say more.
>>
>> I mean if server is to accept PSK, it must now go fishing for another
>> extension, check that it is present and pay attention to values there.
>> As opposed to having the data in where it is needed.
>>
>
> This is a reasonable argument (and the reason I stuffed the binder here).
> However, David's argument was that this applied to *all* PSKs even new
> ones.
>
>
> Implementations already have to do some amount of "scan through all
> extensions to detect certain things, do some initial processing, and then
> finish process everything [else]", not least because SNI can change what
> cert types you have, configuration knobs, etc..  So, yes it's bad, but how
> bad is it in a relative sense?
>
> I think there is some value in the client indicating to the server whether
> it doesn't want to do psk_dhe (or doesn't want to do pure psk) for future
> NSTs, though it's perhaps not of the utmost importance.  That property does
> support a separate psk_key_exchange_modes extension in preference  to
> rolling it into pre_shared_keys (as a separate list next to identities and
> binders), but it seems to only be a weak argument for separation.  I do
> think that keeping the psk kex mode orthogonal to the individual keys is
> helpful, though.
>
> Anyway, maybe it's time to bite the bullet and actually write up the
> description of the proper procedure for ClientHello processing (scan
> extensions for SNI, load up servername-specific config+cert/key, etc.).
> Which would make this stuff any prettier, but would at least help people
> not get it wrong.
>
> -Ben
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Finished stuffing/PSK Binders

[Benjamin Kaduk]

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
> >
> > 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 parameters out of the PSK itself and
> into a
> > > > separate message. This cleans things up and also lets us
> drop the
> > > > currently non-useful auth_mode parameter.
> > >
> > > Eeh... From the text, it seems to currently require the kex modes
> > > extension if PSK extension is present. Which seems worse than
> useless
> > > if the meaning is to get rid of the kex mode parameter from PSK
> > > extension (since you will have the value anyway, but need to
> dig it
> > > from another extension... Blech).
> >
> > I guess this is a matter of taste, but what convinced me was that:
> >
> > 1. It put all the logic on the server side.
>

I was going to ask whether this also includes the decision on whether to
send a Certificate to authenticate the server (even for PSK modes), but
it looks like this change is intentionally removing the ability to do
PSK keyex and auth with a certificate?

> > 2. It removed the auth mod parameter.
> >
> > Maybe david can say more.
>
> I mean if server is to accept PSK, it must now go fishing for another
> extension, check that it is present and pay attention to values there.
> As opposed to having the data in where it is needed.
>
>
> This is a reasonable argument (and the reason I stuffed the binder here).
> However, David's argument was that this applied to *all* PSKs even new
> ones.
>

Implementations already have to do some amount of "scan through all
extensions to detect certain things, do some initial processing, and
then finish process everything [else]", not least because SNI can change
what cert types you have, configuration knobs, etc..  So, yes it's bad,
but how bad is it in a relative sense?

I think there is some value in the client indicating to the server
whether it doesn't want to do psk_dhe (or doesn't want to do pure psk)
for future NSTs, though it's perhaps not of the utmost importance.  That
property does support a separate psk_key_exchange_modes extension in
preference  to rolling it into pre_shared_keys (as a separate list next
to identities and binders), but it seems to only be a weak argument for
separation.  I do think that keeping the psk kex mode orthogonal to the
individual keys is helpful, though.

Anyway, maybe it's time to bite the bullet and actually write up the
description of the proper procedure for ClientHello processing (scan
extensions for SNI, load up servername-specific config+cert/key, etc.). 
Which would make this stuff any prettier, but would at least help people
not get it wrong.

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

Re: [TLS] Finished stuffing/PSK Binders

[Eric Rescorla]

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. I've taken a suggestion from David Benjamin to move the
> negotiation
> > > > of the PSK key exchange parameters out of the PSK itself and into a
> > > > separate message. This cleans things up and also lets us drop the
> > > > currently non-useful auth_mode parameter.
> > >
> > > Eeh... From the text, it seems to currently require the kex modes
> > > extension if PSK extension is present. Which seems worse than useless
> > > if the meaning is to get rid of the kex mode parameter from PSK
> > > extension (since you will have the value anyway, but need to dig it
> > > from another extension... Blech).
> >
> > I guess this is a matter of taste, but what convinced me was that:
> >
> > 1. It put all the logic on the server side.
> > 2. It removed the auth mod parameter.
> >
> > Maybe david can say more.
>
> I mean if server is to accept PSK, it must now go fishing for another
> extension, check that it is present and pay attention to values there.
> As opposed to having the data in where it is needed.
>

This is a reasonable argument (and the reason I stuffed the binder here).
However, David's argument was that this applied to *all* PSKs even new ones.


-Ekr

> > Also, didn't notice what prevents pathology like this (I presume this
> > > is not allowed):
> > >
> > > (Assume PSK with 0RTT allowed, using AES-128-GCM-SHA256)
> > >
> > > ClientHello[Ciphers=CHACHA20-POLY1305-SHA256, EarlyDataIndication]
> --->
> > > [0-RTT data, encrypted using AES-128-GCM-SHA256]
> > > <-- ServerHello[Cipher=CHACHA20-POLY1305-SHA256]
> > > <-- EncryptedExtensions[EarlyDataIndication]
> > >
> > > Note the record protection algorithm mismatch.
> > >
> >
> > Yes, this is forbidden by the combination of:
> >
> > "The parameters for the 0-RTT data (symmetric cipher suite,
> > ALPN, etc.) are the same as those which were negotiated in the connection
> > which established the PSK.  The PSK used to encrypt the early data
> > MUST be the first PSK listed in the client's "pre_shared_key" extension."
> > (though I think I just recently added cipher suite).
> >
> > and:
> > "Any ticket MUST only be resumed with a cipher suite that is identical
> > to that negotiated connection where the ticket was established."
>
> If 0-RTT is used with manually provisioned PSKs (might not be allowed
> currently, but might be allowed soon), does that still hold?
>
> Also, I think it is problematic that externally provisioned PSKs can
> be used with any protection with given prf-hash, while NST-provisioned
> PSKs can only be used with one protection and prf-hash.
>
> 0-RTT requirements are separate matter, since those would apply to all.
>
> The original purpose of resumption-as-PSK was AFAIK to unify the two
> mechanisms to simplify things. Therefore those two should be as similar
> as possible.
>
> >
> > Also, to straightforwardly prove that collision resistance of HKDF and
> > > HMAC (as used) follows from collision resistance of the underlying hash
> > > function, yon need to take the output to be at least the hash output
> > > size. As otherwise it is not guaranteed that any collision in HKDF or
> > > HMAC can be reduced into collision of the underlying hash.
> > >
> >
> > Right. I have some text here but please feel free to suggest more.
>
> Yes, but the text says 256 bit output is enough. One isn't guaranteed
> to be able to reduce such collision to collision of >256 bit hash.
>
> (In fact, if the hash is e.g. 384 bit, 256-bit collisions are extremely
> unlikely to reduce).
>

Right. I can update.

-Ekr


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

Re: [TLS] Finished stuffing/PSK Binders

[Ilari Liusvaara]

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 parameters out of the PSK itself and into a
> > > separate message. This cleans things up and also lets us drop the
> > > currently non-useful auth_mode parameter.
> >
> > Eeh... From the text, it seems to currently require the kex modes
> > extension if PSK extension is present. Which seems worse than useless
> > if the meaning is to get rid of the kex mode parameter from PSK
> > extension (since you will have the value anyway, but need to dig it
> > from another extension... Blech).
> 
> I guess this is a matter of taste, but what convinced me was that:
> 
> 1. It put all the logic on the server side.
> 2. It removed the auth mod parameter.
> 
> Maybe david can say more.

I mean if server is to accept PSK, it must now go fishing for another
extension, check that it is present and pay attention to values there.
As opposed to having the data in where it is needed.
 
> > Also, didn't notice what prevents pathology like this (I presume this
> > is not allowed):
> >
> > (Assume PSK with 0RTT allowed, using AES-128-GCM-SHA256)
> >
> > ClientHello[Ciphers=CHACHA20-POLY1305-SHA256, EarlyDataIndication] --->
> > [0-RTT data, encrypted using AES-128-GCM-SHA256]
> > <-- ServerHello[Cipher=CHACHA20-POLY1305-SHA256]
> > <-- EncryptedExtensions[EarlyDataIndication]
> >
> > Note the record protection algorithm mismatch.
> >
> 
> Yes, this is forbidden by the combination of:
> 
> "The parameters for the 0-RTT data (symmetric cipher suite,
> ALPN, etc.) are the same as those which were negotiated in the connection
> which established the PSK.  The PSK used to encrypt the early data
> MUST be the first PSK listed in the client's "pre_shared_key" extension."
> (though I think I just recently added cipher suite).
> 
> and:
> "Any ticket MUST only be resumed with a cipher suite that is identical
> to that negotiated connection where the ticket was established."
 
If 0-RTT is used with manually provisioned PSKs (might not be allowed
currently, but might be allowed soon), does that still hold?

Also, I think it is problematic that externally provisioned PSKs can
be used with any protection with given prf-hash, while NST-provisioned
PSKs can only be used with one protection and prf-hash.

0-RTT requirements are separate matter, since those would apply to all.

The original purpose of resumption-as-PSK was AFAIK to unify the two
mechanisms to simplify things. Therefore those two should be as similar
as possible.
 
> 
> Also, to straightforwardly prove that collision resistance of HKDF and
> > HMAC (as used) follows from collision resistance of the underlying hash
> > function, yon need to take the output to be at least the hash output
> > size. As otherwise it is not guaranteed that any collision in HKDF or
> > HMAC can be reduced into collision of the underlying hash.
> >
> 
> Right. I have some text here but please feel free to suggest more.

Yes, but the text says 256 bit output is enough. One isn't guaranteed
to be able to reduce such collision to collision of >256 bit hash.

(In fact, if the hash is e.g. 384 bit, 256-bit collisions are extremely
unlikely to reduce).



-Ilari

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

Re: [TLS] Finished stuffing/PSK Binders

[Eric Rescorla]

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/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 clear what the purpose of the
> > HMAC it is (this suggestion due to Karthik Bhargavan) This also makes
> > implementation somewhat easier and avoids creating another extension.
> >
> > 2. It is now possible to have >1 PSK, each with its own binder.
> >
> > 3. The binder is now computed over the ClientHello prefix rather than
> > filling the MAC with zeroes.
> >
> > 4. I've taken a suggestion from David Benjamin to move the negotiation
> > of the PSK key exchange parameters out of the PSK itself and into a
> > separate message. This cleans things up and also lets us drop the
> > currently non-useful auth_mode parameter.
>
> Eeh... From the text, it seems to currently require the kex modes
> extension if PSK extension is present. Which seems worse than useless
> if the meaning is to get rid of the kex mode parameter from PSK
> extension (since you will have the value anyway, but need to dig it
> from another extension... Blech).
>

I guess this is a matter of taste, but what convinced me was that:

1. It put all the logic on the server side.
2. It removed the auth mod parameter.

Maybe david can say more.


> This text is still a bit rough but I think shows the right direction.
>
> I would talk about PSKs established by NST, not resumption PSKs.
>

Willdo.



>
> Also, didn't notice what prevents pathology like this (I presume this
> is not allowed):
>
> (Assume PSK with 0RTT allowed, using AES-128-GCM-SHA256)
>
> ClientHello[Ciphers=CHACHA20-POLY1305-SHA256, EarlyDataIndication] --->
> [0-RTT data, encrypted using AES-128-GCM-SHA256]
> <-- ServerHello[Cipher=CHACHA20-POLY1305-SHA256]
> <-- EncryptedExtensions[EarlyDataIndication]
>
> Note the record protection algorithm mismatch.
>

Yes, this is forbidden by the combination of:

"The parameters for the 0-RTT data (symmetric cipher suite,
ALPN, etc.) are the same as those which were negotiated in the connection
which established the PSK.  The PSK used to encrypt the early data
MUST be the first PSK listed in the client's "pre_shared_key" extension."
(though I think I just recently added cipher suite).

and:
"Any ticket MUST only be resumed with a cipher suite that is identical
to that negotiated connection where the ticket was established."



Also, to straightforwardly prove that collision resistance of HKDF and
> HMAC (as used) follows from collision resistance of the underlying hash
> function, yon need to take the output to be at least the hash output
> size. As otherwise it is not guaranteed that any collision in HKDF or
> HMAC can be reduced into collision of the underlying hash.
>

Right. I have some text here but please feel free to suggest more.

-Ekr




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

Re: [TLS] Finished stuffing/PSK Binders

[Ilari Liusvaara]

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 into the PreSharedKey message, where it is
> now called "PSK Binder" to make very clear what the purpose of the
> HMAC it is (this suggestion due to Karthik Bhargavan) This also makes
> implementation somewhat easier and avoids creating another extension.
> 
> 2. It is now possible to have >1 PSK, each with its own binder.
> 
> 3. The binder is now computed over the ClientHello prefix rather than
> filling the MAC with zeroes.
> 
> 4. I've taken a suggestion from David Benjamin to move the negotiation
> of the PSK key exchange parameters out of the PSK itself and into a
> separate message. This cleans things up and also lets us drop the
> currently non-useful auth_mode parameter.

Eeh... From the text, it seems to currently require the kex modes
extension if PSK extension is present. Which seems worse than useless
if the meaning is to get rid of the kex mode parameter from PSK
extension (since you will have the value anyway, but need to dig it
from another extension... Blech).

> This text is still a bit rough but I think shows the right direction.

I would talk about PSKs established by NST, not resumption PSKs.
 

Also, didn't notice what prevents pathology like this (I presume this
is not allowed):

(Assume PSK with 0RTT allowed, using AES-128-GCM-SHA256)

ClientHello[Ciphers=CHACHA20-POLY1305-SHA256, EarlyDataIndication] --->
[0-RTT data, encrypted using AES-128-GCM-SHA256]
<-- ServerHello[Cipher=CHACHA20-POLY1305-SHA256]
<-- EncryptedExtensions[EarlyDataIndication]

Note the record protection algorithm mismatch.


Also, to straightforwardly prove that collision resistance of HKDF and
HMAC (as used) follows from collision resistance of the underlying hash
function, yon need to take the output to be at least the hash output
size. As otherwise it is not guaranteed that any collision in HKDF or
HMAC can be reduced into collision of the underlying hash.




-Ilari

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

[TLS] Finished stuffing/PSK Binders

[Eric Rescorla]

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 clear what the purpose of the
HMAC it is (this suggestion due to Karthik Bhargavan) This also makes
implementation somewhat easier and avoids creating another extension.

2. It is now possible to have >1 PSK, each with its own binder.

3. The binder is now computed over the ClientHello prefix rather than
filling the MAC with zeroes.

4. I've taken a suggestion from David Benjamin to move the negotiation
of the PSK key exchange parameters out of the PSK itself and into a
separate message. This cleans things up and also lets us drop the
currently non-useful auth_mode parameter.

This text is still a bit rough but I think shows the right direction.

As usual, comments welcome, but I think the key question we need
to resolve is whether we really need multiple PSKs. It's clearly
simpler not to support them but it seems like we need to worry about
the case where we are resuming a session created with a PSK. I've come
to the conclusion that if we want to have multiple concurrent PSKs at
all, then this is the right structure, rather than having one PSK and
using HRR to fix it.

ISTM that the other major alternatives are to say:

1. You can't resume sessions created with a PSK.
2. Tickets created in sessions created with a PSK have a hard lifetime
   value and it's a failure if the server forgets during the lifetime
   (this seems like it's going to interact badly with clock skew).

Note that if we decide that we only want one PSK, I'll just revise the
PreSharedKey section to have one, not a list [0].

Thanks,
-Ekr

[0] In fairness, it's also worth noting that if we decide to only
have one, it's possible in the future to replace the PreSharedKey
extension with a MultiplePreSharedKey extension.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Finished stuffing

[Ilari Liusvaara]

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 than prefix-of-ClientHello.  (Is
> >> there a reason to require this extension to be the last one with
> >> block-of-zeros?  Clearly there is for prefix-of-ClientHello.)
> > What about the case where client tries DHE-PSK and gets attempt
> > rejected because of missing group (or because address verification)?
> > 0-RTT is gone yes, but the PSK attempt isn't.
> >
> > What happens to the hash in this case?
> >
> >
> 
> I feel like I must be missing something, but I don't really understand
> the question.  (Sadly, waiting in the hope that someone else did
> understand and would respond didn't work.)  The 0-RTT failed, so the
> full handshake will have an actual Finished message, with a different
> hash calculated (including over the "hello_finished" extension).  The
> most plausible way I could interpret the question seems to be asking
> about the lack of Hash(resumption_context) in the 1-RTT Finished, but
> the security properties of that should be the same as for the
> hello_finished, so I'm still puzzled.
> 
> Sorry for being dense...

I mean the following case (perhaps bit misconfigured server):

Client: 
ClientHello(groups=23,24,29;PSK=foo;shares=23:bar,29:baz,...,finished=zot)
Server: HelloRetryRequest(group=24)
Client: 
ClientHello(groups=23,24,29;PSK=foo;shares=23:bar,29:baz,24:quux,...,finished=???)


What is the finished data calculated over in the second case?


-Ilari

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

Re: [TLS] Finished stuffing

[Benjamin Kaduk]

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 and do not overload the resumption_psk
>> as much.
> One problem with this is that authentication_methods can include
> nontrivial methods even for "static" PSKs, and if server takes such
> method, you have an attack unless you bind the PSK secret used. And
> "static" PSKs don't have resumption_context.

Agreed.

>  
> And I would expect that someone will be crazy enough to try to
> provision "static" PSK with the information required to perform
> 0-RTT (ALPN (or indication there is none) and associated cipher)...

Wasn't Hannes just asking about that? ;)

>> I have a slight (i.e., unjustified) preference for doing
>> ClientHello-with-block-of-zeros rather than prefix-of-ClientHello.  (Is
>> there a reason to require this extension to be the last one with
>> block-of-zeros?  Clearly there is for prefix-of-ClientHello.)
> What about the case where client tries DHE-PSK and gets attempt
> rejected because of missing group (or because address verification)?
> 0-RTT is gone yes, but the PSK attempt isn't.
>
> What happens to the hash in this case?
>
>

I feel like I must be missing something, but I don't really understand
the question.  (Sadly, waiting in the hope that someone else did
understand and would respond didn't work.)  The 0-RTT failed, so the
full handshake will have an actual Finished message, with a different
hash calculated (including over the "hello_finished" extension).  The
most plausible way I could interpret the question seems to be asking
about the lack of Hash(resumption_context) in the 1-RTT Finished, but
the security properties of that should be the same as for the
hello_finished, so I'm still puzzled.

Sorry for being dense...

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

Re: [TLS] Finished stuffing

[Ilari Liusvaara]

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 consists of a context string or digest associated to
> that key. Then, you would use the key to key crypto algorithms and use the
> descriptor as a binder to the key's original context, usually as input to a
> crypto algorithm (and not as a key). This will make the functionality of
> each element (key or binder) more explicit and will make it clear when is
> that we need collision resistance and when we don't.
 
If one can really have PSKs that lack "binders", then one would really
need to ban nontrivial authentication with those PSKs.

That is:
- If the PSK lacks a "binder", then:
  * Client MUST send auth_modes = [psk_ke] (i.e. 0x01, 0x00) with such
PSK.
  * Server MUST abort with illegal_parameter if anything else is sent.
  * Client MUST abort with insufficient_security if the server tries to
use any authentication mode except psk_ke.
  * Client MUST NOT send either early_data or hello_finished/hello_binder
  * Server MUST abort with handshake_failure if either extension is
present.
- If the PSK has a "binder", then:
  * hello_finished/hello_binder extension MUST be present and have the
correct value.
  * If it is not present, server MUST abort with missing_extension.
  * If it is incorrect, server MUST abort with decrypt_error.


(The point of all those "MUST abort" requirements is to try to weed out
implementation that might do unsafe things to the extent possible).


-Ilari

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

Re: [TLS] Finished stuffing

[Benjamin Kaduk]

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-block-of-zeros rather than prefix-of-ClientHello.  (Is
there a reason to require this extension to be the last one with
block-of-zeros?  Clearly there is for prefix-of-ClientHello.)

-Ben

On 09/06/2016 11:49 PM, Joseph Salowey wrote:
> 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
>
> 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 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 traffic key calculation since we'll never derive more
> than one epoch off of the same traffic secret. Combine that with
> the two-ladder KeyUpdate and we no longer need any concatenation
> or other label-munging at all. Simply use labels "key" and "iv"
> and the record-layer just exposes a single UseTrafficSecret
> function which saves the traffic secret (for KeyUpdate), derives
> the traffic keys, and engages the new AEAD in one swoop without
> mucking about with phases, traffic directions, whether we are
> client or server, etc.
>
> David
>
> On Thu, Sep 1, 2016 at 6:19 PM Eric Rescorla  > wrote:
>
> 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 perspective, this outweighs the messing
> around with the ClientHello buffer.
> -Ekr
>
>
> On Thu, Sep 1, 2016 at 3:04 PM, Eric Rescorla  > wrote:
>
> 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
> of Finished and resumption_ctx. This PR makes the
> following changes:
>
> - Replace the 0-RTT Finished with an extension you send in the
>   ClientHello *whenever* you do PSK.
> - Get rid of resumption context (because it is now replaced by
>   the ClientHello.hello_finished.
>
>
> RATIONALE
> The reasoning for this change is:
>
> - With ordinary PSK you don't get any assurance that the
> other side
>   knows the PSK.
>
> - With 0-RTT you get some (subject to the usual anti-replay
>   guarantees) via the Finished message.
>
> - If we were to include the 0-RTT Finished message in the
> handshake
>   transcript, then we wouldn't need the resumption context
> because
>   the transcript would transitively include the PSK via
> the Finished.
>
> So the natural thing to do would be to always send 0-RTT
> Finished
> but unfortunately:
>
> 1. You can't just send the 0-RTT Finished whenever you do
> PSK because
>that causes potential compat problems with mixed
> 1.3/1.2 networks
>(the same ones we have with 0-RTT, but at least that's
> opt-in).
>
> 2. You also can't send the 0-RTT Finished with PSK because
> you can
>currently offer multiple PSK identities.
>
> The on-list discussion has suggested we could relax
> condition #2 and
> only have one identity. And we can fix condition #1 by
> stuffing the
> Finished in an extension (with some hacks to make this
> easier). 

Re: [TLS] Finished stuffing

[Hannes Tschofenig]

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 was previously possible and useful since the 
server could delete state (based on local policy) prior to the indicated 
ticket lifetime.


Ciao
Hannes

On 09/02/2016 12:04 AM, Eric Rescorla wrote:

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
of Finished and resumption_ctx. This PR makes the following changes:

- Replace the 0-RTT Finished with an extension you send in the
  ClientHello *whenever* you do PSK.
- Get rid of resumption context (because it is now replaced by
  the ClientHello.hello_finished.


RATIONALE
The reasoning for this change is:

- With ordinary PSK you don't get any assurance that the other side
  knows the PSK.

- With 0-RTT you get some (subject to the usual anti-replay
  guarantees) via the Finished message.

- If we were to include the 0-RTT Finished message in the handshake
  transcript, then we wouldn't need the resumption context because
  the transcript would transitively include the PSK via the Finished.

So the natural thing to do would be to always send 0-RTT Finished
but unfortunately:

1. You can't just send the 0-RTT Finished whenever you do PSK because
   that causes potential compat problems with mixed 1.3/1.2 networks
   (the same ones we have with 0-RTT, but at least that's opt-in).

2. You also can't send the 0-RTT Finished with PSK because you can
   currently offer multiple PSK identities.

The on-list discussion has suggested we could relax condition #2 and
only have one identity. And we can fix condition #1 by stuffing the
Finished in an extension (with some hacks to make this easier). This
PR enacts that.


FAQS
- What gets included in the handshake transcript?
  The whole ClientHello including the computed hello_finished extension.

- Isn't this a hassle to implement?
  It turns out not to be. The basic reason is that at the point where
  the client sends the ClientHello and the server processes, it doesn't
  yet know which Hash will be chosen for HKDF and so NSS (and I believe
  other stacks) buffers the ClientHello in plaintext, so hashing only
  part of it is easy. I've done it in NSS and this part is quite easy.


POTENTIAL VARIATIONS/TODOs
There are a number of possible variations we might want to look at:

1. Moving obfuscated_ticket_age to its own extension (out of
   early_data_indication). This provides additional anti-replay
   for the CH at the 0.5RTT sending point. I believe we should
   make this change.

2. Tweaking the data to be hashed to just hash the ClientHello
   prefix without the 0-filled verify_data. This is not significantly
   harder or easier to implement and basically depends on whether
   you prefer the invariant of "always hash complete messages" or
   "always hash valid pieces of transcript". See above for notes
   on buffering.

3. Allow multiple PSKs. Technically you could make this design
   work with >1 PSK but stuffing multiple verify_data values in
   the ClientHello. E.g,,

  opaque FinishedValue<0..255>;

  struct {
 FinishedValue finisheds<0..2^16-1>;
  } HelloFinished;

   Based on the list discussion, it seems like nobody wants >1 PSK,
   so I think one is simpler; I just wanted to note that these
   changes weren't totally coupled.

4. External context values. Several people have pointed out that it
   might be convenient to have an external context value hashed
   into the transcript. One way to do this would be to include
   it under the Finished. That's not difficult if people want to,
   with the default being empty.

5. Hugo brought up on the list that we need to make very clear that
   the "hello_finished" is being used to bind the handshakes and
   that it depends on collision resistance. I have not forgotten this
   and text on that point would be appreciated.

Comments welcome.
-Ekr



___
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] Finished stuffing

[Martin Thomson]

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 property that forces separation
between sessions that use resumption vs. those that use a regular PSK.
Though the former is bound to an ALPN value and cipher suite (and
maybe some other things, like server identity) and cannot be used
unless those values remain fixed, whereas the latter is not.

We're imposing those restrictions artificially for convenience for the
most part, though 0-RTT can be used to justify the two values I
mentioned.  Given that you need the same coupling of PSK to
ALPN+cipher suite if you intend to use a non-resumption PSK for 0-RTT,
maybe instead we can fix your "problem" by identifying what needs to
be bound and forcing them to remain bound for all PSKs.  (I use scare
quotes here because I'm not convinced that it is a problem worth
worrying about.)

That limits choice, but it would remove any divergence between the two.

Note that we already couple the hash function to a PSK for very good
reasons.  So you can't use both ChaCha and AES-256 with the same PSK.

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

Re: [TLS] Finished stuffing

[Ilari Liusvaara]

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 curious: Can you explain the need for this property? Note that if a
> key to HMAC is  ​larger than the (compression) function output size then
> this key is first hashed into a full output hence preserving CR.

Simply me not bothering to figure out what the heck HMAC does if this
isn't true (or if it is even well-defined in all cases).

> - HKDF-extract salt length is constant (in current draft, always hash_olen)
> > - HKDF-expand PRK length is constant (in current draft, always hash_olen)
> > - The HKDF-expand output output length is at least hash output length
> >   (in current draft, hash_olen except in key expansions).
> >
> 
> These are a lot of restrictions that no one has spelled out as conditions
> on the KDF and they do not follow from the natural properties of KDFs.
> Collision resistance is never needed as far as I can tell for generation of
> keys or to compute PRF and/or MAC values (e.g., for the original
> functionality of Finished that is essentially a MAC/PRF on the transcript).
> The reason we find ourselves considering the CR properties of HKDF is that
> we are using it to derive *strings* that serve as binders/digests of past
> transcripts. Luckily, HKDF with the right hash functions can provide that
> functionality but it is not a native KDF functionality.

So I presume some more text for Security Considerations...
 
> I do not mean this as an academic discussion (although we could have that
> too) but as a warning for future (if not present) misuse and an obstacle in
> replacing HKDF in the future.
> I would be much happier if we had a clear distinction between PRF/MAC
> ​computations, KDF computations and digest computations., even if we
> currently used HKDF for all these functions.

Unfortunately there are things like exporter outputs, that need to be
both "secret" (i.e. "keys") and "nonces" (i.e. "binders"). At least if
application wants so... Dropping either would cause MAJOR security
problems.

I think those and the dynamically provisioned PSKs are the only ones
that have that property of being both key and binder.

> > It is a bit more problematic than that:
> >
> > The hello_finished / "PSK Creation Binder" derives from the PSK key.
> >
> > Deriving separate value in context of dynamic PSK provisioning does not
> > work properly as "static" PSKs lack this value, and if one then tries to
> > use such key with combined authentication, you got an attack[1].
> >
> 
> ​I could not follow this argument.
 
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.



-Ilari

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

Re: [TLS] Finished stuffing

[Hugo Krawczyk]

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 with names. "Resumption context" is very explicit
> > >> about providing, well, resumption context.
> > >> "Hello_Finished", in turn, means nothing.
> > >> Also, RC may better match the notion of "binder" hence more naturally
> > >> requiring collision resistance, while all Finished uses in TLS (1.3
> and
> > >> before) have a MAC functionality (for which, say, 128 bits are good
> enough)
> > >> and it would be better not to abuse them for other uses.
> > >>
> > >
> > > Two points about this:
> > >
> > > 1. The Finished in TLS 1.3 is always Hash.length, and our minimum hash
> is
> > > SHA-256, so I believe we have enough strength here. We could of course
> > > require a minimum size.
> > >
> >
> > ​If you keep this, you definitely need to have a minimum size
> specification
> > in boldface.
>
> Well, the PRF hash is already assumed to be CR, and if HKDF is used with
> certain restrictions, it preserves CR:
>
> - The hash has output length at most input length (true for all SHA-2
> variants)
>

Just curious: Can you explain the need for this property? Note that if a
key to HMAC is  ​larger than the (compression) function output size then
this key is first hashed into a full output hence preserving CR.


- HKDF-extract salt length is constant (in current draft, always hash_olen)
> - HKDF-expand PRK length is constant (in current draft, always hash_olen)
> - The HKDF-expand output output length is at least hash output length
>   (in current draft, hash_olen except in key expansions).
>

These are a lot of restrictions that no one has spelled out as conditions
on the KDF and they do not follow from the natural properties of KDFs.
Collision resistance is never needed as far as I can tell for generation of
keys or to compute PRF and/or MAC values (e.g., for the original
functionality of Finished that is essentially a MAC/PRF on the transcript).
The reason we find ourselves considering the CR properties of HKDF is that
we are using it to derive *strings* that serve as binders/digests of past
transcripts. Luckily, HKDF with the right hash functions can provide that
functionality but it is not a native KDF functionality.

I do not mean this as an academic discussion (although we could have that
too) but as a warning for future (if not present) misuse and an obstacle in
replacing HKDF in the future.
I would be much happier if we had a clear distinction between PRF/MAC
​computations, KDF computations and digest computations., even if we
currently used HKDF for all these functions.


> Furthermore Finished construction uses HMAC. There for CR-preserving,
> one needs key to be of constant length (it always is hash_olen).
>
>
> Then there's things that are "nonces":
>
> - Exporter master secret
> - Resumption master secret
> - hello_finished
> - Some outputs of TLS exporter (depending on application).
>
> So I would be more concerned about some future extension changing the
> way things are computed, breaking CR-preserving, or someone adding a
> weak PRF hash. ​
>
>
​Agreed.
​
​


>
> (Of course, if SHA-2 breaks, we have really messy practical problem
> too...)
>
>
> > > 2. I wouldn't object to changing names here, of course.
> > >
> >
> > ​I think that's a must. "Finished" says absolutely nothing about the
> > functionality of this extension (it may actually mislead to think of it
> as
> > a MAC of some sorts).
> > Call it something that can be understood as  "PSK Creation Binder" and
> make
> > sure to specify (and explain in English) that all the values in the key
> > derivation chain to lead to this value are collision resistant mappings
> of
> > the original handshake context (including the server's certificate).
>
> It is a bit more problematic than that:
>
> The hello_finished / "PSK Creation Binder" derives from the PSK key.
>
> Deriving separate value in context of dynamic PSK provisioning does not
> work properly as "static" PSKs lack this value, and if one then tries to
> use such key with combined authentication, you got an attack[1].
>
>
> [1] Apparently combined authentication is to be in separate spec[2], but
> the main spec needs to be safe with it.
>
> [2] There apparently the server signature_algorithms to "support" that,
> except I can't figure out _any_ use for that except a footgun[3].
>
> [3] If using PSK, it has ill-defined semantics. If not, it pretty much
> only useful for attacking the client.
>

​I could not follow this argument.

Hugo
​


>
> ​
>
>
> -Ilari
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Finished stuffing

[Salz, Rich]

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

Re: [TLS] Finished stuffing

[Ilari Liusvaara]

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, resumption context.
> >> "Hello_Finished", in turn, means nothing.
> >> Also, RC may better match the notion of "binder" hence more naturally
> >> requiring collision resistance, while all Finished uses in TLS (1.3 and
> >> before) have a MAC functionality (for which, say, 128 bits are good enough)
> >> and it would be better not to abuse them for other uses.
> >>
> >
> > Two points about this:
> >
> > 1. The Finished in TLS 1.3 is always Hash.length, and our minimum hash is
> > SHA-256, so I believe we have enough strength here. We could of course
> > require a minimum size.
> >
> 
> ​If you keep this, you definitely need to have a minimum size specification
> in boldface.

Well, the PRF hash is already assumed to be CR, and if HKDF is used with
certain restrictions, it preserves CR:

- The hash has output length at most input length (true for all SHA-2 variants)
- HKDF-extract salt length is constant (in current draft, always hash_olen)
- HKDF-expand PRK length is constant (in current draft, always hash_olen)
- The HKDF-expand output output length is at least hash output length
  (in current draft, hash_olen except in key expansions).

Furthermore Finished construction uses HMAC. There for CR-preserving,
one needs key to be of constant length (it always is hash_olen).


Then there's things that are "nonces":

- Exporter master secret
- Resumption master secret
- hello_finished
- Some outputs of TLS exporter (depending on application).

So I would be more concerned about some future extension changing the
way things are computed, breaking CR-preserving, or someone adding a
weak PRF hash. ​


(Of course, if SHA-2 breaks, we have really messy practical problem
too...)

 
> > 2. I wouldn't object to changing names here, of course.
> >
> 
> ​I think that's a must. "Finished" says absolutely nothing about the
> functionality of this extension (it may actually mislead to think of it as
> a MAC of some sorts).
> Call it something that can be understood as  "PSK Creation Binder" and make
> sure to specify (and explain in English) that all the values in the key
> derivation chain to lead to this value are collision resistant mappings of
> the original handshake context (including the server's certificate).

It is a bit more problematic than that:

The hello_finished / "PSK Creation Binder" derives from the PSK key.

Deriving separate value in context of dynamic PSK provisioning does not
work properly as "static" PSKs lack this value, and if one then tries to
use such key with combined authentication, you got an attack[1].


[1] Apparently combined authentication is to be in separate spec[2], but
the main spec needs to be safe with it.

[2] There apparently the server signature_algorithms to "support" that,
except I can't figure out _any_ use for that except a footgun[3].

[3] If using PSK, it has ill-defined semantics. If not, it pretty much
only useful for attacking the client.



-Ilari

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

Re: [TLS] Finished stuffing

[Hugo Krawczyk]

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?
>>
>
> Yes.
>
>
>
>> 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
>> original context that generated a resumption PSK, in particular a binding
>> with the server's identity (certificate). This is not achieved by the
>> hello_finished extension, is it?
>>
>
> It is supposed to do so. The reasoning is:
>
> - RMS is unchanged and therefore derived from the server certificate
> - The HelloFinished computation is HKDF(F(RMS), ) and
> therefore also is derived from the server certificate.
>
> Is that insufficient.
>

​Maybe it is, but in a very convoluted way.  There is no crypto-logic
reason in the world to think of RMS as a collision resistant binding value
​. These non-explicit requirements/assumptions are very dangerous. A recipe
for future trouble.


>
> I also have a problem with names. "Resumption context" is very explicit
>> about providing, well, resumption context.
>> "Hello_Finished", in turn, means nothing.
>> Also, RC may better match the notion of "binder" hence more naturally
>> requiring collision resistance, while all Finished uses in TLS (1.3 and
>> before) have a MAC functionality (for which, say, 128 bits are good enough)
>> and it would be better not to abuse them for other uses.
>>
>
> Two points about this:
>
> 1. The Finished in TLS 1.3 is always Hash.length, and our minimum hash is
> SHA-256, so I believe we have enough strength here. We could of course
> require a minimum size.
>

​If you keep this, you definitely need to have a minimum size specification
in boldface.
​


> 2. I wouldn't object to changing names here, of course.
>

​I think that's a must. "Finished" says absolutely nothing about the
functionality of this extension (it may actually mislead to think of it as
a MAC of some sorts).
Call it something that can be understood as  "PSK Creation Binder" and make
sure to specify (and explain in English) that all the values in the key
derivation chain to lead to this value are collision resistant mappings of
the original handshake context (including the server's certificate).

BTW, what would this "original handshake context" be in a setting where
everything is derived from a PSK without server certificates?

Hugo

PS: A mostly unrelated comment:  Finished in 0-RTT was potentially useful
to enable client authentication of 0-RTT traffic but since the latter is
not in (current) scope I guess this should not be a consideration to keep
that Finished message (which can be added when deciding to do such client
authentication).

​


>
> Best,
> -Ekr
>
>
>> Anyways, maybe this is just the result of my misunderstanding of the
>> proposal.
>>
>> Hugo
>>
>>
>> On Wed, Sep 7, 2016 at 11:26 AM, Eric Rescorla  wrote:
>>
>>>
>>>
>>> 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 for the stuffed finished, an argument against it is that it
>> violates the incremental nature of the session hash. If the hash stops
>> before the placeholder, it can be resumed with the computed finished;
>> otherwise, it must be rolled back.
>>
>
> This isn't a big deal for me (or I think any other implementor) either
> way, because of the actual way we compute the hash.
>

 To expand on that, because the final PRF hash is not known at the time
 we send ClientHello, most implementations I've seen just buffer the full
 transcript before this point.

 But one could also keep a rolling hash of all the supported PRFs
 (there's all of two of them if you lose TLS 1.1 and below), so I think
 that's a good argument for using the prefix rather than zeros. For
 implementations keeping a buffer, I don't think it matters, so let's keep
 both strategies happy.

>>>
>>> This is certainly fine with me.
>>>
>>> -Ekr
>>>
>>>

 David



> -Ekr
>
>
>>
>> Best,
>>
>> Antoine
>>
>>
>> Le 2016-09-07 05:49, Joseph Salowey a écrit :
>>
>>> 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
>>>
>>> On Tue, Sep 6, 2016 at 11:57 AM, David Benjamin
>>>  wrote:

Re: [TLS] Finished stuffing

[Eric Rescorla]

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?
>
One important property of RC is that it serves as a binding with the
> original context that generated a resumption PSK, in particular a binding
> with the server's identity (certificate). This is not achieved by the
> hello_finished extension, is it?
>

It is supposed to do so. The reasoning is:

- RMS is unchanged and therefore derived from the server certificate
- The HelloFinished computation is HKDF(F(RMS), ) and
therefore also is derived from the server certificate.

Is that insufficient.


I also have a problem with names. "Resumption context" is very explicit
> about providing, well, resumption context.
> "Hello_Finished", in turn, means nothing.
> Also, RC may better match the notion of "binder" hence more naturally
> requiring collision resistance, while all Finished uses in TLS (1.3 and
> before) have a MAC functionality (for which, say, 128 bits are good enough)
> and it would be better not to abuse them for other uses.
>

Two points about this:

1. The Finished in TLS 1.3 is always Hash.length, and our minimum hash is
SHA-256, so I believe we have enough strength here. We could of course
require a minimum size.
2. I wouldn't object to changing names here, of course.

Best,
-Ekr


> Anyways, maybe this is just the result of my misunderstanding of the
> proposal.
>
> Hugo
>
>
> On Wed, Sep 7, 2016 at 11:26 AM, Eric Rescorla  wrote:
>
>>
>>
>> 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 for the stuffed finished, an argument against it is that it
> violates the incremental nature of the session hash. If the hash stops
> before the placeholder, it can be resumed with the computed finished;
> otherwise, it must be rolled back.
>

 This isn't a big deal for me (or I think any other implementor) either
 way, because of the actual way we compute the hash.

>>>
>>> To expand on that, because the final PRF hash is not known at the time
>>> we send ClientHello, most implementations I've seen just buffer the full
>>> transcript before this point.
>>>
>>> But one could also keep a rolling hash of all the supported PRFs
>>> (there's all of two of them if you lose TLS 1.1 and below), so I think
>>> that's a good argument for using the prefix rather than zeros. For
>>> implementations keeping a buffer, I don't think it matters, so let's keep
>>> both strategies happy.
>>>
>>
>> This is certainly fine with me.
>>
>> -Ekr
>>
>>
>>>
>>> David
>>>
>>>
>>>
 -Ekr


>
> Best,
>
> Antoine
>
>
> Le 2016-09-07 05:49, Joseph Salowey a écrit :
>
>> 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
>>
>> 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 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 traffic key calculation since we'll never derive more than one
>>> epoch off of the same traffic secret. Combine that with the
>>> two-ladder KeyUpdate and we no longer need any concatenation or
>>> other label-munging at all. Simply use labels "key" and "iv" and the
>>> record-layer just exposes a single UseTrafficSecret function which
>>> saves the traffic secret (for KeyUpdate), derives the traffic keys,
>>> and engages the new AEAD in one swoop without mucking about with
>>> phases, traffic directions, whether we are client or server, etc.
>>>
>>> David
>>>
>>> On Thu, Sep 1, 2016 at 6:19 PM Eric Rescorla  wrote:
>>>
>>> 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 perspective, this outweighs the messing around
>>> with 

Re: [TLS] Finished stuffing

[Hugo Krawczyk]

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
original context that generated a resumption PSK, in particular a binding
with the server's identity (certificate). This is not achieved by the
hello_finished extension, is it?

I also have a problem with names. "Resumption context" is very explicit
about providing, well, resumption context.
"Hello_Finished", in turn, means nothing.
Also, RC may better match the notion of "binder" hence more naturally
requiring collision resistance, while all Finished uses in TLS (1.3 and
before) have a MAC functionality (for which, say, 128 bits are good enough)
and it would be better not to abuse them for other uses.

Anyways, maybe this is just the result of my misunderstanding of the
proposal.

Hugo


On Wed, Sep 7, 2016 at 11:26 AM, Eric Rescorla  wrote:

>
>
> 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 for the stuffed finished, an argument against it is that it
 violates the incremental nature of the session hash. If the hash stops
 before the placeholder, it can be resumed with the computed finished;
 otherwise, it must be rolled back.

>>>
>>> This isn't a big deal for me (or I think any other implementor) either
>>> way, because of the actual way we compute the hash.
>>>
>>
>> To expand on that, because the final PRF hash is not known at the time we
>> send ClientHello, most implementations I've seen just buffer the full
>> transcript before this point.
>>
>> But one could also keep a rolling hash of all the supported PRFs (there's
>> all of two of them if you lose TLS 1.1 and below), so I think that's a good
>> argument for using the prefix rather than zeros. For implementations
>> keeping a buffer, I don't think it matters, so let's keep both strategies
>> happy.
>>
>
> This is certainly fine with me.
>
> -Ekr
>
>
>>
>> David
>>
>>
>>
>>> -Ekr
>>>
>>>

 Best,

 Antoine


 Le 2016-09-07 05:49, Joseph Salowey a écrit :

> 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
>
> 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 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 traffic key calculation since we'll never derive more than one
>> epoch off of the same traffic secret. Combine that with the
>> two-ladder KeyUpdate and we no longer need any concatenation or
>> other label-munging at all. Simply use labels "key" and "iv" and the
>> record-layer just exposes a single UseTrafficSecret function which
>> saves the traffic secret (for KeyUpdate), derives the traffic keys,
>> and engages the new AEAD in one swoop without mucking about with
>> phases, traffic directions, whether we are client or server, etc.
>>
>> David
>>
>> On Thu, Sep 1, 2016 at 6:19 PM Eric Rescorla  wrote:
>>
>> 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 perspective, this outweighs the messing around
>> with the ClientHello buffer.
>> -Ekr
>>
>> On Thu, Sep 1, 2016 at 3:04 PM, Eric Rescorla  wrote:
>>
>> Folks,
>>
>> I have just posted a WIP PR for what I'm calling "Finished Stuffing"
>>
>> https://github.com/tlswg/tls13-spec/pull/615 [1]
>>
>>
>> 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
>> of Finished and resumption_ctx. This PR makes the following changes:
>>
>> - Replace the 0-RTT Finished with an extension you send in the
>> ClientHello *whenever* you do PSK.
>> - Get rid of resumption 

Re: [TLS] Finished stuffing

[Eric Rescorla]

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
>>> for the stuffed finished, an argument against it is that it violates the
>>> incremental nature of the session hash. If the hash stops before the
>>> placeholder, it can be resumed with the computed finished; otherwise, it
>>> must be rolled back.
>>>
>>
>> This isn't a big deal for me (or I think any other implementor) either
>> way, because of the actual way we compute the hash.
>>
>
> To expand on that, because the final PRF hash is not known at the time we
> send ClientHello, most implementations I've seen just buffer the full
> transcript before this point.
>
> But one could also keep a rolling hash of all the supported PRFs (there's
> all of two of them if you lose TLS 1.1 and below), so I think that's a good
> argument for using the prefix rather than zeros. For implementations
> keeping a buffer, I don't think it matters, so let's keep both strategies
> happy.
>

This is certainly fine with me.

-Ekr


>
> David
>
>
>
>> -Ekr
>>
>>
>>>
>>> Best,
>>>
>>> Antoine
>>>
>>>
>>> Le 2016-09-07 05:49, Joseph Salowey a écrit :
>>>
 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

 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 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 traffic key calculation since we'll never derive more than one
> epoch off of the same traffic secret. Combine that with the
> two-ladder KeyUpdate and we no longer need any concatenation or
> other label-munging at all. Simply use labels "key" and "iv" and the
> record-layer just exposes a single UseTrafficSecret function which
> saves the traffic secret (for KeyUpdate), derives the traffic keys,
> and engages the new AEAD in one swoop without mucking about with
> phases, traffic directions, whether we are client or server, etc.
>
> David
>
> On Thu, Sep 1, 2016 at 6:19 PM Eric Rescorla  wrote:
>
> 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 perspective, this outweighs the messing around
> with the ClientHello buffer.
> -Ekr
>
> On Thu, Sep 1, 2016 at 3:04 PM, Eric Rescorla  wrote:
>
> Folks,
>
> I have just posted a WIP PR for what I'm calling "Finished Stuffing"
>
> https://github.com/tlswg/tls13-spec/pull/615 [1]
>
>
> 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
> of Finished and resumption_ctx. This PR makes the following changes:
>
> - Replace the 0-RTT Finished with an extension you send in the
> ClientHello *whenever* you do PSK.
> - Get rid of resumption context (because it is now replaced by
> the ClientHello.hello_finished.
>
> RATIONALE
> The reasoning for this change is:
>
> - With ordinary PSK you don't get any assurance that the other side
> knows the PSK.
>
> - With 0-RTT you get some (subject to the usual anti-replay
> guarantees) via the Finished message.
>
> - If we were to include the 0-RTT Finished message in the handshake
> transcript, then we wouldn't need the resumption context because
> the transcript would transitively include the PSK via the
> Finished.
>
> So the natural thing to do would be to always send 0-RTT Finished
> but unfortunately:
>
> 1. You can't just send the 0-RTT Finished whenever you do PSK
> because
> that causes potential compat problems with mixed 1.3/1.2 networks
> (the same ones we have with 0-RTT, but at least that's opt-in).
>
> 2. You also can't send the 0-RTT Finished with PSK because you can
> currently offer multiple PSK identities.
>
> The on-list discussion has suggested we could relax condition #2 and
> only have one identity. And we can fix condition #1 

Re: [TLS] Finished stuffing

[David Benjamin]

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 the
> incremental nature of the session hash. If the hash stops before the
> placeholder, it can be resumed with the computed finished; otherwise, it
> must be rolled back.
>
>
> This isn't a big deal for me (or I think any other implementor) either
> way, because of the actual way we compute the hash.
>

To expand on that, because the final PRF hash is not known at the time we
send ClientHello, most implementations I've seen just buffer the full
transcript before this point.

But one could also keep a rolling hash of all the supported PRFs (there's
all of two of them if you lose TLS 1.1 and below), so I think that's a good
argument for using the prefix rather than zeros. For implementations
keeping a buffer, I don't think it matters, so let's keep both strategies
happy.

David



> -Ekr
>
>
>
> Best,
>
> Antoine
>
>
> Le 2016-09-07 05:49, Joseph Salowey a écrit :
>
> 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
>
> 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 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 traffic key calculation since we'll never derive more than one
> epoch off of the same traffic secret. Combine that with the
> two-ladder KeyUpdate and we no longer need any concatenation or
> other label-munging at all. Simply use labels "key" and "iv" and the
> record-layer just exposes a single UseTrafficSecret function which
> saves the traffic secret (for KeyUpdate), derives the traffic keys,
> and engages the new AEAD in one swoop without mucking about with
> phases, traffic directions, whether we are client or server, etc.
>
> David
>
> On Thu, Sep 1, 2016 at 6:19 PM Eric Rescorla  wrote:
>
> 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 perspective, this outweighs the messing around
> with the ClientHello buffer.
> -Ekr
>
> On Thu, Sep 1, 2016 at 3:04 PM, Eric Rescorla  wrote:
>
> Folks,
>
> I have just posted a WIP PR for what I'm calling "Finished Stuffing"
>
> https://github.com/tlswg/tls13-spec/pull/615 [1]
>
>
> 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
> of Finished and resumption_ctx. This PR makes the following changes:
>
> - Replace the 0-RTT Finished with an extension you send in the
> ClientHello *whenever* you do PSK.
> - Get rid of resumption context (because it is now replaced by
> the ClientHello.hello_finished.
>
> RATIONALE
> The reasoning for this change is:
>
> - With ordinary PSK you don't get any assurance that the other side
> knows the PSK.
>
> - With 0-RTT you get some (subject to the usual anti-replay
> guarantees) via the Finished message.
>
> - If we were to include the 0-RTT Finished message in the handshake
> transcript, then we wouldn't need the resumption context because
> the transcript would transitively include the PSK via the
> Finished.
>
> So the natural thing to do would be to always send 0-RTT Finished
> but unfortunately:
>
> 1. You can't just send the 0-RTT Finished whenever you do PSK
> because
> that causes potential compat problems with mixed 1.3/1.2 networks
> (the same ones we have with 0-RTT, but at least that's opt-in).
>
> 2. You also can't send the 0-RTT Finished with PSK because you can
> currently offer multiple PSK identities.
>
> The on-list discussion has suggested we could relax condition #2 and
> only have one identity. And we can fix condition #1 by stuffing the
> Finished in an extension (with some hacks to make this easier). This
> PR enacts that.
>
> FAQS
> - What gets included in the handshake transcript?
> The whole ClientHello including the computed hello_finished
> extension.
>
> - Isn't this a hassle to implement?
> It turns out not to be. The basic reason is that at the point
> where
> the client sends the ClientHello and the server processes, it
> doesn't
> yet know which Hash will be chosen for HKDF and so NSS (and I
> believe
> other stacks) buffers the ClientHello in 

Re: [TLS] Finished stuffing

[Eric Rescorla]

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 affects the security proof of
> PSK even in the resumption case.
>

Yes.


Regarding the removal of multiple PSK identities offered by the client, it
> may weaken the PSK identity negotiation if the client has no choice but to
> try again with a different PSK (thus leaving the choice of the PSK to the
> adversary). This is somewhat comparable to the SupportedGroups/KeyShares
> situation; in that sense, if there is evidence that some clients will
> support multiple PSKs (e.g. for ticket updating, as mentioned recently on
> the list) it may be better to either send multiple stuffed finished, or to
> offer alternative PSK identities without stuffed finished and let the
> server ask for a hello retry.


Here are some initial thoughts on this:
First, it's not clear to me what the scenario is actually for multiple PSKs
for resumption. As
David Benjamin points out, this is handled more easily by just having the
server have overlapping
ticket keys. This is doubly true because you can't offer multiple 0-RTT
flights under different
keys, so really the only thing the client saves by offering multiple keys
is some reduced
cryptographic cost, which is a pretty modest advantage.

The primary reason I am aware of for allowing multiple PSKs is that
resumption of PSK-established
connections will be problematic (in that you would have to go through HRR).
That's unfortunate,
but TBH I'm not sure how important a scenario this is. Perhaps this is
something Hannes could weigh in
on. As noted, we can support the multi-PSK scenario with a bit more
complexity, but I'd rather not
unless we absolutely have to.

As far as security goes, it seems like the scenario here is that the client
has n keys that might be usable
with the server, but it doesn't know which if any of them is available. In
the current draft it offers
K_0 ... K_n in the ClientHello and the ServerHello selects one (WLOG,
assume that the server
would prefer K_0) and because the selected key is used to generate the
Finished, then any changes
to the handshake to cause the server to prefer K_i (i != 0) will also cause
a Finished failure unless
the attacker can somehow forge a Finished with K_i

In the PR, the client only offers K_j (which is its most preferred, but
perhaps not the server's) and the server
then would have to either accept it or reject it with HRR. Realistically,
the client then falls back to its next
most preferred or perhaps to one hinted by the server if that works. At the
end of the day, we then get
K_k (k!=j), with the entire transcript MACed with K_k. So, again, I would
argue that the attacker can't
influence the selection without being able to forge a Finished with K_k.



> Regarding whether the placeholder zeros should be part of the transcript
> for the stuffed finished, an argument against it is that it violates the
> incremental nature of the session hash. If the hash stops before the
> placeholder, it can be resumed with the computed finished; otherwise, it
> must be rolled back.
>

This isn't a big deal for me (or I think any other implementor) either way,
because of the actual way we compute the hash.

-Ekr


>
> Best,
>
> Antoine
>
>
> Le 2016-09-07 05:49, Joseph Salowey a écrit :
>
>> 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
>>
>> 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 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 traffic key calculation since we'll never derive more than one
>>> epoch off of the same traffic secret. Combine that with the
>>> two-ladder KeyUpdate and we no longer need any concatenation or
>>> other label-munging at all. Simply use labels "key" and "iv" and the
>>> record-layer just exposes a single UseTrafficSecret function which
>>> saves the traffic secret (for KeyUpdate), derives the traffic keys,
>>> and engages the new AEAD in one swoop without mucking about with
>>> phases, traffic directions, whether we are client or server, etc.
>>>
>>> David
>>>
>>> On Thu, Sep 1, 2016 at 6:19 PM Eric Rescorla  wrote:
>>>
>>> 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 

Re: [TLS] Finished stuffing

[Antoine Delignat-Lavaud]

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 identities offered by the client, 
it may weaken the PSK identity negotiation if the client has no choice 
but to try again with a different PSK (thus leaving the choice of the 
PSK to the adversary). This is somewhat comparable to the 
SupportedGroups/KeyShares situation; in that sense, if there is evidence 
that some clients will support multiple PSKs (e.g. for ticket updating, 
as mentioned recently on the list) it may be better to either send 
multiple stuffed finished, or to offer alternative PSK identities 
without stuffed finished and let the server ask for a hello retry.


Regarding whether the placeholder zeros should be part of the transcript 
for the stuffed finished, an argument against it is that it violates the 
incremental nature of the session hash. If the hash stops before the 
placeholder, it can be resumed with the computed finished; otherwise, it 
must be rolled back.



Best,

Antoine

Le 2016-09-07 05:49, Joseph Salowey a écrit :

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

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 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 traffic key calculation since we'll never derive more than one
epoch off of the same traffic secret. Combine that with the
two-ladder KeyUpdate and we no longer need any concatenation or
other label-munging at all. Simply use labels "key" and "iv" and the
record-layer just exposes a single UseTrafficSecret function which
saves the traffic secret (for KeyUpdate), derives the traffic keys,
and engages the new AEAD in one swoop without mucking about with
phases, traffic directions, whether we are client or server, etc.

David

On Thu, Sep 1, 2016 at 6:19 PM Eric Rescorla  wrote:

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 perspective, this outweighs the messing around
with the ClientHello buffer.
-Ekr

On Thu, Sep 1, 2016 at 3:04 PM, Eric Rescorla  wrote:

Folks,

I have just posted a WIP PR for what I'm calling "Finished Stuffing"

https://github.com/tlswg/tls13-spec/pull/615 [1]

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
of Finished and resumption_ctx. This PR makes the following changes:

- Replace the 0-RTT Finished with an extension you send in the
ClientHello *whenever* you do PSK.
- Get rid of resumption context (because it is now replaced by
the ClientHello.hello_finished.

RATIONALE
The reasoning for this change is:

- With ordinary PSK you don't get any assurance that the other side
knows the PSK.

- With 0-RTT you get some (subject to the usual anti-replay
guarantees) via the Finished message.

- If we were to include the 0-RTT Finished message in the handshake
transcript, then we wouldn't need the resumption context because
the transcript would transitively include the PSK via the
Finished.

So the natural thing to do would be to always send 0-RTT Finished
but unfortunately:

1. You can't just send the 0-RTT Finished whenever you do PSK
because
that causes potential compat problems with mixed 1.3/1.2 networks
(the same ones we have with 0-RTT, but at least that's opt-in).

2. You also can't send the 0-RTT Finished with PSK because you can
currently offer multiple PSK identities.

The on-list discussion has suggested we could relax condition #2 and
only have one identity. And we can fix condition #1 by stuffing the
Finished in an extension (with some hacks to make this easier). This
PR enacts that.

FAQS
- What gets included in the handshake transcript?
The whole ClientHello including the computed hello_finished
extension.

- Isn't this a hassle to implement?
It turns out not to be. The basic reason is that at the point
where
the client sends the ClientHello and the server processes, it
doesn't
yet know which Hash will be chosen for HKDF and so NSS (and I
believe
other stacks) buffers the ClientHello in plaintext, so hashing
only
part of it is easy. I've done it in NSS and this part is quite
easy.

POTENTIAL 

Re: [TLS] Finished stuffing

[Joseph Salowey]

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

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 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
> traffic key calculation since we'll never derive more than one epoch off of
> the same traffic secret. Combine that with the two-ladder KeyUpdate and we
> no longer need any concatenation or other label-munging at all. Simply use
> labels "key" and "iv" and the record-layer just exposes a single
> UseTrafficSecret function which saves the traffic secret (for KeyUpdate),
> derives the traffic keys, and engages the new AEAD in one swoop without
> mucking about with phases, traffic directions, whether we are client or
> server, etc.
>
> David
>
> On Thu, Sep 1, 2016 at 6:19 PM Eric Rescorla  wrote:
>
>> 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 perspective, this outweighs the messing around with
>> the ClientHello buffer.
>> -Ekr
>>
>>
>> On Thu, Sep 1, 2016 at 3:04 PM, Eric Rescorla  wrote:
>>
>>> 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
>>> of Finished and resumption_ctx. This PR makes the following changes:
>>>
>>> - Replace the 0-RTT Finished with an extension you send in the
>>>   ClientHello *whenever* you do PSK.
>>> - Get rid of resumption context (because it is now replaced by
>>>   the ClientHello.hello_finished.
>>>
>>>
>>> RATIONALE
>>> The reasoning for this change is:
>>>
>>> - With ordinary PSK you don't get any assurance that the other side
>>>   knows the PSK.
>>>
>>> - With 0-RTT you get some (subject to the usual anti-replay
>>>   guarantees) via the Finished message.
>>>
>>> - If we were to include the 0-RTT Finished message in the handshake
>>>   transcript, then we wouldn't need the resumption context because
>>>   the transcript would transitively include the PSK via the Finished.
>>>
>>> So the natural thing to do would be to always send 0-RTT Finished
>>> but unfortunately:
>>>
>>> 1. You can't just send the 0-RTT Finished whenever you do PSK because
>>>that causes potential compat problems with mixed 1.3/1.2 networks
>>>(the same ones we have with 0-RTT, but at least that's opt-in).
>>>
>>> 2. You also can't send the 0-RTT Finished with PSK because you can
>>>currently offer multiple PSK identities.
>>>
>>> The on-list discussion has suggested we could relax condition #2 and
>>> only have one identity. And we can fix condition #1 by stuffing the
>>> Finished in an extension (with some hacks to make this easier). This
>>> PR enacts that.
>>>
>>>
>>> FAQS
>>> - What gets included in the handshake transcript?
>>>   The whole ClientHello including the computed hello_finished extension.
>>>
>>> - Isn't this a hassle to implement?
>>>   It turns out not to be. The basic reason is that at the point where
>>>   the client sends the ClientHello and the server processes, it doesn't
>>>   yet know which Hash will be chosen for HKDF and so NSS (and I believe
>>>   other stacks) buffers the ClientHello in plaintext, so hashing only
>>>   part of it is easy. I've done it in NSS and this part is quite easy.
>>>
>>>
>>> POTENTIAL VARIATIONS/TODOs
>>> There are a number of possible variations we might want to look at:
>>>
>>> 1. Moving obfuscated_ticket_age to its own extension (out of
>>>early_data_indication). This provides additional anti-replay
>>>for the CH at the 0.5RTT sending point. I believe we should
>>>make this change.
>>>
>>> 2. Tweaking the data to be hashed to just hash the ClientHello
>>>prefix without the 0-filled verify_data. This is not significantly
>>>harder or easier to implement and basically depends on whether
>>>you prefer the invariant of "always hash complete messages" or
>>>"always hash valid pieces of transcript". See above for notes
>>>on buffering.
>>>
>>> 3. Allow multiple PSKs. Technically you could make this design
>>>work with >1 PSK but stuffing multiple verify_data values in
>>>the ClientHello. E.g,,
>>>
>>>   opaque FinishedValue<0..255>;
>>>
>>>   struct {
>>>  

Re: [TLS] Finished stuffing

[David Benjamin]

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
traffic key calculation since we'll never derive more than one epoch off of
the same traffic secret. Combine that with the two-ladder KeyUpdate and we
no longer need any concatenation or other label-munging at all. Simply use
labels "key" and "iv" and the record-layer just exposes a single
UseTrafficSecret function which saves the traffic secret (for KeyUpdate),
derives the traffic keys, and engages the new AEAD in one swoop without
mucking about with phases, traffic directions, whether we are client or
server, etc.

David

On Thu, Sep 1, 2016 at 6:19 PM Eric Rescorla  wrote:

> 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 perspective, this outweighs the messing around with
> the ClientHello buffer.
> -Ekr
>
>
> On Thu, Sep 1, 2016 at 3:04 PM, Eric Rescorla  wrote:
>
>> 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
>> of Finished and resumption_ctx. This PR makes the following changes:
>>
>> - Replace the 0-RTT Finished with an extension you send in the
>>   ClientHello *whenever* you do PSK.
>> - Get rid of resumption context (because it is now replaced by
>>   the ClientHello.hello_finished.
>>
>>
>> RATIONALE
>> The reasoning for this change is:
>>
>> - With ordinary PSK you don't get any assurance that the other side
>>   knows the PSK.
>>
>> - With 0-RTT you get some (subject to the usual anti-replay
>>   guarantees) via the Finished message.
>>
>> - If we were to include the 0-RTT Finished message in the handshake
>>   transcript, then we wouldn't need the resumption context because
>>   the transcript would transitively include the PSK via the Finished.
>>
>> So the natural thing to do would be to always send 0-RTT Finished
>> but unfortunately:
>>
>> 1. You can't just send the 0-RTT Finished whenever you do PSK because
>>that causes potential compat problems with mixed 1.3/1.2 networks
>>(the same ones we have with 0-RTT, but at least that's opt-in).
>>
>> 2. You also can't send the 0-RTT Finished with PSK because you can
>>currently offer multiple PSK identities.
>>
>> The on-list discussion has suggested we could relax condition #2 and
>> only have one identity. And we can fix condition #1 by stuffing the
>> Finished in an extension (with some hacks to make this easier). This
>> PR enacts that.
>>
>>
>> FAQS
>> - What gets included in the handshake transcript?
>>   The whole ClientHello including the computed hello_finished extension.
>>
>> - Isn't this a hassle to implement?
>>   It turns out not to be. The basic reason is that at the point where
>>   the client sends the ClientHello and the server processes, it doesn't
>>   yet know which Hash will be chosen for HKDF and so NSS (and I believe
>>   other stacks) buffers the ClientHello in plaintext, so hashing only
>>   part of it is easy. I've done it in NSS and this part is quite easy.
>>
>>
>> POTENTIAL VARIATIONS/TODOs
>> There are a number of possible variations we might want to look at:
>>
>> 1. Moving obfuscated_ticket_age to its own extension (out of
>>early_data_indication). This provides additional anti-replay
>>for the CH at the 0.5RTT sending point. I believe we should
>>make this change.
>>
>> 2. Tweaking the data to be hashed to just hash the ClientHello
>>prefix without the 0-filled verify_data. This is not significantly
>>harder or easier to implement and basically depends on whether
>>you prefer the invariant of "always hash complete messages" or
>>"always hash valid pieces of transcript". See above for notes
>>on buffering.
>>
>> 3. Allow multiple PSKs. Technically you could make this design
>>work with >1 PSK but stuffing multiple verify_data values in
>>the ClientHello. E.g,,
>>
>>   opaque FinishedValue<0..255>;
>>
>>   struct {
>>  FinishedValue finisheds<0..2^16-1>;
>>   } HelloFinished;
>>
>>Based on the list discussion, it seems like nobody wants >1 PSK,
>>so I think one is simpler; I just wanted to note that these
>>changes weren't totally coupled.
>>
>> 4. External context values. Several people have pointed out that it
>>might be convenient to have an external context value 

Re: [TLS] Finished stuffing

[Eric Rescorla]

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 perspective, this outweighs the messing around with
the ClientHello buffer.
-Ekr


On Thu, Sep 1, 2016 at 3:04 PM, Eric Rescorla  wrote:

> 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
> of Finished and resumption_ctx. This PR makes the following changes:
>
> - Replace the 0-RTT Finished with an extension you send in the
>   ClientHello *whenever* you do PSK.
> - Get rid of resumption context (because it is now replaced by
>   the ClientHello.hello_finished.
>
>
> RATIONALE
> The reasoning for this change is:
>
> - With ordinary PSK you don't get any assurance that the other side
>   knows the PSK.
>
> - With 0-RTT you get some (subject to the usual anti-replay
>   guarantees) via the Finished message.
>
> - If we were to include the 0-RTT Finished message in the handshake
>   transcript, then we wouldn't need the resumption context because
>   the transcript would transitively include the PSK via the Finished.
>
> So the natural thing to do would be to always send 0-RTT Finished
> but unfortunately:
>
> 1. You can't just send the 0-RTT Finished whenever you do PSK because
>that causes potential compat problems with mixed 1.3/1.2 networks
>(the same ones we have with 0-RTT, but at least that's opt-in).
>
> 2. You also can't send the 0-RTT Finished with PSK because you can
>currently offer multiple PSK identities.
>
> The on-list discussion has suggested we could relax condition #2 and
> only have one identity. And we can fix condition #1 by stuffing the
> Finished in an extension (with some hacks to make this easier). This
> PR enacts that.
>
>
> FAQS
> - What gets included in the handshake transcript?
>   The whole ClientHello including the computed hello_finished extension.
>
> - Isn't this a hassle to implement?
>   It turns out not to be. The basic reason is that at the point where
>   the client sends the ClientHello and the server processes, it doesn't
>   yet know which Hash will be chosen for HKDF and so NSS (and I believe
>   other stacks) buffers the ClientHello in plaintext, so hashing only
>   part of it is easy. I've done it in NSS and this part is quite easy.
>
>
> POTENTIAL VARIATIONS/TODOs
> There are a number of possible variations we might want to look at:
>
> 1. Moving obfuscated_ticket_age to its own extension (out of
>early_data_indication). This provides additional anti-replay
>for the CH at the 0.5RTT sending point. I believe we should
>make this change.
>
> 2. Tweaking the data to be hashed to just hash the ClientHello
>prefix without the 0-filled verify_data. This is not significantly
>harder or easier to implement and basically depends on whether
>you prefer the invariant of "always hash complete messages" or
>"always hash valid pieces of transcript". See above for notes
>on buffering.
>
> 3. Allow multiple PSKs. Technically you could make this design
>work with >1 PSK but stuffing multiple verify_data values in
>the ClientHello. E.g,,
>
>   opaque FinishedValue<0..255>;
>
>   struct {
>  FinishedValue finisheds<0..2^16-1>;
>   } HelloFinished;
>
>Based on the list discussion, it seems like nobody wants >1 PSK,
>so I think one is simpler; I just wanted to note that these
>changes weren't totally coupled.
>
> 4. External context values. Several people have pointed out that it
>might be convenient to have an external context value hashed
>into the transcript. One way to do this would be to include
>it under the Finished. That's not difficult if people want to,
>with the default being empty.
>
> 5. Hugo brought up on the list that we need to make very clear that
>the "hello_finished" is being used to bind the handshakes and
>that it depends on collision resistance. I have not forgotten this
>and text on that point would be appreciated.
>
> Comments welcome.
> -Ekr
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Finished stuffing

[Eric Rescorla]

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
of Finished and resumption_ctx. This PR makes the following changes:

- Replace the 0-RTT Finished with an extension you send in the
  ClientHello *whenever* you do PSK.
- Get rid of resumption context (because it is now replaced by
  the ClientHello.hello_finished.


RATIONALE
The reasoning for this change is:

- With ordinary PSK you don't get any assurance that the other side
  knows the PSK.

- With 0-RTT you get some (subject to the usual anti-replay
  guarantees) via the Finished message.

- If we were to include the 0-RTT Finished message in the handshake
  transcript, then we wouldn't need the resumption context because
  the transcript would transitively include the PSK via the Finished.

So the natural thing to do would be to always send 0-RTT Finished
but unfortunately:

1. You can't just send the 0-RTT Finished whenever you do PSK because
   that causes potential compat problems with mixed 1.3/1.2 networks
   (the same ones we have with 0-RTT, but at least that's opt-in).

2. You also can't send the 0-RTT Finished with PSK because you can
   currently offer multiple PSK identities.

The on-list discussion has suggested we could relax condition #2 and
only have one identity. And we can fix condition #1 by stuffing the
Finished in an extension (with some hacks to make this easier). This
PR enacts that.


FAQS
- What gets included in the handshake transcript?
  The whole ClientHello including the computed hello_finished extension.

- Isn't this a hassle to implement?
  It turns out not to be. The basic reason is that at the point where
  the client sends the ClientHello and the server processes, it doesn't
  yet know which Hash will be chosen for HKDF and so NSS (and I believe
  other stacks) buffers the ClientHello in plaintext, so hashing only
  part of it is easy. I've done it in NSS and this part is quite easy.


POTENTIAL VARIATIONS/TODOs
There are a number of possible variations we might want to look at:

1. Moving obfuscated_ticket_age to its own extension (out of
   early_data_indication). This provides additional anti-replay
   for the CH at the 0.5RTT sending point. I believe we should
   make this change.

2. Tweaking the data to be hashed to just hash the ClientHello
   prefix without the 0-filled verify_data. This is not significantly
   harder or easier to implement and basically depends on whether
   you prefer the invariant of "always hash complete messages" or
   "always hash valid pieces of transcript". See above for notes
   on buffering.

3. Allow multiple PSKs. Technically you could make this design
   work with >1 PSK but stuffing multiple verify_data values in
   the ClientHello. E.g,,

  opaque FinishedValue<0..255>;

  struct {
 FinishedValue finisheds<0..2^16-1>;
  } HelloFinished;

   Based on the list discussion, it seems like nobody wants >1 PSK,
   so I think one is simpler; I just wanted to note that these
   changes weren't totally coupled.

4. External context values. Several people have pointed out that it
   might be convenient to have an external context value hashed
   into the transcript. One way to do this would be to include
   it under the Finished. That's not difficult if people want to,
   with the default being empty.

5. Hugo brought up on the list that we need to make very clear that
   the "hello_finished" is being used to bind the handshakes and
   that it depends on collision resistance. I have not forgotten this
   and text on that point would be appreciated.

Comments welcome.
-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls