Hi, It seems the presented mechanism can be used to mitigate the signing oracle issue. Unless someone opposes this I am encline to consider that the signing oracle issue is closed.
BR, Daniel On Wed, Oct 12, 2016 at 11:00 AM, Daniel Migault < daniel.miga...@ericsson.com> wrote: > Hi, > > > > If I understand correctly, to prevent a generic signing oracle, some > mechanisms or operations should be defined so the signed public key can be > believed to be part of legitimate ECDHE exchange instead of some random > data. This includes checking the public key belongs to the curve or proving > that the Edge Server owns the corresponding private key associate to that > curve. > > > > In order, for the Edge Server, to prove the ownership of the corresponding > private key, I propose the following mechanism. Please let me know if you > agree with that mechanism as well as if you believe the generic signing > oracle has been sufficiently addressed. > > > > Upon the request the server computes: > > a) r a randomly generated number the Edge Server can chose > > b) c a randomly generated number the Edge Server cannot chose. ** > > Let > > t = cb + r > > and > > bG the public key to be signed. > > > > The Edge Server sends to the Key Server: > > rG, tG, c, bG > > > > The Key Server checks: c(bG) + rG = tG > > > > ** Ideally, the number could be provided by the Key Server for each > request. However, we can probably find some reasonable alternatives where > the number is generated by the Edge Server while being reasonably out of > control from the Edge Server. For example we could use the resulting hash > of a combination of a shared secret between the Edge Server and the Key > Server, associated to a sequence number address. There are probably other > maybe better ways to do and feel free to propose alternatives. > > > > > > BR, > > Daniel > > *From:* Lurk [mailto:lurk-boun...@ietf.org] *On Behalf Of *Kyle Rose > *Sent:* Monday, July 18, 2016 11:23 AM > *To:* Eric Rescorla <e...@rtfm.com> > *Cc:* LURK BoF <lurk@ietf.org> > *Subject:* Re: [Lurk] Notes on preventing signing oracles > > > > It's possible we can't do much to prevent creating a generic signing > oracle for TLS 1.2, but for 1.3 we can send precursors to the key owner and > require it to reproduce the final input to the signature algorithm, > constraining the adversary to signatures of messages of the form > (0x20){32}("TLS 1.3, (server|client) CertificateVerify")(0x00)(.){64} for > SHA-256. > > We could potentially backtrack even further, sending inputs to each of the > hashes and requiring the key owner to do additional verification, at the > risk of exposing some data to the key owner that we might not want to. > > Is this worth the added complexity and duplicated effort (by both the > server and the key owner)? Regardless of best-practice, since it's at least > somewhat likely that a particular signing key will be used in more than > context, this might prevent some future class of cross-protocol attacks. > > Kyle > > > > On Mon, Jul 18, 2016 at 9:22 AM, Eric Rescorla <e...@rtfm.com> wrote: > > The current charter proposal says: > > > > A Standards Track document that defines the interface between an edge > > server and a content owner. Security is a key concern, specifically > > avoiding a "signing oracle" where possible. > > > > This text is a bit unclear, but I presume that the intent is to avoid > > allowing the Server to use the KeyOwner as a signing oracle. This > > message attempts to explore how hard this is. > > > > > > As I think is well known, TLS 1.2 servers inherently allow clients to > > obtain a signature with the server key on a message with a 32-byte > > prefix chosen by the client [0]. In a LURK context, if one adopts the > > naive design where the Server supplies the ServerKeyExchange to the > > KeyOwner, the Server can obtain a signature by the KeyOwner on a > > string which consists of: > > > > - 32 bytes of ClientRandom (which can be chosen by the Server) > > - 32 bytes of ServerRandom (which in the worst-case for the attacker > > is selected by the KeyOwner) > > - The serialization of the ServerKeyExchange message which ostensibly > > consists of [1]: > > - The server's ECDHE share > > - The server's FFDHE group + share > > > > It should be clear that if we just allow the Server to supply an > > unverified key/share that that's a very powerful signing oracle, but > > there are also limits to how much the KeyOwner can validate the share: > > > > - If it's ECDHE (NIST curves) then it can validate that the ostensible > > point is on the curve. This allows the Server to generate a pretty > > random x-coord value but then y-coord has to match (assuming we > > require uncompressed points). > > > > - If it's ECDHE (CFRG curves), then the Server can basically generate > > an arbitrary 32 or 48-byte string > > > > - If it's FFDHE, then the Server gets to control a huge amount of data > > if you allow custom groups, but one could require that Servers use > > the defined FFDHE groups, in which case, the Server just gets to > > specify Y as a random value. > > > > Maybe one could do a bit better than this with some more thought, but > > I suspect that ultimately really preventing a signing oracle requires > > preventing the Server from arbitrarily choosing the "public" part of > > the DH share, e.g., by requiring the Server prove it knows the private > > part) Absent this, I'm not sure how much security value this actually > > provides over no validation (the CFRG curve case seems especially > > bad). > > > > -Ekr > > > > > > [0] https://tlswg.github.io/tls13-spec/#rfc.section.4.3.2 > > [1] I'm ignoring the length bytes for the purposes of this discussion. > > > > > _______________________________________________ > Lurk mailing list > Lurk@ietf.org > https://www.ietf.org/mailman/listinfo/lurk > > > > _______________________________________________ > Lurk mailing list > Lurk@ietf.org > https://www.ietf.org/mailman/listinfo/lurk > >
_______________________________________________ Lurk mailing list Lurk@ietf.org https://www.ietf.org/mailman/listinfo/lurk
