Re: [tcpinc] Review of draft-ietf-tcpinc-api-03

Kyle Rose <krose@krose.org> Wed, 04 October 2017 20:34 UTC

Return-Path: <krose@krose.org>
X-Original-To: tcpinc@ietfa.amsl.com
Delivered-To: tcpinc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C6C134484 for <tcpinc@ietfa.amsl.com>; Wed, 4 Oct 2017 13:34:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjjYYvNsCIlG for <tcpinc@ietfa.amsl.com>; Wed, 4 Oct 2017 13:34:42 -0700 (PDT)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EE981331E7 for <tcpinc@ietf.org>; Wed, 4 Oct 2017 13:34:41 -0700 (PDT)
Received: by mail-qk0-x233.google.com with SMTP id r64so12527242qkc.1 for <tcpinc@ietf.org>; Wed, 04 Oct 2017 13:34:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Nz8ZLX7/pMUxHUxpRcAE2ek6g77cQF7+palsQQGjATk=; b=iAPKdKbiDNE+aG8b+L/fkR5Rhg0rE2+nUQ4IXW1KADGdgmpbX4BE6zjtBtHo0AEZEq 9r0qUCD6rhvgjUy5WeKwB+9LIBMpkIU4+uEmUVTIYRYIREOwlJPc/ztbh8CdLaMq5Y4Q lygAjk3HSWn4KU1f4dCOkRCxx+hbac0J8gpM0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Nz8ZLX7/pMUxHUxpRcAE2ek6g77cQF7+palsQQGjATk=; b=c+dHAvEiPqvw+yBZlMERY+Q40no7/DtQ5t7F/cG4NxLX7vReg/hOop+bMUnt1n5DPO blB5H5Ra82txuOGMaXYfIUyFXNKOXeJYCzYOLlGuOVPpPkvhxLa4VG7m9f5jCX+aWXyx XosWWZZGTJAXuc+fO9wX/VkhmqYwasHbprqm3uvEBA7+2XcAcIdsQKOdU87XZ+6u5yEl EYPCAlVb417kDGmHGZlLtz/fNxdQ8083Ya7BcWv5RnaFye0R0/RmPiJrVjU4VzpeNbN5 Tmj9zCoVL+CxP6p05DRRPt5plDwfRZRwiNlV/ikuUh89s9r10qUoGwthQt29mi9gj6qt u1yQ==
X-Gm-Message-State: AMCzsaX6jNsN9PtNDWmKKHzRa4U7VHI61NI10+fWljKk+U972+LodsrS R3lg4aRfXOBwBTKNsmOy2eMOyyPCoQgZytXImasv6pYtU6I=
X-Google-Smtp-Source: AOwi7QD2eVaLUM/bwuvS6ZWjiDI+rMJXq5xKRPoBUxpF3Yazj3ESp95abPr9UYRM8bZ7RQ9lw0vxY1j7/o92kPYFWPI=
X-Received: by 10.55.179.196 with SMTP id c187mr27071072qkf.9.1507149280785; Wed, 04 Oct 2017 13:34:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.137.119 with HTTP; Wed, 4 Oct 2017 13:34:40 -0700 (PDT)
X-Originating-IP: [72.246.0.14]
In-Reply-To: <87infwrrw7.fsf@ta.scs.stanford.edu>
References: <CAJU8_nW_SLVBHvnELTq_vWVN+TtFh6hmST-O2+MQSyA19=5pyw@mail.gmail.com> <87d16894hg.fsf@ta.scs.stanford.edu> <CAJU8_nVkNTOsDvWkmDWggWD5rgyRp1MGLxS-iKBH=0-9hVBiQQ@mail.gmail.com> <87infwrrw7.fsf@ta.scs.stanford.edu>
From: Kyle Rose <krose@krose.org>
Date: Wed, 4 Oct 2017 16:34:40 -0400
Message-ID: <CAJU8_nXkTB4zOS_JzGjjiebwpUByRXNYaghBCHbU7s7-htUyVQ@mail.gmail.com>
To: David Mazieres expires 2018-01-01 PST <mazieres-t9u9hmk3vpz5my8ewn7urnqwxa@temporary-address.scs.stanford.edu>
Cc: tcpinc <tcpinc@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/9gAc850uvbYEF5EB9Fg9NuMUdCw>
Subject: Re: [tcpinc] Review of draft-ietf-tcpinc-api-03
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Working group mailing list for TCP Increased Security \(tcpinc\)" <tcpinc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpinc/>
List-Post: <mailto:tcpinc@ietf.org>
List-Help: <mailto:tcpinc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Oct 2017 20:34:46 -0000

