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

I think I might nonetheless spend my flight to Prague formalizing a
security proof, mostly as an exercise to improve my proficiency
working in the standard model. My intuition here is mostly that, even
if the adversary is given K1, it still can't distinguish E_{K2}(K1)
from E{K2}(R) for random R; there therefore shouldn't be anything
"special" about using E_{K2}(K1) as an input to E_{K1}(.). A colleague
has sketched out a plausible hybrid argument which sort of matches
this intuition. I'm going to take that argument and see if I can run
with it.

On Wed, Mar 20, 2019 at 8:46 PM Watson Ladd <watsonbladd@gmail.com> wrote:
>
> I've managed to convince myself Daniel is right and there is no problem.
>
> On Wed, Mar 20, 2019, 1:31 PM Aanchal Malhotra <aanchal4@bu.edu> wrote:
>>
>> 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
>>
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/cfrg
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg