On Tue, 2016-11-15 at 18:20 +0900, Martin Thomson wrote: > On 15 November 2016 at 18:11, Nikos Mavrogiannopoulos <n...@redhat.co > m> wrote: > > > > > > > > I'm not seeing quite enough information here to implement > > > this. How > > > does a server know which of the many HOTP keys it has are in use? > > > Surely you can't use the same HOTP key with every client. > > > > Not sure I understand the question, but I'd suggest to read the > > text on > > generating the hotp keys. > > > OK, I re-read it. It wasn't particularly clear from the overview. > But you generate the HOTP based on an exporter. That means that the > server has no control over the contents of the CID, direct or > otherwise. This means that you can guarantee privacy, but it forces > the server to do an exhaustive search of all of its active > connections > (that is, O(N)) when it gets a 5-tuple mismatch. > > There are probably designs that don't have this property. For > instance, the server could propose an identifier or set of > identifiers. That means that a bad server could willfully break the > privacy property, but it also means that it doesn't have the scaling > issues.
I think Thomas reply addresses that, or we must have misunderstood what you mean above. I think however that we are getting outside the scope of the initial discussion. Do you have a proposal which changes the TLSrecord header? If yes would you be interested in discussing ways to combine that, or ways to make the header extendable? regards, Nikos _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
