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

"Kampanakis, Panos" <kpanos@amazon.com> Fri, 18 February 2022 19:10 UTC

Return-Path: <prvs=0412dd42c=kpanos@amazon.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 6692C3A0F42 for <tls@ietfa.amsl.com>; Fri, 18 Feb 2022 11:10:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.173
X-Spam-Level:
X-Spam-Status: No, score=-10.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 s4_wYElqUMqc for <tls@ietfa.amsl.com>; Fri, 18 Feb 2022 11:10:54 -0800 (PST)
Received: from smtp-fw-9103.amazon.com (smtp-fw-9103.amazon.com [207.171.188.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FC333A132F for <tls@ietf.org>; Fri, 18 Feb 2022 11:10:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1645211454; x=1676747454; h=from:to:cc:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=TJNFTnnRQ4C51lVQ3yrer1e6EYrXxsmz/zBTBj6ahvs=; b=nv0nc4D4NhNNnqUmNFG90xTYwiCuP5akkqIPbUhyM9hhodbQKUQrXXMn RtjjBFnkdwF9ssV0T1WVMyH5ng0BWo6bdzGbLhiYk0yTj0Hnv43eH0lnP ZDfTFzeBh4lhElfMyCSukaRXwag2izwE46sSbE4dqdjsZ/JQyqjAqs2AI c=;
X-IronPort-AV: E=Sophos;i="5.88,379,1635206400"; d="scan'208";a="993173899"
Thread-Topic: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)
Received: from pdx4-co-svc-p1-lb2-vlan2.amazon.com (HELO email-inbound-relay-pdx-2b-28a78e3f.us-west-2.amazon.com) ([10.25.36.210]) by smtp-border-fw-9103.sea19.amazon.com with ESMTP; 18 Feb 2022 19:10:39 +0000
Received: from EX13MTAUWB001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan2.pdx.amazon.com [10.236.137.194]) by email-inbound-relay-pdx-2b-28a78e3f.us-west-2.amazon.com (Postfix) with ESMTPS id 6C68BA0BD6; Fri, 18 Feb 2022 19:10:39 +0000 (UTC)
Received: from EX13D01ANC004.ant.amazon.com (10.43.157.237) by EX13MTAUWB001.ant.amazon.com (10.43.161.249) with Microsoft SMTP Server (TLS) id 15.0.1497.28; Fri, 18 Feb 2022 19:10:38 +0000
Received: from EX13D01ANC003.ant.amazon.com (10.43.157.68) by EX13D01ANC004.ant.amazon.com (10.43.157.237) with Microsoft SMTP Server (TLS) id 15.0.1497.28; Fri, 18 Feb 2022 19:10:37 +0000
Received: from EX13D01ANC003.ant.amazon.com ([10.43.157.68]) by EX13D01ANC003.ant.amazon.com ([10.43.157.68]) with mapi id 15.00.1497.028; Fri, 18 Feb 2022 19:10:37 +0000
From: "Kampanakis, Panos" <kpanos@amazon.com>
To: "ilariliusvaara@welho.com" <ilariliusvaara@welho.com>
CC: "tls@ietf.org" <tls@ietf.org>
Thread-Index: AdghU4+EMFFuriJ+SLKnIIleOIJolAAItyGAAC6M1iAAPdsXgABWdSJAAB1AJAAAAN/R0A==
Date: Fri, 18 Feb 2022 19:10:37 +0000
Message-ID: <c4a37beb39164d3899a71f26d5290711@EX13D01ANC003.ant.amazon.com>
References: <83f923185c3741ccb668826f5b11b0c3@EX13D01ANC003.ant.amazon.com> <YgoH5/zQS67JgexL@LK-Perkele-VII2.locald> <4a28a1fbfb3445cab4906d6266b3831e@EX13D01ANC003.ant.amazon.com> <YgzfZyXNVpbUjiqu@LK-Perkele-VII2.locald> <9eee53c130274c5497f7899026f22a76@EX13D01ANC003.ant.amazon.com> <Yg/n6Bie+YfV9HFL@LK-Perkele-VII2.locald>
In-Reply-To: <Yg/n6Bie+YfV9HFL@LK-Perkele-VII2.locald>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.157.155]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/83opT1W6jjIbSYu9dH_5r35IIFg>
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: Fri, 18 Feb 2022 19:10:59 -0000

Makes sense. 

The thing to clarify if tlsflags should mandate an acknowledgement by default. Yoav confirmed that the spirit of the tlsflags draft currently is to require an acknowledgement.

I am tracking it here https://github.com/csosto-pk/tls-suppress-intermediates/issues/9 , but I think the WG needs to reach consensus on the default behavior. 



-----Original Message-----
From: ilariliusvaara@welho.com <ilariliusvaara@welho.com> 
Sent: Friday, February 18, 2022 1:40 PM
To: Kampanakis, Panos <kpanos@amazon.com>
Cc: tls@ietf.org
Subject: RE: [EXTERNAL] [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



On Fri, Feb 18, 2022 at 04:47:09AM +0000, Kampanakis, Panos wrote:
>
> About the tlsflags, make sense. It would simplify things too. The 
> impression I got from the old draft-thomson-tls-sic thread and the 
> tlsflags draft was that it mandates an acknowledgement. I will confirm 
> with Yoav.

The text in tlsflags looks like it mandates an acknowledgement, but I think it might be just confusing text.

Regarding actual need for acknowledgement for this flag, I think that server acknowledging it could be useful so client knows if retrying without flag could be useful or not.

For the client acknowledging it, I find that much less useful. If server proposes the extension, it better have exhaustive issuer list, be using certificates as just holders for raw public keys, or using certificate fingerprints for identification. Anything else looks like it is asking for trouble.



-Ilari