Re: [Cfrg] [Ntp] Last minute annoying discovery about NTS

[Watson Ladd <[e-mail]>]

I've managed to convince myself Daniel is right and there is no problem.

On Wed, Mar 20, 2019, 1:31 PM Aanchal Malhotra <[e-mail]> wrote:

> This reference for KDM security might be useful.
> https://eprint..iacr.org/2010/513.pdf
> <https://eprint.iacr.org/2010/513.pdf>
>
> On Wed, Mar 20, 2019 at 1:29 PM Watson Ladd <watson=
> [e-mail]> wrote:
>
>> On Wed, Mar 20, 2019 at 1:18 PM Daniel Franke <[e-mail]>
>> wrote:
>> >
>> > Are you certain the standard security definitions don't suffice? If
>> > the S2C key were directly being encrypted under itself, then a
>> > circular-secure cipher would be needed. Ditto if you were to encrypt
>> > the S2C key under the master key and also encrypted the master key
>> > under the S2C key. We're producing the cookie by encrypting the S2C
>> > key under the master key, and then for transmission we're encrypting
>> > the resulting ciphertext under the S2C key. But at no point does the
>> > master key ever get encrypted under the S2C key; the master key never
>> > leaves the server even as ciphertext. So I don't think we actually
>> > have a loop here.
>>
>> Any sort of encryption of a function of the key is a call the experts
>> situation. So the question for the experts: if E_K(M) is an AEAD
>> scheme, and K1, K2 keys
>> is E_{K1}(E_{K2}(K1)) a sane thing to do, or is it a problem from a
>> proof perspective? What if I am allowed to change the inner or outer
>> schemes to any AEAD scheme?
>>
>> >
>> > On Wed, Mar 20, 2019 at 3:34 PM Watson Ladd
>> > <watson=[e-mail]> wrote:
>> > >
>> > > Dear all,
>> > >
>> > > I really apologize for sending this message so late in the process,
>> > > but there is a problem with NTS in draft-17.
>> > >
>> > > The cookie encrypts S2C and C2S under a key known to the server, but
>> > > then the response encrypts the cookie under S2C. This creates a
>> > > situation where we are encrypting plaintext that depends on the key,
>> > > which complicates the security analysis. (And by complicates I mean
>> > > there are contrived ciphers meeting the ordinary security notion that
>> > > would be completely insecure in such a protocol: one has to not use
>> > > generic analysis: it's a pain to deal with. see
>> > > https://eprint.iacr.org/2010/144.pdf)
>> > >
>> > > One solution would be for the cookie to contain the new keys which the
>> > > server picks at random (and of course the client strips them out
>> > > before sending the rest of the cookie to the server). Again, I
>> > > apologize for only just noticing this detail.
>> > >
>> > > Sincerely,
>> > > Watson Ladd
>> > >
>> > > _______________________________________________
>> > > ntp mailing list
>> > > [e-mail]
>> > > https://www.ietf.org/mailman/listinfo/ntp
>>
>> _______________________________________________
>> ntp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ntp
>>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>