As it happens, I was able to take a look. Several notes from my review: - Not all algorithms take a 12 byte nonce, so you probably want to allow some generality here. - I'm not sure you still need the NONCE_MAGIC value. - Do you want to cover SACK in the section about how you handle deprotection failures.
On Fri, Nov 17, 2017 at 8:17 PM, Daniel B Giffin <d...@scs.stanford.edu> wrote > > > Given that you are allowing P-256 and point reuse, you > > should be requiring point validation. See: > > https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13. > html#rfc.section.4.2.8.2 > > https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13. > html#elliptic-curve-diffie-hellman > > Yes, thank you. For the NIST curves, I have added: > > Implementations MUST validate these "pubkey" values according to > the > algorithm in [ieee1363] Section A.16.10. > > But I see that TLS refers to ANSI X9.62 for validation, even > though it refers to IEEE1363 for DH computation. Is there a > good reason not to stick with the one source? > TBH, not sure. Filed an issue on TLS for that. > Also, I guess there's no need to check on-the-curve if we > allow only compressed format, and it's not perfectly clear > to me whether we need to check group membership, but I'd > really rather not have all these details in this document if > there's a good way to cite it out. > I think your text is fine. > You should probably also be requiring Curve25519 output validation. > > I think you're saying we should check that the DH result is > not zero? > > No harm, I suppose, but I'm going to try to get guidance on > whether it's necessary. > It's the way we're going in the security area. Is there some reason not to. > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > > > The design of session resumption here essentially precludes doing > > tcpcrypt resumption across servers (as one does with TLS) because you > > need extremely tight control of ss[i] or you have catastrophic > > results. Was this a deliberate choice by the WG? > > I think it's a choice to keep key material in the kernel and > to have control over forward secrecy. > See my separate note on this topoic. > > > suboption containing the TEP identifier and "v = 0". In order to > > propose session resumption (described further below) with a > > particular TEP, a host sends a variable-length suboption containing > > > > It would be clearer if you explained resumption here. > > > > PRK = Extract(N_A, eno-transcript | Init1 | Init2 | ES) > > What is the rationale for providing N_A as the salt to HKDF-Extract, > given that > > you also supply N_A in the Init1 message? > > I'm not qualified to say. I agree it seems "redundant", but > it appears to achieve what it needs to. Perhaps we can find > a more satisfying answer for you ... > I agree it's harmless, but I'd be interested. -Ekr
_______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
