Re: Quic: the elephant in the room

Michael Thomas <mike@mtcc.com> Sat, 10 April 2021 19:59 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 6A7B13A1980 for <ietf@ietfa.amsl.com>; Sat, 10 Apr 2021 12:59:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.751
X-Spam-Level:
X-Spam-Status: No, score=-1.751 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 0QWlPpu3VleT for <ietf@ietfa.amsl.com>; Sat, 10 Apr 2021 12:59:38 -0700 (PDT)
Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 531453A197E for <ietf@ietf.org>; Sat, 10 Apr 2021 12:59:37 -0700 (PDT)
Received: by mail-pl1-x62e.google.com with SMTP id e2so25864plh.8 for <ietf@ietf.org>; Sat, 10 Apr 2021 12:59:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=9THvbdMjOEeSVsH8m/S854A5Ll66nAv8ldhYwbVpqfY=; b=Z/8ivJfwGfmUZjQy3wLBqiTmDB/V8XVq4qC0oHRsuYi6Tmh6ehSjuGODA55pY2gXi8 ai3en2cbTvTFI+If4qUMh8MB5AzyGPn8c8Qyp/lqyGk5fKFxPNht+gqfSUmzal4hh3OS z9G9n1w6aqnhqLSPclTjgfRz5bGrXVUen8MTdfv9NLB6uGlzSuAafTsdQZDa1WEbxASs oBW1a8Jvk6DXIgCm9vlh6L7XvkM3mEwICtdNyrzZJG8j22ztaRPtDszA3KYnn3g3fTv4 6tbAKp8WIjJXDOYY4aUeDtwcouqE5rZ/0d0/EIyYkpbnp9o0U6IfvkCDNkQZ4dLdsXul eapA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=9THvbdMjOEeSVsH8m/S854A5Ll66nAv8ldhYwbVpqfY=; b=GQurgehCG/fq5Q8jxz+geJ/DNjKS0mUqHJmKnXPBI1TwPjISpO6kczp8YwOEEGvTry YcpMmqJHSJYlDSKav9hpHbTx7U/9ZUQlcveNnpndBb5FTuNZOTt/rJiLc8cR80JIny/I KeOm4M72zcxqWZ2/v4a7yNEgvcOnfTAoN6nJD6XFPIYc35geYfpEaOVI4tQzOd9Rbyql KJaUcggyXfjXE1TdR0JF4RMGun0E8Jrp46I94Uk7L4pbG9/pREgl7WINa7Z97zJKFdBW 7/ZY0zlqmDGs8KtJg84b3HIkyC2VJrxoZ3L2Fn1n7yyOkp3D2hcx/i2PQyCrxI4+jsJ/ fkmQ==
X-Gm-Message-State: AOAM531M7o0l5zqLyFbP1+fRZoCwM9XRa9Bzp2yvipQ70V4/+Vnw2VOy pkRJCYEtjFK3tC9LJT49kBds3VnuzMVeTQ==
X-Google-Smtp-Source: ABdhPJyuvmElD9XeE7paSyhP76rorXqaFtd4aMbsMvqm25aeRJrgTPBRF23RN8jfxWJqy1Xn12GxvQ==
X-Received: by 2002:a17:90b:1946:: with SMTP id nk6mr17902210pjb.61.1618084776158; Sat, 10 Apr 2021 12:59:36 -0700 (PDT)
Received: from mike-mac.lan (107-182-38-56.volcanocom.com. [107.182.38.56]) by smtp.gmail.com with ESMTPSA id q2sm5195344pfk.143.2021.04.10.12.59.35 for <ietf@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 10 Apr 2021 12:59:35 -0700 (PDT)
Subject: Re: Quic: the elephant in the room
To: 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> <CABrd9STZXonBDvWB7Z36H2mD20Juubc01TUmEvpfWkvJggQVOQ@mail.gmail.com> <20210410175712.GF9612@localhost> <926C5F27-E011-4809-88DB-DBC9A8976D01@dukhovni.org> <20210410195048.GG9612@localhost>
From: Michael Thomas <mike@mtcc.com>
Message-ID: <bfdceabb-143b-a0ab-3041-05888e8f39f2@mtcc.com>
Date: Sat, 10 Apr 2021 12:59:34 -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: <20210410195048.GG9612@localhost>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/DK6VKgg7IpNe3X1mrln2X4EvMkI>
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: Sat, 10 Apr 2021 19:59:44 -0000

On 4/10/21 12:50 PM, Nico Williams wrote:
> On Sat, Apr 10, 2021 at 02:08:30PM -0400, Viktor Dukhovni wrote:
>> Ben's claim that CAs are "more secure" than DNSSEC is demonstrably
>> in error in a world where all that CAs do is issue DV certs that
>> attest to "domain control".
>>
>> If you don't trust the ICANN root, you can't trust DV certs, since
>> all they do is memoise some DNS-derived data you don't trust.  Indeed
>> it takes DNSSEC (and CAs honouring DNSSEC-signed CAA records) to somewhat
>> improve the rather weak assurance that DV provides.
>>
>> Perhaps CT adequately hardens this model for Google's domains, if
>> they're sufficiently vigilant to detect unauthorised certificate
>> issuance (after the fact), but for the rest of us, tracking the
>> CT logs is not actually practical.
> Indeed, CT works only if people bother to do enough log checking to
> increase the risk -real and perceived- to malefactors with access to CA
> credentials.  CT can fail to get there generally, leaving us with the
> same old name-constraint-less, multi-root WebPKI.
>
> CT is not the answer, and it's not even an answer.  CT might help, and
> it's better than nothing, but it's certainly not better than also
> addressing the other issues, and it's not better than only addressing
> the other issues either.
>
> If QUIC were to depend on DANE, the result would be a shot in the arm to
> DNSSEC deployment, which would instantly address the two biggest
> problems with WebPKI.
>
Yeah, I was trying to verify whether google, amazon and facebook sign 
but it appears not? my dig fu is admittedly bad so I might be full of it 
(hopefully).

Let me ask a pointed question: if we used DANE+DNSSec do we have 
confidence in the security of the solution? I think we'd have to have a 
lot of confidence in both that they are really ready for prime time.

Again, this yet another reason why an experiment would be extremely 
instructive because they could limit the scope to steer out of 
ecommerce, etc, until the results are in.

Mike