Re: Quic: the elephant in the room

Viktor Dukhovni <ietf-dane@dukhovni.org> Sun, 11 April 2021 22:33 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 C7EF13A216F for <ietf@ietfa.amsl.com>; Sun, 11 Apr 2021 15:33:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 hSbG4_kfxdIY for <ietf@ietfa.amsl.com>; Sun, 11 Apr 2021 15:33:30 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E5663A216E for <ietf@ietf.org>; Sun, 11 Apr 2021 15:33:30 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 2B3DDB94CB; Sun, 11 Apr 2021 18:33:29 -0400 (EDT)
Date: Sun, 11 Apr 2021 18:33:29 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: ietf@ietf.org
Subject: Re: Quic: the elephant in the room
Message-ID: <YHN5ObR0eqea8Mrc@straasha.imrryr.org>
Reply-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> <ab6bcbf0-646c-9f2d-5f98-fdc3e9ba27bf@mtcc.com> <CABrd9STEqvgexYKTUdFqn1zu=U2+h92_aDS6rM=8xcwibNJM3A@mail.gmail.com> <YHMc54xe1Mnx2U2y@straasha.imrryr.org> <CABrd9SShpOnSpshnMZSag4ZVp6ic5tURFoH9RzT0WCXDHyxgkA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABrd9SShpOnSpshnMZSag4ZVp6ic5tURFoH9RzT0WCXDHyxgkA@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/rSMeHqb6qC-dvM_nulOHyeyc7Og>
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 22:33:34 -0000

On Sun, Apr 11, 2021 at 11:18:39PM +0100, Ben Laurie wrote:

> > But any compromise of a registrant, registrar or registry also
> > compromises CA certificate issuance.  The CAs are redundant so
> > long as the attestation they're performing is "domain control".
> 
> CT makes that untrue. Why is this not obvious?

Because:

    * CT is after the fact, plausibly too late.

    * As I mentioned before, CT is often impractical for
      typical domains != google.com.

      - They need to track the CT logs
      - They need to keep track of all legitimately issued certificates.
      - They need to detect unauthorised issuance quickly and have
        a mechanism in place to demand revocation.
      - Clients need to actually support CRLs, OCSP, ... 

      There's an awful lot of preconditions there for CT to actually be
      effective in practice.

> > > Also, DNS has the same plethora of authorities with varying
> > > security responsibility.
> >
> > Choose a security-conscious registrar, and apply registrar lock, and any
> > other available/applicable options to prevent unauthorised changes to
> > domain registration metadata.
> 
> Of course anyone can trivially figure this out. Not.

It certainly isn't a secret, has been discussed on many lists over the
years, but I don't know of a canonical place to find this advice.  We
could publicise this better, not sure whether an IETF BCP would be the
right mechanism.  Yes, you're unlikely to learn this from a discount
registrar competing only on price and not on quality/security of service.

-- 
    Viktor.