Re: Quic: the elephant in the room

Michael Thomas <mike@mtcc.com> Sun, 11 April 2021 20:13 UTC

Return-Path: <mike@fresheez.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 CF9FA3A1D66 for <ietf@ietfa.amsl.com>; Sun, 11 Apr 2021 13:13:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc.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 ZUq1vW0tpN3U for <ietf@ietfa.amsl.com>; Sun, 11 Apr 2021 13:13:15 -0700 (PDT)
Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 1DA2A3A1CB2 for <ietf@ietf.org>; Sun, 11 Apr 2021 13:13:08 -0700 (PDT)
Received: by mail-pf1-x42b.google.com with SMTP id l123so7795223pfl.8 for <ietf@ietf.org>; Sun, 11 Apr 2021 13:13:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=gOoxlQnjNbjV6fzE3wo4DkksW8vrmNdRnLqW5Fi4HEI=; b=frmhXhbzfa0ZRrXLnINvjo3T9g0LTnw2vKuKI6MTEbUlZPci75bRBgonuXi9ZbglyL 85VjG0QDofMBzoiUGjDPLa3JSpj5jOnYupN2C36B95gSOJyFdI5rV9+gP7i34PsxccxU FJMIKj9BCuxFWRX3miYZyx+PmeCD0OuaUCcTUosAKUwVFkRgV5AKadSgctb5MeBr2IJT /btGbKQI/PO0f3jhLVjXFNDQQi25Gi4oOUJWHaEWpwHD8Eg4vWhEQUIMCX0PBLJ2qLfZ WnMJSKZq5Qb/aNSTinw1vvDFMR3TSGkLsfQo2g4yMz8s3KUfeaweHN+sQsYYZsVgzduP 4g/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=gOoxlQnjNbjV6fzE3wo4DkksW8vrmNdRnLqW5Fi4HEI=; b=RfH/61LpEWA6NbmE7Wwc7k93YdKYFbSwYY5sUjd2oqFYCWSr/f+6emJjVNS6mtBhoT 3h2LeM3MrnPFbzQgH5s5vn/ypl21cdKaPCbkhD/ZjlEOyMWP+VzXxP+3Kqv5bcu+z9Ec AvznSA7c23zZnsac24GqaTIX+OUYFcQwbB/oUONpr9QsGJHXnorKk2VSwdrsHkQR21aZ qg/ny7QVzZSr9dBx4600I/FopYDROp0Wg1te7Qfliy20dtBZ8OpjOPJohPfxecTun7Ke vYrcoARZujx8MKDZVg793bTJEcV7HwM7N1R93Vs1Q+x8D4vbtLA8JZipQDs4zLBlNJXT V+0g==
X-Gm-Message-State: AOAM533TFZ0MU+YVuAkTR889KEUU/H7CE6adhFTbevV8K83qlV9Z/7DP VnuiDH+zGVRbZlqehMH85dUtfZ/k4zmktQ==
X-Google-Smtp-Source: ABdhPJw8GbPgHTp0wM4n3chdFwIa/YWxogdCT23e1oqBWt1SsxLKIxSId+aFIfW/YGG2rDEo0YYJCQ==
X-Received: by 2002:a05:6a00:c93:b029:20d:1b8e:cfaa with SMTP id a19-20020a056a000c93b029020d1b8ecfaamr21957410pfv.48.1618171987564; Sun, 11 Apr 2021 13:13:07 -0700 (PDT)
Received: from mike-mac.lan (107-182-38-56.volcanocom.com. [107.182.38.56]) by smtp.gmail.com with ESMTPSA id d26sm8109402pfo.162.2021.04.11.13.13.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 11 Apr 2021 13:13:07 -0700 (PDT)
Subject: Re: Quic: the elephant in the room
To: Phillip Hallam-Baker <phill@hallambaker.com>
Cc: "Salz, Rich" <rsalz@akamai.com>, IETF Discussion Mailing List <ietf@ietf.org>
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> <CAMm+Lwj-O3NMJ+zWbfOViUXE1PBPzOZ6E1iPfZ0uWAj+1Q=_-w@mail.gmail.com> <ade4b396-507b-c969-ff32-2b3291fc14fc@mtcc.com> <CAMm+Lwh6ZaR2aQ_j15q9FwdYHojuFxG_GscRQjGXdD_t4z_fqA@mail.gmail.com>
From: Michael Thomas <mike@mtcc.com>
Message-ID: <ffd180f0-0359-9a84-9889-de395df3127a@mtcc.com>
Date: Sun, 11 Apr 2021 13:13:05 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <CAMm+Lwh6ZaR2aQ_j15q9FwdYHojuFxG_GscRQjGXdD_t4z_fqA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------51B2299F8146A60CDD3839A2"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/kMJqaV1abWEdR2VKxq_mmvL6dTA>
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: Sun, 11 Apr 2021 20:13:24 -0000

On 4/11/21 12:56 PM, Phillip Hallam-Baker wrote:
>
>
> On Sun, Apr 11, 2021 at 3:34 PM Michael Thomas <mike@mtcc.com 
> <mailto:mike@mtcc.com>> wrote:
>
>
>     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.

Uh, Jim and I didn't use certificates in the design of IIM and neither 
did Mark with DK. Since the three of us were the basis of the combined 
protocol I think I have a little bit of insight into our thinking. So 
yes, we ignored the webpki guys including you. Thank goodness for that 
because a trip down that rat hole would have doomed it.


>
> 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.

We showed Jon our design before we released it as a sanity check. At no 
time did he say anything about certificate based approaches.


>
> 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.


The original IIM design used SRV records to find key servers. It's 
looking more and more that it was actually the right design. But Cisco 
was nobody with email so it was easier to go with flow of DK. I was the 
original one in our group to advocate that and I'm at peace with that.

>     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.
I have no idea how something that signs billions and billions of 
messages a day can be considered the "wrong model" whatever that means.
>
> 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.

TLS doesn't do anything to help the end-to-end authentication.

Mike