Re: Quic: the elephant in the room

Andrew McConachie <andrew@depht.com> Mon, 12 April 2021 10:36 UTC

Return-Path: <andrew@depht.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB703A1785 for <ietf@ietfa.amsl.com>; Mon, 12 Apr 2021 03:36:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=depht-com.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 Mg_RgZ1v9azB for <ietf@ietfa.amsl.com>; Mon, 12 Apr 2021 03:36:48 -0700 (PDT)
Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 8F7163A1784 for <ietf@ietf.org>; Mon, 12 Apr 2021 03:36:48 -0700 (PDT)
Received: by mail-il1-x132.google.com with SMTP id b17so10558678ilh.6 for <ietf@ietf.org>; Mon, 12 Apr 2021 03:36:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=depht-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=xTzHi51IxWu8qqdrdHjpA24SSGf9xaSQ2IQohBlaJb4=; b=NcCACF0uzNvs3hgeXW/y6Gg1jil8pbJvouedKJ25tmS6Xqnd6qzbrGBaby6H4xxAt5 AmuOXKamb5WWnPNeccydntipnIYx8nmSAQJfE5BMBqz/VdAnT5wQT7tuHNc+hpbMN/Ae pMvs1mPzin6ValRZSsLsDaqNxBauu1CQNYUCHNtaK9KM/cfGGSXdYjhv38h34Wt3D9h/ 8ntrqv4hAnzjHQZJJnFHcq/ksT/Gy0Xf/cyvyS5FifkFZBaqvqCQouSVi3+mj+3CcjwS je/AE/ay/bFezXKVy2flJ65lh3ej/qDE/uL1fg78jkfLmQsKSZRTWxbgtWNBBX7TORSc 2Wug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=xTzHi51IxWu8qqdrdHjpA24SSGf9xaSQ2IQohBlaJb4=; b=lrOA0C8TS6cXS+4NEhPCkZjlT1Q8BymAGcxtqHCYTpzpZrysNbc+WQ3rULyC46gxe6 kUFWYUz7U4zNwTerMCfP3aoIhTIPiI/e7yM4Bxrqk3ZXuyAv5zXbwp0AkUEVRmBnltmm T+xMHYEknPO1fle6+ID/6nirUEYOotYOmun4Ff+CbwfVdlF2MZC2aABngavQyputlpBT n0FEFmlUykbcy0Mwxuee+D5Qct5UgTYL0ojSy40eojE9wsN7WkNOF7IRZAR6J/ECKEg5 3xYcQUNVw+vr90Ga/QAcY8JRn9eZh6Fb5GZFPa/F3XDFKz0JslDYPMD3g/2Ew+I5FSXk joWA==
X-Gm-Message-State: AOAM533WH95vJnsoRjmSPa887KmazAgA1OeFaisjPu0+2ff4HlOeMAOh v9TLjr66/TDh0UJVm1eg/XhBPQ==
X-Google-Smtp-Source: ABdhPJxn8+gacpr5xQdzbl21u/UHn8s+tNB8MINyX7LWHGa1KMD8/xKtkJB+6ScrPbBGtFGSXXnAhw==
X-Received: by 2002:a92:c566:: with SMTP id b6mr21371402ilj.162.1618223807184; Mon, 12 Apr 2021 03:36:47 -0700 (PDT)
Received: from [10.47.61.36] ([2a02:a212:9285:29f0:ac08:d99:63c3:56f5]) by smtp.gmail.com with ESMTPSA id g6sm3822996ilr.30.2021.04.12.03.36.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Apr 2021 03:36:46 -0700 (PDT)
From: "Andrew McConachie" <andrew@depht.com>
To: "Michael Thomas" <mike@mtcc.com>
Cc: "Salz, Rich" <rsalz@akamai.com>, "Phillip Hallam-Baker" <phill@hallambaker.com>, "IETF Discussion Mailing List" <ietf@ietf.org>
Subject: Re: Quic: the elephant in the room
Date: Mon, 12 Apr 2021 12:36:43 +0200
X-Mailer: MailMate (1.13.2r5673)
Message-ID: <E4374100-265E-4426-9F9A-AC437DA31D2B@depht.com>
In-Reply-To: <14cd802e-2a1b-97d4-c80d-b57f93e8cc21@mtcc.com>
References: <3b25c77d-e721-e86d-6c34-a90039aab0e2@mtcc.com> <CAMm+Lwhi8xwFgZJL7jod2g4urZt_f+dm0tNi+3y1osqOfch2mQ@mail.gmail.com> <3593a01f-73f4-7d03-a85b-dff64a8b070e@mtcc.com> <506A780B-9C0D-4F4A-B045-098F6152F4DB@akamai.com> <14cd802e-2a1b-97d4-c80d-b57f93e8cc21@mtcc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/uynWhCZfCNAWfS7zJaLMoL1T5dU>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Apr 2021 10:36:53 -0000


