Re: Quic: the elephant in the room

Phillip Hallam-Baker <> Sun, 11 April 2021 19:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 25DC73A1A09 for <>; Sun, 11 Apr 2021 12:11:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Status: No, score=-1.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.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Djg8TXVphhlE for <>; Sun, 11 Apr 2021 12:11:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BE7A23A1A07 for <>; Sun, 11 Apr 2021 12:11:29 -0700 (PDT)
Received: by with SMTP id k73so6309250ybf.3 for <>; Sun, 11 Apr 2021 12:11:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IwXuivy83OJ5z5jr2KD4tsQ9csWZihRAk33SZwUcKCg=; b=J+hFuJUjGJhxP6rG46x3OcDNATurMLaLQUfdlBNZQ2/cr8BYZ5GeLm9bJtz8LbUpV0 T8stB6TCsRc7D8NUCGVOinQZPEICx8xl+E2kbEfnRitBSTgWh8VPbCfmpK+KG4tZRkUB ZlzkXXh6Y/K/caxJgYu5q2F0mbaX1ncyZnfSMY9IVAFA46WKWeCYIlUMqwVxHioowVNq 18XNTMgwR/+fJplnFSHX8maQu/dV+/IGEigHh3BOiGT6EqiQFY2NfExYQJojKt4NRtLx er8zaD5ReEzQTv4FslM04dEZmCoxpXqeEv2nrF107GoW0ArP17e6BwHbol0A8z1qwaD8 QSEg==
X-Gm-Message-State: AOAM531EUFdLt4yfboEgxa5Aa4wZcwocpaRXd0I/AUNGLKrG1C0FWLX/ dudj4tOIavAYzk6g3tYK29hH5V4+Z8nK1DKXOzQ=
X-Google-Smtp-Source: ABdhPJz7AnXCIEv1O9EbByHa3lcePxBio/3r00DZBqSo7rirKoRTNSnzZnA+e4/1LeWPYRdkHa0JOcPtBAaNJe2iavk=
X-Received: by 2002:a5b:585:: with SMTP id l5mr32018785ybp.213.1618168288539; Sun, 11 Apr 2021 12:11:28 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Phillip Hallam-Baker <>
Date: Sun, 11 Apr 2021 15:11:17 -0400
Message-ID: <>
Subject: Re: Quic: the elephant in the room
To: Michael Thomas <>
Cc: "Salz, Rich" <>, IETF Discussion Mailing List <>
Content-Type: multipart/alternative; boundary="00000000000006786605bfb72aab"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 11 Apr 2021 19:11:34 -0000

I made essentially the same argument to people at Google BEFORE the DANE
group was ever proposed. The answer they gave me then has not changed.

DANE was chartered over a decade ago. Individuals in that group made clear
that no input was going to be accepted from anyone who was a part of the
WebPKI world. The tactics used were intentionally exclusionary. Those of us
pointing out the limitations of the proposed approach were never given a
fair hearing.

It is now ten years since DANE was chartered. DANE has failed beyond the
very limited application to SMTP which was never really covered. The
argument for DANE was weak before LetsEncrypt was launched and it seems
highly unlikely future events are going to change that.

The TLSA model is simply the wrong model. If you want to change the way
discovery is done, you need to think about the full discovery chain. And
not least because DOH is another factor in this mix.

DANE and DPRIV should have all been a part of one effort that should have
included the introduction of SRV records for HTTP.

The key weakness in the DNS protocol is that the client-resolver
interaction is of an entirely different character to resolver-authoritative
and the current client-resolver interaction only supports requests for one
record at a time.

The kick off meeting for DPRIV was quite interesting. There should be
standing IESG instructions to prohibit chartering of any WG that is
premised on the need to finish something in a year, so it is essential that
it be done in exactly the way the proposers have already decided. Even more
so when the results from DPRIV could be easily foreseen from the fact it
was the same group that had hijacked DNS security policy with DANE.

I don't claim to always do the right thing but there are some folk who seem
to keep doing the same thing with the same outcome and for some reason they
get priority over folk who have actually built stuff that was successfully
deployed and is in use.

On Sun, Apr 11, 2021 at 2:14 PM 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.
> Mike