Errors for bogus tickets. Fixes #1247

[ekr]

As noted in the original issue, we he have unknown_psk_identity, so I think this is unnecessary after all.

@emanjon @chris-wood ?

[tomato42]

Shouldn't we add a security section to that? It feels to me like it may be very easy to mess up the identity checks in a way that provides information to the attacker (Bleichenbacher style).

[ekr]

Do you have some specific text to propose?

On Mon, Oct 24, 2022 at 4:46 AM Hubert Kario @.***> wrote:

Shouldn't we add a security section to that? It feels to me like it may be very easy to mess up the identity checks in a way that provides information to the attacker (Bleichenbacher style).

— Reply to this email directly, view it on GitHub https://github.com/tlswg/tls13-spec/pull/1269#issuecomment-1288914406, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIPLIIGGFOVI66OHOOUGCLWEZZJTANCNFSM6AAAAAARLOWL54 . You are receiving this because you authored the thread.Message ID: @.***>

[tomato42]

It's very implementation dependent, how the ticket is constructed. A ticket that's RSA encrypted, AES encrypted, or just a database key will have completely different behaviours and possible attacks, so unfortunately at best I think we can provide only something vague and generic.

Rather bad, bad something like this:

Note that the decryption and processing of the ticket may provide a side channel about information contained in the ticket or internal state of the server.
Implements should analyse if the particular ticket construction doesn't leak sensitive information when processed from malformed messages or unexpected sources. Using authenticated encryption over all fields of the ticket is one of recommended mitigation strategies. 

[ekr]

Thanks. We have so far remained agnostic about ticket construction and I think we should do the same here. The introduction of this error would not change what the client learns, I don't think.

Note that I actually don't plan to land this PR anyway, as there is already a fine alert.

On Mon, Oct 24, 2022 at 7:27 AM Hubert Kario @.***> wrote:

It's very implementation dependent, how the ticket is constructed. A ticket that's RSA encrypted, AES encrypted, or just a database key will have completely different behaviours and possible attacks, so unfortunately at best I think we can provide only something vague and generic.

Rather bad, bad something like this:

Note that the decryption and processing of the ticket may provide a side channel about information contained in the ticket or internal state of the server. Implements should analyse if the particular ticket construction doesn't leak sensitive information when processed from malformed messages or unexpected sources. Using authenticated encryption over all fields of the ticket is one of recommended mitigation strategies.

— Reply to this email directly, view it on GitHub https://github.com/tlswg/tls13-spec/pull/1269#issuecomment-1289122773, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIPLIOM3ZTPYMSLBYWX6CLWE2MF7ANCNFSM6AAAAAARLOWL54 . You are receiving this because you authored the thread.Message ID: @.***>

[tomato42]

I wasn't thinking about the presence or even value of the alert being the side channel, I was thinking about timing side-channels.

[ekr]

This really seems out of scope then.

On Mon, Oct 24, 2022 at 11:31 AM Hubert Kario @.***> wrote:

I wasn't thinking about the presence or even value of the ticket being the side channel, I was thinking about timing side-channels.

— Reply to this email directly, view it on GitHub https://github.com/tlswg/tls13-spec/pull/1269#issuecomment-1289429564, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIPLIJQZ7KXSAVQPVFRVW3WE3IY7ANCNFSM6AAAAAARLOWL54 . You are receiving this because you authored the thread.Message ID: @.***>