Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

Colm MacCárthaigh <colm@allcosts.net> Tue, 06 March 2018 22:35 UTC

Return-Path: <colm@allcosts.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F2B1201F2 for <tls@ietfa.amsl.com>; Tue, 6 Mar 2018 14:35:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.com
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 v55GNMjrGMVv for <tls@ietfa.amsl.com>; Tue, 6 Mar 2018 14:35:25 -0800 (PST)
Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 4D9CF126BF6 for <tls@ietf.org>; Tue, 6 Mar 2018 14:35:25 -0800 (PST)
Received: by mail-yw0-x22c.google.com with SMTP id y186so99174ywf.7 for <tls@ietf.org>; Tue, 06 Mar 2018 14:35:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KH95ikBnJb4+d8Teq03zRmmiujNZXgHee9MrICXA/5Y=; b=byUVEqzOs0EPuOHQ7lXN5k0/Pq/Tj7bHfeJEH8M9LllsfespeaHTV48yhA/Z935sWk O+fmEcBY7h1VKW4/yAqu8hXzp3vR4q8xk8SNL/yCHYTWc+OYP6bIQB9xX1hL4fis1WA3 8zCXxPOYgPp7IR2+EvnH++XGptzevbcdeLAy1GBWVuvpe4u38booF5tXW8TU+9ukn0Ge j6VI4WVM05jGT8I2ZtGwAsLk1rs2MkQMJGNjv8p0F82R/txM+9t+u9WVQmK7ZmETGm6m s12Z/T63IGQKqbKGv1mdDahg7jB7+i4lenTW5E+KFQJOLAyof7X+PCBQlwKsg3NZq166 AlIA==
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=KH95ikBnJb4+d8Teq03zRmmiujNZXgHee9MrICXA/5Y=; b=UKt01W+Yd+DL0QT4h0VEsnNtpstBJZbCBEpJ/7fhWIXnZEnopFS72m9k5NtJDbircw Gii7ywa1yua0h6Frk2qWrLPpzyZ6yOPEcacnQ7DT51j+QI9jb8bnDWgvR4KtNNX8XbbO 1qp38nJtblQTlTBoF/1d8zLYiWUC0F9/4/yq5gj6TqcJby67hNAWtVYqjYDvVJnX9OO7 OvX3PQ6FFRhXOBg4vd66lFi29N4y/PerzpxJp7hWtKSgFtq9incNwLIrSsn9wldDN7Hd mXofl89MZp9O2Jzojkg3IXFesplKgngYjjGSSiOBAztzLwkbo7YvhUmP5xk5h1ibx50E 0uYw==
X-Gm-Message-State: APf1xPAIighRHPqzMUPZp2WrRVeAyEcaVgZb14eyg3tuLUDpfNDgrbab Ai5ZUH8/bSy/T6Kmt4FiuUov64cn4W3aU2ilKNeEPw==
X-Google-Smtp-Source: AG47ELvoYE5etJNyRVgIWqm7FF1rsezArgFJohLXs3aNiwBrji9C3kR5Dt8+NUuGk0w7GDyKS+NSIvz+6/wFa5blX0I=
X-Received: by 10.129.212.8 with SMTP id z8mr12865841ywi.310.1520375724338; Tue, 06 Mar 2018 14:35:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.108.203 with HTTP; Tue, 6 Mar 2018 14:35:23 -0800 (PST)
In-Reply-To: <152004960327.8290.4628820807186314931@ietfa.amsl.com>
References: <152004960327.8290.4628820807186314931@ietfa.amsl.com>
From: Colm MacCárthaigh <colm@allcosts.net>
Date: Tue, 06 Mar 2018 14:35:23 -0800
Message-ID: <CAAF6GDcBFHhe8oWJqF-LVUfYdR7HRW_Gk9c0KgxNRKoQzauvpQ@mail.gmail.com>
To: Dale Worley <worley@ariadne.com>
Cc: gen-art@ietf.org, ietf@ietf.org, draft-ietf-tls-tls13.all@ietf.org, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="f403043ee3acf984590566c60ecf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/DyLj93w0RHIIIlCFkr_RbUPC4Jo>
Subject: Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 06 Mar 2018 22:35:27 -0000

On Fri, Mar 2, 2018 at 8:00 PM, Dale Worley <worley@ariadne.com> wrote:

> - There are about 28 error codes but nearly 150 places where the text
>   require the connection to be aborted with an error -- and hence,
>   nearly 150 distinct constraints that can be violated.  There are 19
>   alone for "illegal_parameter".  I would like to see an "alert
>   extension value" which assigns a distinct "minor" code to each
>   statement in the text that requires an error response (with
>   implementations being allowed to be a bit sloppy in providing the
>   correct minor code).
>

Your review is incredibly deep, comprehensive and I learned a lot from it.
I want to pick out just one small piece, but don't mean that to diminish
how thorough it was!

On the specific suggestion of having more granular error codes, I think
this is a dangerous direction to take lightly; there's at least one
instance where granular TLS alert messages have directly led to security
issues by acting as oracles that aided the attacker.

There's a general conjecture that the more information that is provided to
attackers, the more easily they can leverage into a compromise. Personally
I believe that conjecture, and would actually prefer to see fewer signals,
ideally as few as one big error code. There is a trade-off against
debugability, but I've only seen a handful of people have the skills to
debug low level TLS issues and it doesn't seem worth the risk. Others
disagree, which is valid, but it's at least an area of reasonable
contention.

-- 
Colm