Re: [TLS] draft-ietf-tls-cached-info-14

Rob Stradling <rob.stradling@comodo.com> Wed, 10 April 2013 12:21 UTC

Return-Path: <rob.stradling@comodo.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 743BD21F9104 for <tls@ietfa.amsl.com>; Wed, 10 Apr 2013 05:21:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfT4ZzJfUxD1 for <tls@ietfa.amsl.com>; Wed, 10 Apr 2013 05:21:42 -0700 (PDT)
Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3BABB21F92F2 for <tls@ietf.org>; Wed, 10 Apr 2013 05:21:15 -0700 (PDT)
Received: (qmail 15386 invoked from network); 10 Apr 2013 12:21:13 -0000
Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 10 Apr 2013 12:21:13 -0000
Received: (qmail 1399 invoked by uid 1000); 10 Apr 2013 12:21:13 -0000
Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Wed, 10 Apr 2013 13:21:13 +0100
Message-ID: <51655939.3060001@comodo.com>
Date: Wed, 10 Apr 2013 13:21:13 +0100
From: Rob Stradling <rob.stradling@comodo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: "Yngve N. Pettersen" <yngve@spec-work.net>
References: <2C078811-2A81-4B37-82F0-FAD94A7395BD@gmx.net> <51547C0C.20806@ieca.com> <A3EEC7FB-665B-4543-8D42-A997100506E5@gmx.net> <5154B4C9.1070405@comodo.com> <5096AB41-02FD-4E01-A78E-BEF272181F42@gmx.net> <5162C154.1010202@comodo.com> <op.wu76e6o73dfyax@killashandra.invalid.invalid> <5163200D.2030300@comodo.com> <op.wu8nh01v3dfyax@killashandra.invalid.invalid> <51646709.4030803@comodo.com> <op.wvakl2sk3dfyax@killashandra.invalid.invalid>
In-Reply-To: <op.wvakl2sk3dfyax@killashandra.invalid.invalid>
Content-Type: text/plain; charset="ISO-8859-15"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] draft-ietf-tls-cached-info-14
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Wed, 10 Apr 2013 12:21:44 -0000

On 09/04/13 21:59, Yngve N. Pettersen wrote:
<snip>
>> If the End-entity certs at https://www.co.uk and https://bank.co.uk
>> are both issued by the same Intermediate, then what's the problem?
>> Why are the domain names even relevant when deciding whether or not
>> it's "safe" for the client to send an Intermediate cert's OCSP
>> Response that a different server provided?
>
> Tip: If domain names are irrelevant, make sure they do not carry meaning
> in the discussion, particularly when combined with the word "safe".
> Might confuse things.

Noted.  Thanks.

>> I agree that my proposal should be rejected _if_ the consensus is that
>> it adds too much extra complexity.  But IMHO the more bytes on the
>> wire we can save, the more chance there is that Multi-Stapling +
>> Cached-Info will actually get deployed widely.
>
> The concept still assumes that server1 and server2 will have same binary
> response R for certificate X at time T, even if the client have
> previously only seen R from server1, and instead seen response S from
> server2.

Correct.

> If, at time T both R and S are valid, but R is valid longer than S,
> which should be indicated to server2? If both, that means more
> (unnecessary) bytes on the wire, particularly if you have more than 2
> servers (e.g. 200) with the same (issuer) certificate, each with binary
> different valid responses.
>
> What if the client indicates R to server2 and leaves out S, but server2
> does not have R (and might get response Q if it requested an update)?
> Most likely server2 would then resend response S. Result: unnecessary
> bytes on the wire.

I agree that it's possible that R, S, Q and another 200+ variants of an 
Intermediate OCSP Response might all exist, but how likely is this?

These days, CAs are expected to keep Root private keys off-line.  So in 
the typical case of a cert chain involving just 1 Intermediate, it's 
likely that the Intermediate OCSP Responses will have been pregenerated. 
  Therefore, it's likely that each server will pick up exactly the same 
OCSP Response to staple.

But let's stop discussing this point.  I just read Piyush's post and I 
think he's proposed a far better idea.  :-)

<snip>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online