Subject: [TLS] Finished stuffing

From: Eric Rescorla <[email-masked]>
Date: Thu, 1 Sep 2016 15:04:21 -0700

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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 1 Sep 2016 15:18:49 -0700

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

---

From: David Benjamin <[email-masked]>
Date: Tue, 06 Sep 2016 18:57:45 +0000

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 <[email-masked]> wrote:

> I should also mention that this makes the implementation a fair bit
> simpler because:
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Joseph Salowey <[email-masked]>
Date: Tue, 6 Sep 2016 21:49:13 -0700

Hi Folks,

The chairs want to make sure this gets some proper review.   Please respond
with comments by Friday so we can make some progress on this issue.

Thanks,

J&S

---

From: Antoine Delignat-Lavaud <[email-masked]>
Date: Wed, 07 Sep 2016 14:54:17 +0100

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&S
> 
> On Tue, Sep 6, 2016 at 11:57 AM, David Benjamin
> <[email-masked]> 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
>> 
>> 1. You can make all the decisions on the server side immediately
>> upon receiving the ClientHello
>> From an implementor's perspective, this outweighs the messing around
>> with the ClientHello buffer.
>> -Ekr
>> 
>> https://github.com/tlswg/tls13-spec/pull/615 [1]
>> 
>> https://www.ietf.org/mailman/listinfo/tls [2]
> 
>  https://www.ietf.org/mailman/listinfo/tls [2]
> 
> 
> 
> Links:
> ------
> [1] https://github.com/tlswg/tls13-spec/pull/615
> [2] https://www.ietf.org/mailman/listinfo/tls
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 7 Sep 2016 08:11:02 -0700

On Wed, Sep 7, 2016 at 6:54 AM, Antoine Delignat-Lavaud <
[email-masked]> 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.

> placeholder, it can be resumed with the computed finished; otherwise, it

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

---

From: David Benjamin <[email-masked]>
Date: Wed, 07 Sep 2016 15:25:19 +0000

On Wed, Sep 7, 2016 at 11:11 AM Eric Rescorla <[email-masked]> wrote:

> 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

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 7 Sep 2016 08:26:14 -0700

> keeping a buffer, I don't think it matters, so let's keep both strategies

This is certainly fine with me.

-Ekr

---

From: Hugo Krawczyk <[email-masked]>
Date: Wed, 7 Sep 2016 19:02:16 -0400

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 <[email-masked]> 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.
>>>>
>>>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 7 Sep 2016 16:18:56 -0700

On Wed, Sep 7, 2016 at 4:02 PM, Hugo Krawczyk <[email-masked]>
wrote:

> 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?
>
> 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), <ClientHello>) and
therefore also is derived from the server certificate.

Is that insufficient.

> 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

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

---

From: Hugo Krawczyk <[email-masked]>
Date: Wed, 7 Sep 2016 19:43:53 -0400

> therefore also is derived from the server certificate.

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

> SHA-256, so I believe we have enough strength here. We could of course

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

​

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 8 Sep 2016 12:29:01 +0300

> ​If you keep this, you definitely need to have a minimum size specification

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

> 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

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 8 Sep 2016 17:05:21 +0000

I’m fine with this.

I am strongly in favor of having one PSK identity. ☺

--
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Hugo Krawczyk <[email-masked]>
Date: Thu, 8 Sep 2016 21:59:22 -0400

> - The hash has output length at most input length (true for all SHA-2

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.

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

> way things are computed, breaking CR-preserving, or someone adding a
​Agreed.
​
​

> only useful for attacking the client.

​I could not follow this argument.

Hugo
​

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 9 Sep 2016 11:22:38 +0300

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

> functionality but it is not a native KDF functionality.

So I presume some more text for Security Considerations...
 
> 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.

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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 9 Sep 2016 18:39:56 +1000

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 9 Sep 2016 16:01:07 +0200

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 9 Sep 2016 14:50:59 -0500

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:
> On Tue, Sep 6, 2016 at 11:57 AM, David Benjamin <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     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 <[email-masked]
>     <mailto:[email-masked]>> 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
>         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 <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>             Folks,
>
>             <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls13-2Dspec_pull_615&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=IwfxQnHf5o1ACITZiQQEOKnbhWK40rJ7uWbCfhm0pSE&s=ukqGqua3EOfqImRb0EFPRRxMv7Hgom3t_5Ki4OvDG8M&e=>
>
>         [email-masked] <mailto:[email-masked]>
>         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=IwfxQnHf5o1ACITZiQQEOKnbhWK40rJ7uWbCfhm0pSE&s=wIZYtT4TzI4oljhi8_PX1pf95lodfWq4WmQBUXX5Q7g&e=>
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=IwfxQnHf5o1ACITZiQQEOKnbhWK40rJ7uWbCfhm0pSE&s=wIZYtT4TzI4oljhi8_PX1pf95lodfWq4WmQBUXX5Q7g&e=>
>
>
>
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 9 Sep 2016 23:19:03 +0300

> if we keep the resumption_context and do not overload the resumption_psk

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

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

-Ilari

---

From: Hugo Krawczyk <[email-masked]>
Date: Fri, 9 Sep 2016 19:33:21 -0400

> that have that property of being both key and binder.

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

Hugo

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 10 Sep 2016 10:35:03 +0300

> 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

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 13 Sep 2016 12:04:40 -0500

> "static" PSKs don't have resumption_context.

Agreed.

> 0-RTT (ALPN (or indication there is none) and associated cipher)...

Wasn't Hannes just asking about that? ;)

> 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

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 13 Sep 2016 22:15:10 +0300

> hello_finished, so I'm still puzzled.

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

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 17 Sep 2016 14:43:49 -0700

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

In this case, I believe that the finished is computed over
"ClientHello(groups=23,24,29;PSK=foo;shares=23:bar,29:baz,24:quux,..."

But that the handshake transcript is computed over all of:
"Client: ClientHello(groups=23,24,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=???)"

-Ekr

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 18 Sep 2016 12:54:22 +0300

> 24:quux,...,finished=???)"

Well, either way, I think there should be a note about how those
hashes behave with retries.

Also, has that extension been added as an exception to the rule that
extensions must remain the same across retry (since it can change)?
I don't see that being added to such list of exceptions.

-Ilari