Re: [tcpinc] Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpcrypt-09: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

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 <[e-mail]>
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