IETF Logo Mail Archive

Re: [TLS] PR#448: CertificateStatus to extension

Watson Ladd <watsonbladd@gmail.com> Mon, 02 May 2016 21:45 UTC

Return-Path: <watsonbladd@gmail.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 1164A12D523 for <tls@ietfa.amsl.com>; Mon, 2 May 2016 14:45:45 -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 mu29UHs1kY5O for <tls@ietfa.amsl.com>; Mon, 2 May 2016 14:45:43 -0700 (PDT)
Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::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 0878812D126 for <tls@ietf.org>; Mon, 2 May 2016 14:45:43 -0700 (PDT)
Received: by mail-vk0-x22b.google.com with SMTP id b189so1748788vkh.2 for <tls@ietf.org>; Mon, 02 May 2016 14:45:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=lzWIZuUaARcC+MoWnfMll1P31tOGQpG80haHi5/SI0w=; b=Z1UwrMrPDD9kcepbT04Z4J/ACeynQwp6TJpO+f50W4scbymDNgJqiV47n802w+SfjW IZs36YcdkONt58MRNktnpLPVRIXqqjgvyMgYAdX7WVEtZasJijQkOrh+CXoXp4viXkbl qIzDr0skYVsCl3tCKj+gSyjXp/6DpdMo4PVFn9amIsf5xrxm7DT4MSdvBotuRBqlm+i6 YRowpaohbMyxtp6kAEdD4dlLwBFal1SNdqjLv5cSCpT7Z/pot/NhqKpR53lFClXL8bpf yF0jNG66pDf2yybVg3hXRb+SGlUgliR+XBMgHzh3oJaFnukZ/ltMTGxFVmbg9sp9bHDM sUCQ==
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:date :message-id:subject:from:to:cc; bh=lzWIZuUaARcC+MoWnfMll1P31tOGQpG80haHi5/SI0w=; b=jq9nl7gwHHyMA/6fi83HFAI3sDMvIAdwoc+POGNsNZ/vkj8cBzgFAMUeOwKkuCJNf9 jqBgWHXSYsuNHUYtaDZVBiGpx/9FBFpM68kCkP3wo/8fhNV/xV/la7B6VwG+U7CwCVYk BVn5zJqxschtj7ObGx+nNyl/K85NMH40NCBH1gmzGVRQGSP4esWLSaDTSjOVMHVr9MUJ CDrKUt0GunufkNjn77srTIimnK3OWL2JJnPJZ2kKN1tpMpDJuFcrFmv95Jv1awK6Wn08 C97CC7YdOZ83w9d6zhH5PKYM10LKOErT5tYIsKXO2LxVk31ljz2SO49mpXYZ2A6+JGBw L4Qg==
X-Gm-Message-State: AOPr4FXYjjPch4CTvS8y3TTQtK6GvI85xxPkH12RGEMJC7IQJ8wFv1hQ5vBP+7+qaOQvz+t6+Ck9w/SNxIJVAg==
MIME-Version: 1.0
X-Received: by 10.31.92.193 with SMTP id q184mr821485vkb.31.1462225542060; Mon, 02 May 2016 14:45:42 -0700 (PDT)
Received: by 10.176.64.68 with HTTP; Mon, 2 May 2016 14:45:41 -0700 (PDT)
In-Reply-To: <CABcZeBPeSL=u21wZ_e_f-S3sc3UXswBX6JKTwxvgpBkUyDmB6g@mail.gmail.com>
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>
Date: Mon, 02 May 2016 14:45:41 -0700
Message-ID: <CACsn0cmfUAaUsM1UTL3feerQ-R7yFxfpPjpOU19+_uYWXbke4Q@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/QpBQjTtu5fCeLxn507FSKKfoWNk>
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 21:45:45 -0000

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.

v2.23.0 | Report a Bug | By Email