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

This reference for KDM security might be useful.
https://eprint.iacr.org/2010/513.pdf

On Wed, Mar 20, 2019 at 1:29 PM Watson Ladd <watson=
40cloudflare.com@dmarc.ietf.org> wrote:

> On Wed, Mar 20, 2019 at 1:18 PM Daniel Franke <dfoxfranke@gmail.com>
> 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=40cloudflare.com@dmarc.ietf.org> 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
> > > ntp@ietf.org
> > > https://www.ietf.org/mailman/listinfo/ntp
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
>