Hey Tony, Thanks for the comments. Hopefully we can adapt this document to tick more boxes for you :) Since I had noticed some other errors in the document (e.g., figures not rendering properly), I went ahead and submitted a new version that takes these comments into account.
https://tools.ietf.org/html/draft-barnes-tls-pake-01 Some responses inline below. On Thu, Apr 12, 2018 at 9:23 AM, Tony Putman <tony.put...@dyson.com> wrote: > Hi Richard, > > > > I work in the IoT space and am interested in handshakes that involve > little computation but offer better protection than symmetric PSK in the > event of server breach. > > > > *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Richard Barnes > *Sent:* 11 April 2018 15:54 > > […] > > We would love to hear any feedback on the approach proposed here, and on > whether other people here would be interested in working on a PAKE > mechanism for TLS in this working group. > > […] > > > > I was interested in this draft as it seemed to tick some boxes, and I > offer some comments below. But in the end I don't think it offers what I'm > looking for, so I can't offer to help with it in its current form. > > > > My main comment is that I disagree with the assertion in section 3 that > "w" is effectively a salted password hash. An attacker who obtains "w" can > impersonate the client to the server, so it is equivalent to a password. > The only advantage is that a server breach cannot be extended to other > servers where the user uses the same password, but different salts are > used. It seems to me that SPAKE2+ prevents this, so perhaps this should be > used instead. > > > > Secondly, SPAKE2 is fitted to the TLS 1.3 handshake by forcing the client > to know the salt. This seems unreasonable to me unless there is also some > mechanism to retrieve the salt from the server. Could the salt be a hash of > client identity and server identity? (I suspect there is not enough entropy > in this). But in any case I think this is an issue which must be addressed > in the draft. > I'm not a cryptographer, but it seems to me that combining the client and server identities would probably provide enough salt. After all, the idea of salt is just to make add a small degree of multiplicity to the hash. Your point about SPAKE2+ / having the server only store public keys is probably superseding, though. I agree that we should try to arrange this protocol so that the server only has to store a verifier value, but it's not totally clear whether SPAKE2+ is needed, or whether we can use SPAKE2 and just have the server cache w*N. After all, both w and N are fixed over multiple runs of the protocol, so it doesn't seem like there's much benefit to storing w and not w*N. Given all that, I think my proposal would be: - w = H( client identity || SNI || password ) (probably by extending the IdentifierAndPassword struct that's in the document now) - Client stores w or takes identities/password as input - Server stores w*N Maybe Ben or Watson (CCed) could comment on whether this approach seems sound. > Why does the draft need to specify what the identity of the server is? It > doesn't seem to be used. > The identity field that the server sends isn't intended to be the server's identity, but rather to indicate which of the client's offered identities the server has selected. The design pattern here is the same as the key_share extension in TLS 1.3, where the server sends back a (group, key share) pair, and the group identifies which of the client's shares the server is using. https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#key-share > > Would it be helpful to send a list of SPAKE2Shares in ClientHello? For > example, if the application layer protocol is being negotiated, would it be > necessary to supply shares for multiple protocols? Alternatively, if the > client and/or server support multiple pre-provisioned values (G, M, N, H), > how would this be signalled/managed? And would there be associated security > concerns? > The ClientHello extension in the document (SPAKE2ClientHello) already allows the client to send multiple SPAKE2Shares. Note, however, that the only thing that can be negotiated is which identity/password is to be used. The current document assumes that the group (and thus G, M, N) and the hash function (H) are fixed / pre-negotiated based on the identity. I can understand why people might want negotiation, but it does seem safer to me to only ever use a given password with the same group and hash. It's also consistent with the "server stores w*N" approach above. > It is worth noting explicitly somewhere that x and y should have the same > ephemeral characteristics as are used by the key_share elements, and that > if this is followed then forward secrecy is provided by SPAKE2. > Agreed. > IMHO "w" should not be used as the PSK input. If somebody gets hold of a > derived key (e.g. early_exporter_master_secret) then the low entropy of "w" > may allow it to be recovered. "K" provides all that's needed for key > derivation. > > Agreed. Using "w" in the key schedule also means that the server has to have it. As noted above, this is bad. > The draft should recommend somewhere (security section?) that H should be > suitable for password hashing (e.g. Argon2) and not a standard hash > function. This is particularly true if my earlier suggestion to use SPAKE2+ > is followed. > Agreed. --Richard > > > Regards, > > Tony > > > > Dyson Technology Limited, company number 01959090, Tetbury Hill, > Malmesbury, SN16 0RP, UK. > This message is intended solely for the addressee and may contain > confidential information. If you have received this message in error, > please immediately and permanently delete it, and do not use, copy or > disclose the information contained in this message or in any attachment. > Dyson may monitor email traffic data and content for security & training. >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
