Re: [lamps] [saag] Proposal for OCSP over DNS
Phillip Hallam-Baker <phill@hallambaker.com> Fri, 27 October 2017 12:16 UTC
Return-Path: <hallam@gmail.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD93713B13E; Fri, 27 Oct 2017 05:16:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level:
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 UYXRqJSfWO92; Fri, 27 Oct 2017 05:16:46 -0700 (PDT)
Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 CF253138BD8; Fri, 27 Oct 2017 05:16:46 -0700 (PDT)
Received: by mail-oi0-x236.google.com with SMTP id j126so10544494oib.8; Fri, 27 Oct 2017 05:16:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Yc0YEwQg9Ae/vBs3D1SCwAE5yYQ0JqzP5ERo9QcvGm0=; b=OMHQdhH0hFTZ4DYGu5qXIc/Bp/GuE7LO/AxVGyqMbyIp1VUQXrKMV2i+UJoInxqs8I KM2/62pVi/haQ9sYDH7f+IJm0H4jeqKgzX8MZtYFQbG/7JWyHEtvJiDIJ8u5mG2Dg9lv xxrfWxTEgXcOI1Q0ESWbjbeXdLMQcbgpzowzdcfuFH7kc6QXR7brhCSlg9F9oN71/ucn LOIHKi1xPClDRXyNxNglmypRn7FsrfGM9zUwCE5Sdf/mlXTO8FVFiOg5T5D87LojR06M CAB8Mbw+attn/PFcK0Qjb/1HbdBwfCBeD3EmvOwuSvERJKNUVUAZ0GzBod1SWdxjlvLQ T/SA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Yc0YEwQg9Ae/vBs3D1SCwAE5yYQ0JqzP5ERo9QcvGm0=; b=q5ZuOabZSd4cT+GxKT9aU6Lbg93vw/1aAcLR6JUFNQZAPA65Y11CzTULDyIH5mmBds y+OBEl7emO5f/NIoplOmIE6e6MoltFChqN78c0sTdykF+fx6S2U16wQ84j5vVrb+ZZwF czXQVncwFqRTCyVIuRv6IhCVWzITHGfASbZ0UYEk29Bm1RD7vMSNQRaGs57XWrp2VF+V jHLaSWwtILt4Xmz3wJHu5LbJRu8MiAdycuVC8nptigEQxpud/FgjhywHBU/AqG4idNtI AHLJ7PV/3YdnXLtpgb7IQg3ztswPr7nCLe7T2W2ION4q0EMpKYkK/HM5nrKrk0X3YR6s rIfA==
X-Gm-Message-State: AMCzsaVe9iKr2GBxCs2d+xJ6hUSu7qtzuZEpTW/DvhnMscCq54DMaQD6 rIFm6ljV8eRLxf8Z108KGHl4ycIW7w8UP6Fmmpk=
X-Google-Smtp-Source: ABhQp+Smc5xV3bKf038wf3vDSsYZ3oxaF3JG85DIbyGnH+mB2QO1amOQwf1qWjYvKfEJGS+5Pr3zZvUVJfGbzgyK9/0=
X-Received: by 10.157.17.72 with SMTP id p8mr163963otp.305.1509106606078; Fri, 27 Oct 2017 05:16:46 -0700 (PDT)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by 10.157.80.42 with HTTP; Fri, 27 Oct 2017 05:16:45 -0700 (PDT)
In-Reply-To: <3D9CC81C-404A-48D0-9F45-14829FADC646@vpnc.org>
References: <10f5c653-e2b7-9332-02b0-5528e6693582@openca.org> <3D9CC81C-404A-48D0-9F45-14829FADC646@vpnc.org>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Fri, 27 Oct 2017 08:16:45 -0400
X-Google-Sender-Auth: VtwmmqA_KcMJ1rv_AjrzLhtJlxE
Message-ID: <CAMm+Lwj_BQcMxq9T-QveD6sbAbeyHb494DXqvRtkCZKCuq5JSA@mail.gmail.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Cc: "Dr. Pala" <director@openca.org>, "saag@ietf.org" <saag@ietf.org>, SPASM <SPASM@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/VCUqamprj5T7sNZ2R9wx-V_IIIA>
Subject: Re: [lamps] [saag] Proposal for OCSP over DNS
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Oct 2017 12:16:49 -0000
On Mon, Oct 23, 2017 at 5:13 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote: > On 23 Oct 2017, at 13:54, Dr. Pala wrote: > >> we are currently working on specifying how to use DNS as a transport >> protocol for revocation information for X509 certificates. In particular, we >> are working on how to leverage the distributed nature of DNS to efficiently >> (and at lower operational costs) distribute OCSP responses to >> applications/devices/etc. >> >> We started this work sometime ago but never really had the time to finish >> it. Now it seems we can focus more on the topic and would like to discuss >> this work in a more public venue. >> >> We currently have two similar I-D submitted (that should probably be >> re-edited and merged): >> >> * https://datatracker.ietf.org/doc/draft-pala-odin/ >> * https://datatracker.ietf.org/doc/draft-pala-rea-ocsp-over-dns/ >> >> EKR suggested that this may be another topic for the SEC-DISPATCH meeting. >> Can we have 5-10 minutes for this @IETF100 ? > > > These sound like "we want HTTP over UDP to save latency, so we'll just > substitute DNS". That's certainly an option, but it hasn't been a popular > route in the IETF. Are the busy CAs asking for this? Is there a reason why > they can't just beef up their web infrastructure (like their customers are)? Since QUIC is 'TCP++ over UDP' and flavor of the month, OCSP over QUIC is probably a more viable route. The expiry of the Micali and Kocher efficient revocation patents mean that we now have options beyond OCSP which is what we are currently focused on at Comodo. I have proposed OCSP over DNS several times in the past. The problem I ran into was that the chief concern of the browser providers is latency. And some are unwilling to accept any proposal that increases latency in any way for the sake of public safety. Attempting to use DNS as transport is highly problematic. Many networks block unknown RRs for a start. It is hard enough to get DNSSEC to work right. That led me to an approach where the OCSP and DNS lookups were combined into one UDP transaction to a trusted discovery service combining DNS lookup, OCSP and certificate fetch, aka 'omnibroker'. That is an approach I will probably be revisiting in the near future.
- Re: [lamps] [saag] Proposal for OCSP over DNS Phillip Hallam-Baker
- Re: [lamps] [saag] Proposal for OCSP over DNS Dr. Pala