Re: [Uta] [Last-Call] Artart last call review of draft-ietf-uta-rfc7525bis-09

Cullen Jennings <fluffy@iii.ca> Sat, 09 July 2022 20:30 UTC

Return-Path: <fluffy@iii.ca>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14535C15A723 for <uta@ietfa.amsl.com>; Sat, 9 Jul 2022 13:30:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwx9ONAwz7Vu for <uta@ietfa.amsl.com>; Sat, 9 Jul 2022 13:30:07 -0700 (PDT)
Received: from smtp72.iad3a.emailsrvr.com (smtp72.iad3a.emailsrvr.com [173.203.187.72]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86550C159492 for <uta@ietf.org>; Sat, 9 Jul 2022 13:30:07 -0700 (PDT)
X-Auth-ID: fluffy@iii.ca
Received: by smtp18.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 5D2B8239E1; Sat, 9 Jul 2022 16:30:04 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <DB9PR08MB65249A319F9E14A76EC424279C829@DB9PR08MB6524.eurprd08.prod.outlook.com>
Date: Sat, 09 Jul 2022 14:30:03 -0600
Cc: "art@ietf.org" <art@ietf.org>, "draft-ietf-uta-rfc7525bis.all@ietf.org" <draft-ietf-uta-rfc7525bis.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "uta@ietf.org" <uta@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C2B07B42-7C1A-491F-97C9-BE4E6E9C5B05@iii.ca>
References: <165728991008.45773.10659091812976572509@ietfa.amsl.com> <DB9PR08MB65249A319F9E14A76EC424279C829@DB9PR08MB6524.eurprd08.prod.outlook.com>
To: Thomas Fossati <Thomas.Fossati@arm.com>
X-Mailer: Apple Mail (2.3696.100.31)
X-Classification-ID: 2866c055-4211-4ebd-8274-a08a7f4c2dde-1-1
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/fhFcNtfdlYmOBbAJDEIx4zmhg_g>
Subject: Re: [Uta] [Last-Call] Artart last call review of draft-ietf-uta-rfc7525bis-09
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Jul 2022 20:30:12 -0000


> On Jul 8, 2022, at 9:37 AM, Thomas Fossati <Thomas.Fossati@arm.com> wrote:
> 
> 
> I keep an eye on data from a cute crawler [0] that regularly scans the
> top 1 million web sites, and twice per year makes a summary of the
> trends.  (You can find the freshly collected raw data [1] as well as the
> most recent summary [2].)
>  
> What I gather from that data set is that the amount of traffic < 1.2 is
> becoming quasi invisible (*).  So I would be really surprised if
> Mozilla, Apple and Google, which are surely captured by the crawler,
> were among the very few caught red-handed supporting ver ∈ [1.0, 1.1].
>  

Very interesting.  I think this is important that we get to the bottom of this because the data you are basing some of your conclusions on looks wrong to me. 

I’m reading 
https://scotthelme.co.uk/top-1-million-analysis-november-2021/ 
and there is a section labeled "TLS, old and new” which has a table that lists TLS 1.1 at zero. 

It also references a more specific file at  https://crawler.ninja/files/protocols.txt which currently has the following in that file

TLS Protocol Versions:
TLSv1.3 386,472
TLSv1.2 179,549
TLSv1.0 515

Again implying 1.1 is at 0. If this is supposed to represent the number of sites that offer 1.1, out of the top million, well, I think it wrong. I also don’t think what web sites are are offering a given version is a very great metric to estimate what non browsers TLS client applications are using but that is a different issue. 

I think it is pretty critical that we sort out.

Here is what that site lists as top 10 sites ( I disagree it is the top 10 by clients that use it but close enough for some data ) 

1,google.com
2,akamaiedge.net
3,facebook.com
4,youtube.com
5,gtld-servers.net
6,netflix.com
7,microsoft.com
8,instagram.com
9,twitter.com
10,akamai.net

I checked if they support TLS 1.1 with a command like " openssl s_client -connect google.com:443 -tls1_1 “.  What I got from Calgary on July 9 is 

1,google.com YES
2,akamaiedge.net (this is not a valid server so I randomly used e673.dsce9.akamaiedge.net)  YES
3,facebook.com NO
4,youtube.com YES
5,gtld-servers.net ( seriously, I don’t think this is the #5 domain by any sane definition ). Anyways, I can’t find where it does TLS so will ignore it. UNKNOWN
6,netflix.com YES
7,microsoft.com NO
8,instagram.com YES
9,twitter.com NO
10,akamai.net (I used e1699.dscx.akamaiedge.net ) YES

This looks like well over half of that top 10 list support TLS 1.1 which matches up with other data I have seen. 

What is your thoughts on why it is still turned on for that many ? I think the answer to that question could provide some really useful information for this draft. 

Just so I am not taken the wrong way here, I am not at all arguing that SHA1 is fine for TLS. The advice I give people is put together a threat model for your use of TLS, figure out which, if any clients would be impacted by going to version X, and make a rational decision about if you should move to requiring version X. If your client are all safari or chrome in US or EU on smart phones that are within the apple software update window, the cost of moving might be nearly zero - if you are supporting very old, very cheap mobile phones globally, your stats are going to be a bit different.  If what you are  transferring over TLS is a web page with a menu for your restaurant, your risk of using SHA1 might be pretty much zero. This draft can help provide that information for people to, as Spencer says, make good choices. I’d love to see the draft have more of that for this TLS 1.0 / 1.1 issue. 

I am also not arguing in any way that TLS 1.1 is not deprecated at the IETF. It is.The IETF published an RFC that said don’t use it. However deployments with excellent networking and security teams, like companies on the above list, are still supporting it for some use cases which makes me think it would be far more useful to provide some information about the risk and reasons to use it and not to use it. That would help people understand in a way that may have more impact in getting a transition to newer version that just another RFC that also says don’t use it with no extra info. 

We end up with some people saying “www.google.com” supports TLS 1.1 and if it is good enough for them, it works for me. But is far more subtle than that. The endpoints for google pay at pay.google.com do not support 1.1 even thought 1.1 might be fine for some of the www.google.com. This gets lost on people. 

I think there is room for additional useful information here. I’m not volunteering to write such advice, done is feature, and I am thankful to the people that created what is in the draft.