On 11 Apr 2021, at 20:13, Michael Thomas wrote:

> On 4/11/21 10:23 AM, Salz, Rich wrote:
>>
>>   * I don't see why [DNS timeouts] it can't be long lived, but even
>>     normal TTL's would get amortized over a lot of connections. Right
>>     now with certs it is a 5 message affair which cannot get better.
>>     But that is why one of $BROWSERVENDORS doing an experiment would
>>     be helpful.
>>
>> There are use-cases where a five-second DNS TTL is important.  And 
>> they’re not amortized over multiple connections from **one** user, 
>> but rather affect **many** users.  Imagine an e-commerce site 
>> connected to two CDN’s who needs to switch.
>>
> The worst case is that it devolves into what we already have: 5 
> messages assuming NS records are cached normally.
>
> Another approach using current infrastructure would be for the client 
> to cache the certs and hand the server cert the fingerprint(s) in the 
> ClientHello and the server sends down the chosen cert's fingerprint 
> instead of the cert which could get it back to 3 messages too. That 
> would require hacking on TLS though (assuming that somebody hasn't 
> already thought of this). That has the upside is that it's the server 
> chooses whether it wants to use the cached version or not too.

For the past 2 years or so I’ve been performing HTTPS DANE validation 
on all TLS 1.1 and 1.2 connections egressing my house. I use custom code 
written for OpenWRT that installs ACLs to block TLS connections that 
fail DANE validation.

More info here.
<https://www.middlebox-dane.org/>

The short story is that it works pretty well. I usually forget I have it 
running, and on the off chance I hit a website with invalid TLSA RRs 
that gets blocked it usually takes me a few minutes to try and figure 
out why the website isn’t loading.

One thing I’ve learned from this experiment is that, atleast in my 
situation, DNS is always faster than any TLS setup time that matters. 
The web is horrendously slow, so even if TLS setup completes my OpenWRT 
box will kill the TLS connection long before any real data gets 
transferred. These things happen asynchronously, and I have Unbound 
running directly on the OpenWRT box, so DNS always wins. But even if the 
TLS handshake were to complete fully and only then get killed by OpenWRT 
it would be the same outcome.

When looking at how one might implement DANE for HTTPS/TLS I don’t see 
any reason to handle these things sequentially. You don’t have to 
change TLS you just have to do things asynchronously. Query for TLSA RRs 
at the same time as sending the TLS ClientHello, and kill the connection 
setup when/if DANE validation fails. On the off chance that the DNS 
actually takes longer than TLS, maybe delay sending data via TLS until 
DNS responds. But I bet this almost never happens.

If you really don’t want any slow down from DANE just setup TLS 
normally and only kill it once DANE validation fails. The web is so slow 
that the chances something significant will happen prior to the client 
fetching the TLSA RR and performing DANE validation are practically nil.

Thanks,
Andrew