IETF Logo Mail Archive

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

"Yngve N. Pettersen" <yngve@spec-work.net> Mon, 02 May 2016 21:31 UTC

Return-Path: <yngve@spec-work.net>
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 ED8F012D643 for <tls@ietfa.amsl.com>; Mon, 2 May 2016 14:31:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 NH-KWVEvMBKO for <tls@ietfa.amsl.com>; Mon, 2 May 2016 14:31:10 -0700 (PDT)
Received: from smtp.domeneshop.no (smtp.domeneshop.no [IPv6:2a01:5b40:0:3005::1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 371D812D59D for <tls@ietf.org>; Mon, 2 May 2016 14:31:10 -0700 (PDT)
Received: from 137.71.202.84.customer.cdi.no ([84.202.71.137]:55979 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <yngve@spec-work.net>) id 1axLQq-00072Q-Ij; Mon, 02 May 2016 23:31:08 +0200
Content-Type: text/plain; charset="iso-8859-15"; format="flowed"; delsp="yes"
To: Eric Rescorla <ekr@rtfm.com>
References: <CABcZeBOBTe7juB1Ni=wkT3RJT8YJoy9KyGe5pbCaZFAL2JmmLw@mail.gmail.com> <op.ygusulhp3dfyax@killashandra.invalid.invalid> <CABcZeBM2-JOBsezLDa0pGr1ukz8sH4ktnooG=ztUUF0giWpcBQ@mail.gmail.com>
Date: Mon, 02 May 2016 23:30:42 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Yngve N. Pettersen" <yngve@spec-work.net>
Message-ID: <op.ygut1gwz3dfyax@killashandra.invalid.invalid>
In-Reply-To: <CABcZeBM2-JOBsezLDa0pGr1ukz8sH4ktnooG=ztUUF0giWpcBQ@mail.gmail.com>
User-Agent: Opera Mail/12.17 (Win32)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/V4aNiEoZIHSOFtNKM-E1RGmdUfA>
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:31:12 -0000

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.

-- 
Sincerely,
Yngve N. Pettersen

v2.23.0 | Report a Bug | By Email