On Wed, Jul 5, 2017 at 1:40 AM, Matt Caswell <fr...@baggins.org> wrote:
> On 4 July 2017 at 11:50, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > > On Tue, Jul 04, 2017 at 11:25:35AM +0100, Matt Caswell wrote: > >> On 4 July 2017 at 01:01, Eric Rescorla <e...@rtfm.com> wrote: > >> > - Modifying the key derivation for PSKs so that each session ticket > >> > is associated with a distinct PSK. > >> > >> Draft-21 says this about the ticket nonce: > >> > >> opaque ticket_nonce<1..255>; > >> ... > >> ticket_nonce A unique per-ticket value. > >> > >> > >> Within what context is "uniqueness" required? I am assuming that > >> uniqueness within the context of a single TLS connection is all that > >> is needed? > > > > Yes, It has to be unique within a connection. > > > >> The nonce can be anything between 1 and 255 bytes long. There is no > >> guidance on a suitable length, so I am assuming I can choose anything > >> I like as long as the uniqueness constraint is met. OpenSSL > >> (currently) only ever issues a single ticket per TLS connection so is > >> a single 0 byte sufficient? > > > > Yes, if you only have one ticket per connection, then any legal fixed > > value is acceptable. > > Thanks. Another slightly confusing thing about the way this is > currently specified: > > The spec says: > > The PSK associated with the ticket is computed as: > > HKDF-Expand-Label(resumption_master_secret, > "resumption", ticket_nonce, Hash.length) > > Where HKDF-Expand-Label is defined as: > > HKDF-Expand-Label(Secret, Label, HashValue, Length) = > HKDF-Expand(Secret, HkdfLabel, Length) > ... > Note that in some cases a zero- length HashValue (indicated by > "") is passed to HKDF-Expand-Label. > > Note that the third parameter here is explicitly expected to be either > a hash or "" (i.e. zero length). But in the ticket_nonce case this is > NOT a hash value. AFAICT this is the only time in the spec that > something other than a hash or "" is used for this parameter. I'm > assuming this is intentional and we are supposed to pass the nonce > through "as is" (i.e. there is no implicit requirement to hash it > first). Probably the definition of HKDF-Expand-Label needs to be > updated to allow for this usage. > Yes, that might not be a terrible idea. I'd also be open to replacing the hashes of 0 with an n-byte length 0 string. It's a tiny paper cut (and a wire format change), but would make things slightly simpler . -Ekr > Matt > > _______________________________________________ > 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
