Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-00.txt

Jeffrey Walton <noloader@gmail.com> Mon, 15 June 2015 23:46 UTC

Return-Path: <noloader@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B1A1B30E8 for <tls@ietfa.amsl.com>; Mon, 15 Jun 2015 16:46:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 rrEwJbuexTi1 for <tls@ietfa.amsl.com>; Mon, 15 Jun 2015 16:46:03 -0700 (PDT)
Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (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 AC4561B30EA for <tls@ietf.org>; Mon, 15 Jun 2015 16:46:01 -0700 (PDT)
Received: by igboe5 with SMTP id oe5so42768949igb.1 for <tls@ietf.org>; Mon, 15 Jun 2015 16:46:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ATYGMWEPCuldAW7+JJROFf/6XmlxH7ehviF8bBiN5ZM=; b=mNgK2rpu5lqj/7rcq1vxubYc1nTzLHB/njArKz8ZGU4vpkiyGA9s+idARDCLqosjz6 TV5W8JrhmjZSrr7yO72yPOK0GODZEB/qTV34B50waS+BhvZKngtpNsbceNN0aOtO0PhE sjKphOlofCiuU6iisn14d4Mne++NAxGMXNDbNtLxww3c6SbD/Hc2AiaW5VRavtgJN28d cWkl6AApFc+Xv2I7s3K8BwCBh8br9wEQz44k9gJpqmXoVyzXRM11MU7CwrPWzCy04oMZ qipRFcrjs5K0zwYOO0XfQ+er4bX8VD8ufGGFl1tRN/UV/cG6PsFMmkSFIikTjiEbfnsy 8kaA==
MIME-Version: 1.0
X-Received: by 10.107.40.144 with SMTP id o138mr38171562ioo.66.1434411961228; Mon, 15 Jun 2015 16:46:01 -0700 (PDT)
Received: by 10.36.77.15 with HTTP; Mon, 15 Jun 2015 16:46:01 -0700 (PDT)
In-Reply-To: <87bnggk7ub.fsf@latte.josefsson.org>
References: <20150611170317.13732.72719.idtracker@ietfa.amsl.com> <201506122355.45772.davemgarrett@gmail.com> <87r3petrfq.fsf@latte.josefsson.org> <20150614134639.GN2050@mournblade.imrryr.org> <87bnggk7ub.fsf@latte.josefsson.org>
Date: Mon, 15 Jun 2015 19:46:01 -0400
Message-ID: <CAH8yC8=wUEpqrcCUdoYwTGbsjB25FUvHbj=zvXgo+5f4fmkt3Q@mail.gmail.com>
From: Jeffrey Walton <noloader@gmail.com>
To: Simon Josefsson <simon@josefsson.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/jNgI66Dq55S_v_HZPxCImG3RAs4>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: noloader@gmail.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jun 2015 23:46:05 -0000

>>> What is the use-case?
>>
>> 0.   Authentication other than via certificate-based PKI.  Establish
>>      anon TLS, and channel-bind the TLS-unique via GSSAPI or some
>>      other authentication method.
>>
>> 1.  Unauthenticated opportunistic TLS.
>>
>>     * Server performs no unnecessary signature operations,
>>       since the client can't verify the signature anyway.
>>       (More precisely the client can't verify the authenticity
>>       of the server keys, so it can only determine that somebody
>>       signed the handshake, but no idea whether it is the intended
>>       server).
>
> Both those use-cases can be achieved by choosing, say, ECDHE_ECDSA and
> not verify the signature, right?
>
That's a violation of the engineering requirements :) If you don't
need server authenticity, then you don't ask for it. If you ask for
it, then you have to validate it.

I know I'm splitting hairs, but I would reject that kind of check-in.
I fear a proliferation of
https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html.
It also creates a few extra rules, and we have to teach them to
developers, QA and auditors.

Jeff