Re: [Acme] Onion address validation extension

Roland Shoemaker <roland@letsencrypt.org> Thu, 09 July 2020 16:51 UTC

Return-Path: <roland@letsencrypt.org>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81373A0CFE for <acme@ietfa.amsl.com>; Thu, 9 Jul 2020 09:51:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=letsencrypt.org
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 78M7oS8vPgR4 for <acme@ietfa.amsl.com>; Thu, 9 Jul 2020 09:51:31 -0700 (PDT)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 C0B7C3A0CFD for <acme@ietf.org>; Thu, 9 Jul 2020 09:51:30 -0700 (PDT)
Received: by mail-wm1-x335.google.com with SMTP id f18so2571753wml.3 for <acme@ietf.org>; Thu, 09 Jul 2020 09:51:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dGnGwhToTFw4YwHGm4yIlvNnr6Xv3kD6ukLcj8Cvkao=; b=GRvVxRqvwja0jbOOkkEs8/82LtreEarF0y+ijEakHon+iG5nJyi9tgbVm/gQ4C/3OR CiCjM1vgHcafov3STPzDw70MZoOxUn7pPrzrJCGjcmFr591FfDCw8HRyCU+s4IqnOI9G FUskS2Fps8I6ubazXHazPuFkV2Qg+REX0Vr6o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dGnGwhToTFw4YwHGm4yIlvNnr6Xv3kD6ukLcj8Cvkao=; b=jQ348VbQoDMACzHDA9Y7Z53unZIgaO4Mw6Esj3VCb3JfJKWPaoaGrUFxNlfx7WMz+N Ytm4//yDIE8gGKeeUTtlFApXI2iIm+arARq867IfBD80vpr2T/ExnAXlF8AyLxJ/6aLS c0H2aY97nLq2ZpklM73+1HgWV6lvLvNGZgp4y1bTeKKzFmiR6B0Y/HPszyIXlmMdnwPm MN/DI1ZxRstrC3QBz8dtJhCNlNSyvu1XjXjHsOkKMl3ReWrxaDMDE/hCIaL1zMYZcB7q HHpdaaziOKXqBkxrkDhzhrQO4QI4UEuHSCu10t+ugy5TxtPmqx6EQc+4jTmlIatj95NU 2UGA==
X-Gm-Message-State: AOAM531xQ0UiaezvN+hqbCPubdRjcEkpkZOMliR056s6XM8bIPLVF9PS lWTCmuQpfjwDMAjaWUomCCwtT+HyZIYFyWeQTIQaBQ==
X-Google-Smtp-Source: ABdhPJwfiLj5wc0UHvIQlwNjWrB74J6Ef2j94mjpFJuWwwpHhxBkEsLGPwJR+tny8f2nfOSMWp2xtLsFh94fKY3T3Sg=
X-Received: by 2002:a1c:c904:: with SMTP id f4mr884711wmb.69.1594313489191; Thu, 09 Jul 2020 09:51:29 -0700 (PDT)
MIME-Version: 1.0
References: <CAF1ySfGWY3e=mdn0seJjy5M6jBmtZBMzkm1knvF-BF+hmxCBTA@mail.gmail.com> <002001d65552$1cd504d0$567f0e70$@sebbe.eu> <20200709123015.GA214719@LK-Perkele-VII> <006301d65608$d22956e0$767c04a0$@sebbe.eu>
In-Reply-To: <006301d65608$d22956e0$767c04a0$@sebbe.eu>
From: Roland Shoemaker <roland@letsencrypt.org>
Date: Thu, 9 Jul 2020 09:51:18 -0700
Message-ID: <CAF1ySfHP8BgTB_J9-tBn8prqGPtKJOL2Caj0raGDuOyAto6j8A@mail.gmail.com>
To: Sebastian Nielsen <sebastian=40sebbe.eu@dmarc.ietf.org>
Cc: Mailing List <acme@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002f281505aa050975"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/MuGsJl_NlmMbXT4LeonST7oVGoA>
Subject: Re: [Acme] Onion address validation extension
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jul 2020 16:51:33 -0000

I would be extremely uncomfortable specifying a mechanism like this. It
would be a large divergence from the existing ACME specification, and would
create significant traps for implementers to fall into. Specifically this
would break assumptions in most existing implementations, principally that
an order with valid authorizations can cause an issuance without further
validation. I'm also not sure how this would gel with implementations that
implement authorization reuse. It feels like this would create numerous
opportunities for an implementer to accidentally allow issuance without
actually doing any validation at all, for seemingly little real world
benefit (presumably this would only really save one or two additional
request roundtrips).

I think this is an example of one of the problems with the existing CABF
method of using a CSR as the data/signature transport when something else
would be more appropriate. The validation mechanism and the issuance
request mechanism should be as decoupled as possible to avoid people trying
to stick bits of either in the wrong place.

On Thu, Jul 9, 2020 at 8:51 AM Sebastian Nielsen <sebastian=
40sebbe.eu@dmarc.ietf.org> wrote:

>
> >>ACME protocol is not meant to proceed to CSR sending until after all
>   names are validated. Breaking that would cause implementation
>   problems.
>
> Thats why there should be 2 validation types, so a client who support the
> new "skip ahead" validation type would know that it only needs to request
> onion-2 validation type, then it would immidiately skip ahead to CSR
> sending without checking if validation passed - since validation then
> occurs at CSR stage.
>
> The reason validation is required inside ACME is because ACME (usually)
> needs to contact external resources to confirm your validations, which
> incurs a delay. If you can prove the ownership of the domain inside the
> actual validation response (ergo a self-validating response that can be
> verified "offline") theres no need to use the full blown ACME
> infrastructure, then you could just submit the response inside the final
> CSR.
>
> Of course this wouldn't work for multiple domains, why the normal
> procedure with checking for validationa (onion-1) would be required.
>
> >>The CSRs are assumed to be self-signed, which is a problem here:
>
> Thats not a problem.
> What I proposed, is that you create a CSR over the normal TLS certificate
> (with its signature belongning the TLS certificate's key) BUT you put your
> onion signature (a signature of the nonce made with the onion private key)
> inside the CSR field called "CSR Challenge Password".
>
> So basically, you create a TOR signature with the TOR key, insert it in
> your final TLS CSR (as CSR Challenge Password), and then sign the TLS CSR
> with the TLS key.
>
> Meaning, that the CSR *are* self-signed, and that they CONTAIN the TOR
> signature made with the TOR private key, making the CSR being dual-use -
> both validating the onion name AND also becomes the grounds for your
> certificate generation.
>
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>