Re: [TLS] Review of draft-ietf-tls-cached-info-11

Hannes Tschofenig <Hannes.Tschofenig@gmx.net> Fri, 13 July 2012 09:45 UTC

Return-Path: <Hannes.Tschofenig@gmx.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 E8B4921F8683 for <tls@ietfa.amsl.com>; Fri, 13 Jul 2012 02:45:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.464
X-Spam-Level:
X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 d-cABUasx0ds for <tls@ietfa.amsl.com>; Fri, 13 Jul 2012 02:45:21 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id EAE9321F8638 for <tls@ietf.org>; Fri, 13 Jul 2012 02:45:20 -0700 (PDT)
Received: (qmail invoked by alias); 13 Jul 2012 09:45:55 -0000
Received: from unknown (EHLO [10.255.128.232]) [194.251.119.201] by mail.gmx.net (mp010) with SMTP; 13 Jul 2012 11:45:55 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+D4H4cjpyDCJyNm5Iz1W6FNx9Ryl7p3J0mqjkpZ/ JN388mSN9+Vooo
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
In-Reply-To: <4F7397D3.4060801@nic.cz>
Date: Fri, 13 Jul 2012 12:45:53 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <7594BFD0-9019-4AB8-93AB-3895BA3A1087@gmx.net>
References: <4F7397D3.4060801@nic.cz>
To: Ondrej Mikle <ondrej.mikle@nic.cz>
X-Mailer: Apple Mail (2.1084)
X-Y-GMX-Trusted: 0
Cc: tls@ietf.org
Subject: Re: [TLS] Review of draft-ietf-tls-cached-info-11
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: Fri, 13 Jul 2012 09:45:22 -0000

(added the TLS working group to share the review feedback)

Hi Ondrej, 

thanks for your feedback.

> What I found to to be missing is an example or use-case that would illustrate
> what the extension is good for. Basically an extended version of what you were
> talking about during your tls session presentation.
> 
> For example, it could look like (if I understood correctly):
> 
> 1. Bootstrap: the client does the "usual" TLS handshake, stores the
> certificates and/or their hashes
> 
> 2. On each subsequent connection, the client uses the new extension to say
> that it knows about one specific chain
> 
> 3. In case the chain changes, the client does full regular handshake (i.e. goto 1)
> 

In can add text as you suggested. 

> Question regarding this paragraph:
> 
>   When the CachedInformationType identifies a certificate_chain, then
>   the hash_value field MUST include a hash calculated over the
>   certificate_list element of a server side Certificate message,
>   excluding the three length bytes of the certificate_list vector.
> 
> My interpretation: the hash is computed over the chain retrieved from
> handshake (i.e. excluding any "possible fancy validation-path-building code"
> at the client's side)

The hash is only computed over the message structures and not over any code. 

Did I understood your concern correctly? 

> 
> Question about "trusted_cas" and the trust anchors' fingerprint: I can't
> figure out what it is supposed to accomplish from the draft.

TLS exchanges different payloads and some of them could be larger (and they rarely change) and there it makes sense to only exchange a hash over them and to send the hash instead of repeatedly sending the value. Bob, in his review, noted that there are a few extensions being developed that could also benefit from this cached extension functionality, such as draft-pettersen-tls-ext-multiple-ocsp. 


Ciao
Hannes


> 
> If you'd like we could discuss it today (Thursday).
> 
> 
> Ondrej
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (GNU/Linux)
> 
> iQEcBAEBAgAGBQJPc5fTAAoJEAy6xNgMZCEgTj4H/1yf2sytbkm475n8XLUKuSBy
> Y6QG3+T3MNgjDb09GVj16sNsmE0DstGNsyilytJfSwSIZTVhKY7GxKn0M14wVijs
> sqHT7B/haKveE1dDTK7NyTRB0Kcq43FQEb4bfInAWl0NE7z3tGmV971tPcTPfBlj
> QUJ4WYTO8R8CHZ+eXv/v5JHt8aOZNeEn4BNfQ3XEihGzLvOGd2ZMV7HMx6N7UX9U
> 1kpmnAx4YusUzWIMUOp/LvsJpr0b/YdSlHw8JtZkKxC2vyR0vEV+ItXUVHrXjovQ
> w118+6gD/dNPq4VZ0BsFAIOqpotUoVAMbqAmzwmuDP108Ct3Sxn3KbHov1/JLWc=
> =Kd+Z
> -----END PGP SIGNATURE-----