On Tue, Oct 3, 2017 at 2:46 PM, David Mazieres expires 2018-01-01 PST
<mazieres-t9u9hmk3vpz5my8ewn7urnqwxa@temporary-address.scs.stanford.edu>
wrote:
>> What I mean is maybe best illustrated by example. Server-only auth in
>> TLS provides protection against MitM attacks because the client
>> authenticates the output of a derivation from some secret that cannot
>> be engineered by an adversary to be the same on two connections:
>> modulo a compromise of the signing key or collusion by one of the two
>> endpoints, this is a proof that with overwhelming probability only the
>> server and the client know the symmetric key material protecting the
>> connection. But the server's protection in this case relies on the
>> client taking action: that is, authenticating the server's certificate
>> and hanging up if the cert check fails. If not, the MitM can pretend
>> to be the server to the client, and the server would never know. This
>> is not true with mutual authentication based on a channel binding, as
>> either endpoint would be able to distinguish a legit connection from a
>> broken one.
>
> What you are saying is different enough from how I would think of the
> problem that I'm not sure how to process the feedback.  In particular,
> "symmetric keying material" is a layer of abstraction below what should
> be in the security model.  Can you maybe suggest some concrete language
> for the draft?  Maybe there's some missing logical step about how in
> many situations an attack on a client also undermines the server's
> interests?
>
> Or, popping back up a level, is there a mistake someone might make that
> we could plausibly avert by inserting appropriate language about
> unilateral authentication in the draft?  By analogy, things like "always
> check the session ID if you rely on ENO for communications security" and
> "always make sure you have an adequate source of randomness" are good
> reminders.  It sounds like you are suggesting "always make sure your
> anonymous remote clients check the session ID"--but what are servers
> supposed to do about this?  Is there some actionable advice for servers?

The problem is application-layer protocols that falsely assume "I am
the client and am still willing to talk" implies some kind of
authentication of the client or proof of integrity of the
communication channel. It doesn't do either of those: server-only auth
implies only that a properly-working client with access to some
application-layer secret is assured that there is no MitM on its
connection with the server, and so it is safe to use the secret on
this connection without worry about eavesdroppers (as long as the
server is functioning correctly). The server doesn't derive any
knowledge directly from continued communication with the client. The
server can conclude by receiving (for example) a proof of knowledge of
that secret only that the sender has access to the secret, which could
be from (1) a legitimate client, (2) a MitM if the client didn't
perform server auth, or (3) an adversary with access to a compromised
secret. I'll rule out (3) as being analogous to an
incorrectly-functioning server, but that leaves (1) and (2).

It's been a while, but I think I was reacting specifically to the lack
of parallelism between 5.1 and 5.2. 5.1 says:

  q( Each side must verify that the other side's authenticator is correct. )

which mutually authenticates the connection and rules out (2), while 5.2 says:

  q( Whichever side validates an authenticator in this way knows that
the other side belongs to a host that possesses the appropriate
signature key. )

which only authenticates whichever side(s) send signatures and so permits (2).

What I took issue with was that pre-shared key symmetric
authentication and signatures were being treated differently when the
signature mechanism is actually irrelevant to the properties provided
by one-way vs. mutual auth. If this is server-only auth, whether
symmetric or asymmetric, the client must then authenticate itself at
the application layer before the server can safely send it anything
secret.

I think I would probably reword 5.2 to sound more like 5.1, e.g.,
"Each side must verify that the other side's signature is correct",
and then maybe mention that if the client lacks a signature key it
must first authenticate the server and then present an
application-layer authenticator over the channel it knows is secure
before the server can assume anything about the privacy or integrity
of the connection.

Kyle