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

[Eric Rescorla <[e-mail]>]

On Mon, Nov 13, 2017 at 5:15 AM, David Mazieres <
[e-mail]> wrote:

> Eric Rescorla <[e-mail]> writes:
>
> >> >    connection or when there is any ambiguity over the meaning of the
> SYN
> >> >    data.  This requirement applies to hosts that implement ENO even
> when
> >> >    ENO has been disabled by configuration.  However, note that
> >> > I think you may mean to say "when the last SYN TEP is not eventually
> >> negotiated"
> >>
> >> No, we definitely mean *any* ambiguity, including other unrelated RFCs.
> >> Like if the segment contains a non-empty TFO option, for example.  This
> >> is clarified again below, with:
> >>
> >> * The SYN segment contains a non-empty TFO option or any other TCP
> >>   option implying a conflicting definition of SYN data.
> >>
> >> So does this need a clarification, or is the existing wording okay?
> >>
> >
> > Sorry, I meant to replace "When the SYN TEP does not govern the
> > connection", not the point about ambiguity,.
>
> So in the first paragraph of the section, we define SYN TEP as follows:
>
>         The meaning of data in a SYN segment with an ENO option (a
>         SYN+ENO segment) is determined by the last TEP identifier in the
>         ENO option, which we term the segment's _SYN TEP_.
>
> So I think the problem here may be that the term SYN TEP is confusing,
> or that the definition does not stand out enough.


The problem is that "govern" is not very clear. It's clearer to link the
requirement
here to the specific feature of the packet.


If that's the case, then rather than fix the sentence you highlighted, I
> think we need a better term/and or better definition.  What about
> "SYN-data TEP", since it's the TEP governing data in the SYN segment?
>

i don't really understand what you are proposing here.


>
> >> >    o  TEPs MUST NOT depend on long-lived secrets for data
> >> >       confidentiality, as implementations SHOULD provide forward
> secrecy
> >> >       some bounded, short time after the close of a TCP connection.
> >> > Maybe "depend solely" because one might want to use a DH mode where a
> >> static DH
> >> > key is mixed in with an ephemeral.
> >>
> >> I'm confused by this comment.  Either you depend on a long-lived secret
> >> for data confidentiality or you don't.  In your example, would
> >> compromising the long-lived DH key also break past connections?  If so,
> >> then you have a bad TEP.  If not, then you don't depend on a long-lived
> >> secret for confidentiality, so your TEP is permissible.
> >>
> >
> > Well, as Cas Cremers keeps pointing out, if you also had a weak PRNG,
> > then you would in fact be depending on the static DH key. I think my
> problem
> > is the word "depend" which seems imprecise.
> >
> > It' s clumsy but perhaps
> > "TEPs MUST NOT be designed so that compromise of a long-lived secret
> > compromises confidentiality"
>
> The security considerations section already makes having an adequate
> source of randomness a MUST, so indeed we categorically want to rule out
> a weak PRNG in the normative language!
>

I don't disagree with that. But implementations have defects sometimes and
also
see my point about pinning below


Remember, the "MUST" in question is a requirements for TEPs, not for TEP
> implementations.  We deliberately made forward secrecy of the
> implementation only a SHOULD.  However, the TEP itself MUST be designed
> to avoid dependence on long-lived secrets for data confidentiality.  I
> believe the existing language correctly prohibits TEPs from requiring
> long-lived static DH keys, even if certain *implementations* wind up
> keeping keys around longer than indicated by the TEP specification.
>
> If you still think there's a problem with the current language, can you
> supply a more concrete example?  It sounds like you have a specific kind
> of protocol in mind that you think should be legal but isn't under the
> current draft.


Sure. OPTLS for example. This has PFS but also is robust against compromise
of the ephemeral key.



> However, I can't figure out what that is because I don't
> see how to make long-lived static DH parameters useful in a TEP.
>
Long-lived static DH parameters seem more useful for some kind of
> higher-layer application protocol that authenticates session IDs...
>

They are useful in two ways:

1. If you wanted to do TOFU on the remote key.
2. If you were concerned about the ephemeral PRNG (even if you intended
it to be strong) but you believed your initial PRNG to be strong.


-Ekr


> Thanks,
> David
>