Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)

Ryan Sleevi <ryan-ietftls@sleevi.com> Sat, 19 February 2022 21:29 UTC

Return-Path: <ryan.sleevi@gmail.com>
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 3E8B83A0C15 for <tls@ietfa.amsl.com>; Sat, 19 Feb 2022 13:29:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.398
X-Spam-Level:
X-Spam-Status: No, score=-6.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 AyKbjXikrC9f for <tls@ietfa.amsl.com>; Sat, 19 Feb 2022 13:29:05 -0800 (PST)
Received: from mail-ua1-f45.google.com (mail-ua1-f45.google.com [209.85.222.45]) (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 6B12E3A0C09 for <tls@ietf.org>; Sat, 19 Feb 2022 13:29:05 -0800 (PST)
Received: by mail-ua1-f45.google.com with SMTP id b37so5968023uad.12 for <tls@ietf.org>; Sat, 19 Feb 2022 13:29:05 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=f7LPIp2dHSza1AzcHNVU7X6ddo2IqSWfVfWtHaxtmJo=; b=QaZcqvUZ78y4MdkuLff//ELUfWB/P3jXTIMPhq4qrmHYYDIKmv9VUt/x5vRUab2B4t OnquoQWMKI9o1HeU78GL/qq9RzWRHOk06uUln27ChtNZPs36KI4Gh2Cf/Zc2CJ+u5gt+ 3vTyxMyZTuXCDQ7v6R4iE1OHoyPFXgZ2Kp+nlvPCn6LruWBjmHpX3GUVbkQ3n7m9loiA 63dC4b2qS6Wleu6If3+gc7hkbNqM/iyiWUfv9BFPEASMXAA9Pjdsg0PejVzdl27PwUUr jSUtRJtdAg07UWjUSh0NGXIWDcocXmSEIVAolOwGD47XAWVB6b+hN4VN94i4KW2z6tlY DmkA==
X-Gm-Message-State: AOAM532ihw3Dt3ljon6ByAo9bFQWo7H3w2paVTyspJPqr5ZJGEdomtaG gJet+uVaeVSEejlQzXzGrFii5fIloqA=
X-Google-Smtp-Source: ABdhPJwrktD7RxKOSXu0znVZ8I3tOqfujYEwH3qS0Fuix2wL8SMpRO6xfNRvLpSQCitb7yrOFU+xtA==
X-Received: by 2002:ab0:b05:0:b0:342:2961:37ee with SMTP id b5-20020ab00b05000000b00342296137eemr711495uak.29.1645306144111; Sat, 19 Feb 2022 13:29:04 -0800 (PST)
Received: from mail-vk1-f178.google.com (mail-vk1-f178.google.com. [209.85.221.178]) by smtp.gmail.com with ESMTPSA id r26sm5253909uaw.12.2022.02.19.13.29.03 for <tls@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 19 Feb 2022 13:29:03 -0800 (PST)
Received: by mail-vk1-f178.google.com with SMTP id k128so6686084vkk.10 for <tls@ietf.org>; Sat, 19 Feb 2022 13:29:03 -0800 (PST)
X-Received: by 2002:a1f:a441:0:b0:330:e945:9c9a with SMTP id n62-20020a1fa441000000b00330e9459c9amr5813084vke.6.1645306143629; Sat, 19 Feb 2022 13:29:03 -0800 (PST)
MIME-Version: 1.0
References: <83f923185c3741ccb668826f5b11b0c3@EX13D01ANC003.ant.amazon.com> <CAErg=HFamywTBGriKsVd4eB=yo46Mz2JcKnnjHY8s36f12qEFg@mail.gmail.com> <180543c01fdf439cbdfd8214ec75eb76@EX13D01ANC003.ant.amazon.com> <CAErg=HGufDVCKN+PqPQ80MoVobK0N7ocVjLoDaAyqq5+Bma6TQ@mail.gmail.com> <caa7508995694a56b5b5f632ed8bf49a@EX13D01ANC003.ant.amazon.com> <YhDRHwiTXI6T78+c@LK-Perkele-VII2.locald>
In-Reply-To: <YhDRHwiTXI6T78+c@LK-Perkele-VII2.locald>
From: Ryan Sleevi <ryan-ietftls@sleevi.com>
Date: Sat, 19 Feb 2022 16:28:52 -0500
X-Gmail-Original-Message-ID: <CAErg=HEKPrxxg2gCqpZCOedhHpWvUmXEPVLTW8Cx2t8fSURmyQ@mail.gmail.com>
Message-ID: <CAErg=HEKPrxxg2gCqpZCOedhHpWvUmXEPVLTW8Cx2t8fSURmyQ@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003ceb3f05d865b057"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/vmO0QbpuaGMLocy5YNO4ulRzXg4>
Subject: Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 19 Feb 2022 21:29:11 -0000

On Sat, Feb 19, 2022 at 6:15 AM Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> > - Connection re-establishment affects the security and privacy
> > assumptions and should be captured. I am not sure the concern is
> > worse than the regular fingerprinting text already in the draft,
> > but point taken. We can improve the text and I created an issue
> > for it.
> https://github.com/csosto-pk/tls-suppress-intermediates/issues/12
>
> Regarding security and privacy, the most severe impact of any attack
> I can come up with is determining if some arbitrary ICA is on the
> ICA list or not (for passive attacks, that is restricted to the issuing
> ICA used by the server). Practical impact of attacker being able to do
> that depends on how many endpoints share that same ICA list.
>
> Rough outline of the attack (active variant): Fabricate a certificate
> purporting to be from some ICA, send it to client and observe if the
> client retries (ICA not on the list) or just fails (ICA is on the list).


I'm hopeful that some may be interested to perform a more thorough
analysis. We saw enough complexity with respect to previous TLS versions
and the fallback logic being possible to induce downgrade attacks that I
think we should be very wary about introducing a class of anticipated
handshake failures that require connection re-establishment, especially
across independent TLS sessions. I realize that sounds a little like FUD,
but rather: every time we've tried to do this, it's blown up spectacularly,
so we need to make sure we're not setting up another bomb.

I also think the active attack analysis is a bit lacking, especially since
the attacker has the ability to mint arbitrary ICAs on demand, without
running afoul of any existing client policies. For example, for the Web
PKI, by virtue of nameConstraints without pathLen in the basicConstraints,
the site can mint arbitrary ICAs and arbitrary EE certificates. Combined
with the discovery mechanism discussed, this is effectively the same as
other forms of stateful tracking (ala HSTS tracking), and thus likely to be
subjected to the same mitigations that would largely render the benefits
here ineffective, at best.