Re: [Trans] Proposal to modularize pre certificate transformation

Peter Bowen <pzbowen@gmail.com> Tue, 28 March 2017 13:32 UTC

Return-Path: <pzbowen@gmail.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1493612953C for <trans@ietfa.amsl.com>; Tue, 28 Mar 2017 06:32:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 oRXpWA3GmTnu for <trans@ietfa.amsl.com>; Tue, 28 Mar 2017 06:32:23 -0700 (PDT)
Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 7DCE1129983 for <trans@ietf.org>; Tue, 28 Mar 2017 06:32:16 -0700 (PDT)
Received: by mail-oi0-x22b.google.com with SMTP id b187so5081392oif.0 for <trans@ietf.org>; Tue, 28 Mar 2017 06:32:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PUF7As7/E8v56QDGh2kzDsT5+EFFJ03n2OJlLFty4k8=; b=KWgj2AYBpw8GwWRqNnrpwxavLwHaDKLePKq1l4ODF/hcIOlRv8t+Q8l8rRDSQVx3Cq G3cx/sZTUQM3q0vNAjy745Jr6WgJ0gCVj8RL2pdBVmyJZIMlwdqDh6HguaV2JsrPyprL pGSbmA6egOQyZI9mVA+K4n8TWdoFYTANSP7tgnIB5Red/fNeRHzCMud+Q3JqxcS7fdti 0jZwAQ4btbuAKF1R2cDu0z3jF/dpN0xqeZ8AqrK7Hv3MFQQ7JCJ/CfjWYVLbw2Qq9gGr GFREgka2fPCm686lBo3KvuFKBW7OfgKfCDGQFvcLGsll+S2WXqJTHieH/M7l6mzm7hpx VE8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PUF7As7/E8v56QDGh2kzDsT5+EFFJ03n2OJlLFty4k8=; b=f4uFfjNkS7vs2UEzTEij4lTy8bPD7xl59ghoEmFezU0n1VX5HeJbe7xNY6Tvknz0Cw R62hyTltfLooTCbPjbCqz2avSqH0MYwqKVMMaBs5M3LMlMZ8zkApYTtBvVrQH4l4saOx Vy//ywarfb4gzN9922PdHzXd8jj2U2lgFFGGDt1nqkXW+4Qro7/MLawqFlDQ3jt7OnRs K3LGnFcZlQ23tKhWbHL0j9mzzKC6YqnqAa8JGAZPSMSkTa0yWPRO2HbGzKRoqZFUxaeb zn+CgSQfBmktEXxYdq9ntUcltduEqdPiDEM88ryhwLkel7Uu0Gmr6K3trzKi394yikbq YxUw==
X-Gm-Message-State: AFeK/H1+prsIW1l3X+VApdgo6XYyL74TXk19eJ/3F58H1Ecw8VT9Xp7YBV1t1IHOGaUThLewyY89r6IPHzGBgg==
X-Received: by 10.202.239.2 with SMTP id n2mr15396273oih.22.1490707935418; Tue, 28 Mar 2017 06:32:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.14.6 with HTTP; Tue, 28 Mar 2017 06:32:11 -0700 (PDT)
In-Reply-To: <20170327153907.435444debbebff6d9a08f95b@andrewayer.name>
References: <D4F8495D.4F2D%tarah_wheeler@symantec.com> <20170327153907.435444debbebff6d9a08f95b@andrewayer.name>
From: Peter Bowen <pzbowen@gmail.com>
Date: Tue, 28 Mar 2017 06:32:11 -0700
Message-ID: <CAK6vND8quW3H0=vkUCSt7Y2uWmYcypOTtwPCpiEzfsx8UvbR-g@mail.gmail.com>
To: Andrew Ayer <agwa@andrewayer.name>
Cc: Tarah Wheeler <Tarah_Wheeler@symantec.com>, "trans@ietf.org" <trans@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/lvaTCVJDC-pxn9MTpVM_Hf3ARPM>
Subject: Re: [Trans] Proposal to modularize pre certificate transformation
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Mar 2017 13:32:25 -0000

On Mon, Mar 27, 2017 at 3:39 PM, Andrew Ayer <agwa@andrewayer.name> wrote:
> On Wed, 22 Mar 2017 19:31:43 +0000
> Tarah Wheeler <Tarah_Wheeler@symantec.com> wrote:
>
>> Peter Bowen and I have been collaborating on a possible solution for
>> certificate privacy. Thoughts?
>>
> Your proposal is very similar to the original redaction mechanism
> that existed in draft-ietf-trans-rfc6962-bis-16, the main differences
> being your proposal also supports IP address redaction and solves the
> multiple-certs-per-precert problem.
>
> Like the original redaction mechanism, your proposal imposes a high
> complexity cost on TLS clients by forcing them to do a lot of decoding
> and re-encoding of a certificate in order to reconstruct the
> pre-certificate. This problem was discussed here:
>
>         https://mailarchive.ietf.org/arch/msg/trans/WU_XveDh0GmyyiQbmqEr1SVuC84
>         https://mailarchive.ietf.org/arch/msg/trans/eOHPqmAskBXMrGzSJAFzT9dzwOQ
>
> It led to the solution in draft-ietf-trans-rfc6962-bis-17 (now in
> draft-strad-trans-redaction-00), described here:
>
>         https://mailarchive.ietf.org/arch/msg/trans/gGWZhqCXG0wlkktB_d0a2fPM4VU
>
> I think that any new redaction proposal should address the problem of
> client complexity at least as well as draft-strad-trans-redaction-00
> does.

Andrew,

Thank you for the feedback.  I take full responsibility for the
failure to make the tech spec as friendly to clients as the
strad-trans-redaction draft.
When I was drafting this proposal, I ended up covering two related but
distinct issues, which I think muddies the water.

First, I think it would be good to have an explicit precertificate
transformation algorithm called out.  6962 and 6962bis both have
algorithms discussed in the text for how to go from a final
certificate to a precertificate.  The two algorithms are slightly
different.  From an implementer's perspective, I would prefer to have
a clear statement of that algorithm being used which then also allows
for clear introduction of new algorithms, instead of relying upon
hints such as the presence of a new extension.

Second is a proposal for an algorithm for precertificate
transformation that occludes discovery of full SANs from
precertificates.  This proposal needs a few tweaks to hit the points
covered in the discussions above and strad-trans-redaction draft; I'll
work on revising it to address these.

Thanks,
Peter