Re: Quic: the elephant in the room

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6E5053A1BAE for <>; Sun, 11 Apr 2021 12:56:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Status: No, score=-1.399 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_NONE=-0.0001, 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 gLAn8pPN32kO for <>; Sun, 11 Apr 2021 12:56:26 -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 7CCD33A1BAB for <>; Sun, 11 Apr 2021 12:56:26 -0700 (PDT)
Received: by with SMTP id l9so12745264ybm.0 for <>; Sun, 11 Apr 2021 12:56:26 -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=s9D01GW9FTdJ/dzRyBgefghhaL/wz2/wTULXO46p3L0=; b=idhGqsgCfoQSR1n7JLY3Ka7xOJSeWpayAxnvYGzlYKKLof5ZwMzpPnCbHvakUeIA6A VSgVHArw0ZTckzH703uGyJZcP3BzxD50IHVJ0acVj72DxcWDrjFiOiyGX9o7LchvIyPw 86cweQK7AYULpw6ljFIVQso3gAorywwy33XAlTEKSwqUj22pF4UpEmZsVTqLBerx3M74 ibAhQDxrvQQkodaMQlk3oXlknXB9m0LYJYki2xW5NNs9WWThubO+MRbp/t0HrH7Cszjf wjH2ZIV+3MJvaB66E7jpa2Jth65SKQrcUajKu0km/2Rp4c9swxjUdVoWP5FHm1TWhf5l YrSw==
X-Gm-Message-State: AOAM531z0Eb3Q8knfRPvko/AmiQCZnjCYgXPyXMazSiS4d3w9UyaJ3Pk BPvnpjT5A464RHd6eiWudPV08OELnlL/EabEGaU=
X-Google-Smtp-Source: ABdhPJyTi/QH8TMXU1vtMCXUHth5taD6OOgCrpHczj1YHa3A74JOFMQJrmtWiZYxQI6lCvdwabU5tz+L/99zylSrPLE=
X-Received: by 2002:a5b:585:: with SMTP id l5mr32195030ybp.213.1618170985321; Sun, 11 Apr 2021 12:56:25 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Phillip Hallam-Baker <>
Date: Sun, 11 Apr 2021 15:56:14 -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="000000000000c4183e05bfb7ca4b"
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:56:30 -0000

On Sun, Apr 11, 2021 at 3:34 PM Michael Thomas <> wrote:

> On 4/11/21 12:11 PM, Phillip Hallam-Baker wrote:
> 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.
> We already have a widely adopted example where we ignored the webpki folks
> too: DKIM.
That is completely false. I was a member of the DKIM working group and its
predecessors. Two years before the DKIM WG was started, I designed a DNS
based key credentialing scheme together with a major technology vendor.
This was demonstrated to Yahoo by my CEO, Stratton Sclavos before the date
of the Yahoo patent claim.

The history here is that about a year earlier, I had had discussions with
Jon Callas, then CTO of PGP to see if we could persuade the market to move
beyond the S/MIME vs PGP format war. The thing that ultimately prevented
that work getting off the ground was not DKIM itself but the spam crisis
that had prompted it. It was clearly not time to propose a second,
different scheme. Some of the proposals I made in that group were intended
to keep the door open to progress towards an encryption solution.

I attended every plenary and interim meeting of DKIM and was in constant
contact with my peers in the wider industry.

> Certs are simply not needed in the vast majority of cases. DKIM could be
> adapted for this too, and doesn't have the downside of a new RR type which
> is always problematic. I assume that the people doing DANE were looking at
> DKIM's success as a template. Quite reasonably, IMO.
DANE works in a very different way and its cardinal sin is to mix
publication of security policy with publication of keys.

> And I don't know how something that could reduce the message count to the
> original 3 way handshake is somehow the "wrong model". In what way? Is DKIM
> the wrong model too?
DKIM is very definitely the wrong model and we knew that when we wrote the
spec. DKIM is simply the best model that was possible within the time frame
and with the vast and ugly legacy of SMTP deployment. It would have been
even uglier if not for SPF giving us some breathing room.

Given where we are now with all SMTP using STARTTLS, I would probably look
to implement TLS client auth instead which would allow fast restart to
amortize the public key operations. But thats not where we were then.