On Fri, Sep 09, 2016 at 07:33:21PM -0400, Hugo Krawczyk wrote:
> On Fri, Sep 9, 2016 at 4:22 AM, Ilari Liusvaara <ilariliusva...@welho.com>
> 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
