Re: [tcpinc] Review of draft-ietf-tcpinc-tcpeno-10

[Watson Ladd <[e-mail]>]

On Thu, Oct 19, 2017 at 2:34 AM, David Mazieres <
[e-mail]> wrote:

> Watson Ladd <[e-mail]> writes:
>
> > Dear all,
> >
> > I have reviewed this document as part of the security directorate's
> > ongoing effort to review all IETF documents being processed by the
> > IESG.  These comments were written primarily for the benefit of the
> > security area directors.  Document editors and WG chairs should treat
> > these comments just like any other last call comments.
> >
> > The summary of the review is that the writing and most of the
> > structure is fine, but I am a bit confused by some of the security
> > properties and how they are stated. It is not clear to me why the
> > unpredictability of generated session IDs is required.
>
> Thanks for your review.
>
> Unpredictability of session IDs is required because doing so is not
> particularly burdensome and because it's a very strong property that
> subsumes the security requirements of a broad range of cases where
> things might otherwise go wrong.  For example, the TEP has to be 33
> bytes, and we don't want the last 16 of them being zeros.  Moreover, if
> people sign session IDs for authentication, we want to be absolutely
> sure they don't mess up the domain separation.  As another example,
> someone might use a session ID on one connection to try to authenticate
> a session ID on another.  Do you buy this rationale?  And is it
> important enough that you think we need to add a subsection to the
> rationale section discussing it?
>

More rational for the requirement would I think help.

> It is also not clear to me that the requirement that a TEP produce
> > different keys for different transcripts is strong enough: we need to
> > ensure that every TEP produces different keys (with high probability)
> > (and session identifiers) for different transcripts to prevent
> > cross-protocol attacks.
>
> Do you mind clarifying this comment?  I assume it's in relation the
> following two paragraphs from sections 4.8 and 10 respectively?
>
>    To defend against attacks on encryption negotiation itself, a TEP
>    MUST with high probability fail to establish a working connection
>    between two ENO-compliant hosts when SYN-form ENO options have been
>    altered in transit.  (Of course, in the absence of endpoint
>    authentication, two compliant hosts can each still be connected to a
>    man-in-the-middle attacker.)  To detect SYN-form ENO option
>    tampering, TEPs must reference a transcript of TCP-ENO's negotiation.
>
>    ...
>
>    Because TCP-ENO enables multiple different TEPs to coexist, security
>    could potentially be only as strong as the weakest available TEP.  In
>    particular, if session IDs do not depend on the TCP-ENO transcript in
>    a strong way, an attacker can undetectably tamper with ENO options to
>    force negotiation of a deprecated and vulnerable TEP.  To avoid such
>    problems, TEPs MUST compute session IDs using only well-studied and
>    conservative hash functions.  That way, even if other parts of a TEP
>    are vulnerable, it is still intractable for an attacker to induce
>    identical session IDs at both ends after tampering with ENO contents
>    in SYN segments.
>
> The goal here is indeed to thwart both cross-TEP attacks and TEP
> downgrade attacks, but to do so without mandating a particular hash
> function for all TEPS, because that would severely hamper crypto
> agility.  The extra byte in session IDs should save us from cases where
> somehow both SHA-512 and Keccac are secure, but someone found two inputs
> x and y such that SHA-512(x)==SHA-3(y) causing reuse of Session IDs
> across TEPs.  So I can't figure out the attack you are worried about...
>

Ah, that does work. Thanks for responding to my review.


>
> Thanks,
> David
>



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.