Re: [TLS] PR#448: CertificateStatus to extension
Eric Rescorla <ekr@rtfm.com> Mon, 02 May 2016 22:10 UTC
Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1531012D64A for <tls@ietfa.amsl.com>; Mon, 2 May 2016 15:10:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 riyLVQMDv21Q for <tls@ietfa.amsl.com>; Mon, 2 May 2016 15:10:12 -0700 (PDT)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::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 3175812D64C for <tls@ietf.org>; Mon, 2 May 2016 15:10:12 -0700 (PDT)
Received: by mail-yw0-x236.google.com with SMTP id g133so1941055ywb.2 for <tls@ietf.org>; Mon, 02 May 2016 15:10:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=H5yZTIkh9w1OeFO3M+DTtB3FPyokIatfu8FM1lOx2+k=; b=nTY2GVBAgdmn0AF1WPts2EOvfoDvxbNeMvKWplbjbM/XJ6/KzM6bLW+daMb2vjU2Jx sbNc7KIfzbIMMsrsnOdd9BunX/R6GhY3oqdWW8KZRDi6KVmshf3XNMMryvUnKWiWbFYv qwH/X2nluPPEavzhEe/X/MQKQfQooVK5BRm+l2xFBzcFf75GeRWJZ72pf4y6AjNtpy6Z 4dzPU+aMGqTI5CE0aQqjVVxobrc/PL7rFt+8og3SohNC/VXk3vADGPI24/n6E8eLzU/8 P0Hx1sOiEWW+64AB2wT7CYw2kIsA1h/INuZuSu1z6hFXDxq1YO4YB9rlNz6nsZ2Nez9J ULbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=H5yZTIkh9w1OeFO3M+DTtB3FPyokIatfu8FM1lOx2+k=; b=PcWT89zADUOSH/1kM63mUT0sBwMqHQoiMGffwbpBKq2nHVJMHULesD9Bik5aWMCOXf 1TLVbnH6VkpnWsKa/7x9hhlhQtoeV82ahZ3pZJnbg1nxw/J9RQ22t/LXWLlFCLSlCBaA OvBJFkUUOIwRARdZG3/fe5ZtGJQ4wk3VK19+g4rr8EmIa5JIRErqe0gXPboPTfWlLYAI 9TSJrSXjD2ZQxo+EBGBSEJRQK7RP5kzsY7pxqg1bml0Kcpd1vjxXChSMbXdEPaSh96Nj Gbk+hlLf4D0UQffOLjeVv9iScSEq2vYkYe5jT93DZrK866OhNofBskD3Wa4gBTbWnK/w g6Ww==
X-Gm-Message-State: AOPr4FX8+ds+sq8bA3J7rR5Qb1X2q4nNFXojq0Xzr32A6JTEW3uXREKHJjGvsgs/msQUmV0I37fa2sSIZ5qjVQ==
X-Received: by 10.129.46.193 with SMTP id u184mr19994700ywu.180.1462227011527; Mon, 02 May 2016 15:10:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.132.12 with HTTP; Mon, 2 May 2016 15:09:32 -0700 (PDT)
In-Reply-To: <op.yguvf1ka3dfyax@killashandra.invalid.invalid>
References: <CABcZeBOBTe7juB1Ni=wkT3RJT8YJoy9KyGe5pbCaZFAL2JmmLw@mail.gmail.com> <op.ygusulhp3dfyax@killashandra.invalid.invalid> <CABcZeBM2-JOBsezLDa0pGr1ukz8sH4ktnooG=ztUUF0giWpcBQ@mail.gmail.com> <op.ygut1gwz3dfyax@killashandra.invalid.invalid> <CABcZeBPeSL=u21wZ_e_f-S3sc3UXswBX6JKTwxvgpBkUyDmB6g@mail.gmail.com> <CACsn0cmfUAaUsM1UTL3feerQ-R7yFxfpPjpOU19+_uYWXbke4Q@mail.gmail.com> <CABcZeBNPykXFLqPxH90NoOwJ5Y+M2kBAT4avDVHx2A8V=Ez_7g@mail.gmail.com> <op.yguvf1ka3dfyax@killashandra.invalid.invalid>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 02 May 2016 15:09:32 -0700
Message-ID: <CABcZeBPQA89LnvZyR+eO8TbgbEPb31MzO1okF06E5dAFh7QpRw@mail.gmail.com>
To: "Yngve N. Pettersen" <yngve@spec-work.net>
Content-Type: multipart/alternative; boundary="001a11408a1c9a99290531e34179"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/wn3xJyfhDUJejwP2mat_VM0FL4U>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] PR#448: CertificateStatus to extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 May 2016 22:10:14 -0000
On Mon, May 2, 2016 at 3:01 PM, Yngve N. Pettersen <yngve@spec-work.net> wrote: > On Mon, 02 May 2016 23:54:32 +0200, Eric Rescorla <ekr@rtfm.com> wrote: > > Sorry, I'm responding to Yngve's "MUST" suggestion. >> >> I think what would be reasonable would be: >> >> - clients MAY send either {(v1,v2), (v2), or ()} >> - servers MUST send either {(v2 ) or ()} and MUST only send (v2) if the >> client sent {(v1,v2), (v2)} >> > > Which is what I suggested; note that I said "clients that support > certificate status", with "support" meaning "enabled". My mistake for misreading you. Sounds like we're on the same page. I'll modify as you suggest. -Ekr > > That I could live with... >> -Ekr >> >> >> On Mon, May 2, 2016 at 2:45 PM, Watson Ladd <watsonbladd@gmail.com> >> wrote: >> >> On Mon, May 2, 2016 at 2:40 PM, Eric Rescorla <ekr@rtfm.com> wrote: >>> > >>> > >>> > On Mon, May 2, 2016 at 2:30 PM, Yngve N. Pettersen < >>> yngve@spec-work.net> >>> > wrote: >>> >> >>> >> On Mon, 02 May 2016 23:11:29 +0200, Eric Rescorla <ekr@rtfm.com> >>> wrote: >>> >> >>> >>> On Mon, May 2, 2016 at 2:04 PM, Yngve N. Pettersen < >>> yngve@spec-work.net> >>> >>> wrote: >>> >>> >>> >>>> Hi, >>> >>>> >>> >>>> >>> >>>> On Mon, 02 May 2016 22:43:09 +0200, Eric Rescorla <ekr@rtfm.com> >>> wrote: >>> >>>> >>> >>>> PR: https://github.com/tlswg/tls13-spec/pull/448 >>> >>>>> >>> >>>>> Targe landing date: Wednesday >>> >>>>> >>> >>>>> In Buenos Aires we discussed moving CertificateStatus to part of >>> the >>> >>>>> Certificate message. In offline conversations, it started to look >>> like >>> >>>>> that >>> >>>>> wasn't optimal in part because it created an asymmetry wrt Signed >>> >>>>> Certificate Timestamps. Instead, I propose just carrying the >>> response >>> >>>>> in >>> >>>>> the response extensions. >>> >>>>> >>> >>>>> I just created PR#443, which moves the CertificateStatus response >>> to >>> an >>> >>>>> extension in EncryptedExtensions. Comments welcome. >>> >>>>> >>> >>>>> -Ekr >>> >>>>> >>> >>>> >>> >>>> Regarding Certificate Status, is it such a good idea to keep both >>> the >>> >>>> original extension and the newer status_request_v2 extension in TLS >>> 1.3? >>> >>>> The client may have to signal the original extension in order to be >>> >>>> interoperable with older TLS implementations, but wouldn't it be >>> best >>> if >>> >>>> TLS 1.3 mandated the v2 extension in the server response? >>> >>> >>> >>> >>> >>> >>> >>> I don't think it's a good idea to have the server responding with >>> >>> extensions >>> >>> that the client didn't offer. If we're going to prefer v2, I would >>> rather >>> >>> forbid >>> >>> the v1 version in TLS 1.3 >>> >> >>> >> >>> >> I was thinking along the lines of saying that TLS 1.3 clients that >>> support >>> >> certificate status MUST send v2, MAY send v1 (to be interoperable with >>> older >>> >> servers that tolerate a 1.3 Hello), and TLS 1.3 servers (in a TLS 1.3 >>> >> session) MUST respond with v2 and MUST NOT respond with v1. >>> > >>> > >>> > Well, what if the client doesn't want the OCSP response? >>> >>> Wouldn't the client then not send the certificate status extension, >>> which the proposed text seems to include as an option? Or am I missing >>> something? >>> >>> > >>> > -Ekr >>> > >>> >> >>> >> >>> >> -- >>> >> Sincerely, >>> >> Yngve N. Pettersen >>> > >>> > >>> > >>> > _______________________________________________ >>> > TLS mailing list >>> > TLS@ietf.org >>> > https://www.ietf.org/mailman/listinfo/tls >>> > >>> >>> >>> >>> -- >>> "Man is born free, but everywhere he is in chains". >>> --Rousseau. >>> >>> > > -- > Sincerely, > Yngve N. Pettersen >
- [TLS] PR#448: CertificateStatus to extension Eric Rescorla
- Re: [TLS] PR#448: CertificateStatus to extension Yngve N. Pettersen
- Re: [TLS] PR#448: CertificateStatus to extension Eric Rescorla
- Re: [TLS] PR#448: CertificateStatus to extension Yngve N. Pettersen
- Re: [TLS] PR#448: CertificateStatus to extension Eric Rescorla
- Re: [TLS] PR#448: CertificateStatus to extension Watson Ladd
- Re: [TLS] PR#448: CertificateStatus to extension Eric Rescorla
- Re: [TLS] PR#448: CertificateStatus to extension Yngve N. Pettersen
- Re: [TLS] PR#448: CertificateStatus to extension Eric Rescorla