Re: [TLS] Finished stuffing

[Eric Rescorla <[e-mail]>]

On Wed, Sep 7, 2016 at 6:54 AM, Antoine Delignat-Lavaud <
[e-mail]> 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&S
>>
>> On Tue, Sep 6, 2016 at 11:57 AM, David Benjamin
>> <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tls [2]
>>>
>>
>> _______________________________________________
>>  TLS mailing list
>>  [e-mail]
>>  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
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>