On Wed, Sep 23, 2015 at 08:50:16AM -0700, Eric Rescorla wrote: > On Wed, Sep 23, 2015 at 3:54 AM, Ilari Liusvaara < > ilari.liusva...@elisanet.fi> wrote: > > > investigate: using the same construct for server/client sigs. > > > > Huh? Don't both currently use the same construct, except for the > > context string? Are you proposing to remove the context string or > > what? > > > > The idea on the table was to use an exported value to match Token binding. > Input needed here.
One would then presumably also have to eject SC/SCV from ExMS computation so the same ExMS is available for SCV? Also, bit of an issue here is that OCSP stapling (which is pretty much regarded as the only sane way to actually use OCSP) is specified to use its own message, which goes between SC and SCV (RFC6066). So it would at least need to be moved somewhere in order to merge SC and SCV. > > # Include randoms directly in digital signatures > > > > > > Issue 224 > > > > > > Consensus at the interim was that this has straightforward to do by > > > just having the authentication server supply the ServerRandom was > > > enough since it can search through the handshake transcript. > > > > This assumes that authentication server receives full handshake and > > not just handshake To-Be-Signed. > > > > There was a lot of confusion at the interim about whether the concern here > was an auth server at the attesting party or the relying party. Well, AFAICT if the privileges are different, on attesting party signing code has higher privileges. On relying party, verification code has lower privileges. (The "lower privileges verify" can come up e.g. if performing pubkey extraction is unacceptable risk in main TLS code. In that case, I don't think you can do better than just trust output of that code). But in case of higher privilege sign, I think there might be ways to try to prevent higher privilege signing code from being abused. > > > # PRF designation in server certificate verify > > > > > > Issue 227 > > > > > > Consensus was to leave as-is. A hash identifier isn't the way to > > > solve this. What you really need is contributory behavior to solve > > > this issue. > > > > Huh? This is about collisions between different hash algorithms. I > > don't see how contributory behavior would help there (which is severly > > limited by 1RTT maximum there). > > > > Now, the issue is probably entierely theoretical and thus would not > > need solving. > > There was confusion about this too. Could you provide a (perhaps contrived) > example of the attack you are concerned about and a mechanism which would > defend against it? Suppose one has different hash functions G and H. Server signs handshake hash G(handshake_attacker_server). Attacker manipulates the handshake so that H(handshake_client_attacker) = G(handshake_attacker_server). If client accepts hash function H, that results in inpersonation. In theory, you can't prove security against this attack starting from assumption that G and H are secure hash functions. In practice, if G and H are even near secure and not closely related, that attack should be infeasible. In contrast, if Tag(F) is identifier for F, different for each hash, then: Tag(G)|G(x) = Tag(H)|H(y) Impiles G=H and G(x)=G(y), which contradicts collision resistance of G. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
