Re: [Gen-art] Generate review of draft-ietf-tls-cached-info-20

Hannes Tschofenig <hannes.tschofenig@gmx.net> Mon, 21 December 2015 19:31 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDB61AC413; Mon, 21 Dec 2015 11:31:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 zEMf-Ik_N6CS; Mon, 21 Dec 2015 11:31:26 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B9131AC410; Mon, 21 Dec 2015 11:31:26 -0800 (PST)
Received: from [192.168.10.142] ([80.92.114.181]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lu7a2-1aLeYP08iU-011Skx; Mon, 21 Dec 2015 20:31:23 +0100
To: Jouni <jouni.nospam@gmail.com>, "gen-art@ietf.org (gen-art@ietf.org)" <gen-art@ietf.org>, draft-ietf-tls-cached-info@ietf.org
References: <A36B32E0-28E9-4B9C-AE8F-F9C21B3110E4@gmail.com>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
X-Enigmail-Draft-Status: N1110
Message-ID: <5678538C.90204@gmx.net>
Date: Mon, 21 Dec 2015 20:31:24 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <A36B32E0-28E9-4B9C-AE8F-F9C21B3110E4@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DbF9fSXeCqrI7Sev4d4dt2wv6l1nfRO0D"
X-Provags-ID: V03:K0:B5c3lfGB1CEciEpKBSll16+6LKaX6RSst6HcpMdq6dPBtHcCCVs Vs6e1xQO+v8kssyUG5Tiii21fl1fl82OizZAWEqON8WirH5daTMMNz8J3WdMwwdU8w2m5ET qqpSwMW5ehzQNUHsJMrkGhVziBZqpLTNYp6nMG1eHuOiiyLGzIpO6984wCZ0Vp/1nBvrqxQ IecBgTs0sDutZGP99vI8g==
X-UI-Out-Filterresults: notjunk:1;V01:K0:7J8T5d2a2zU=:AQt/3qFeUT9sKBI85TGqHc XOQLSKHH292JckWvHjqQ6LXMvwjUcKcDI0CIFTtzMm1QapQVZ6OQ+jIBGd9yW9iYVDbNkUWTW 6k1Z39SwZtglgpeuqtK5dshIXi/1/4hCPMaYSmZAj8UqEkwiF6GDTDR1zkkc3GK1HK9NejLwj 8T/EpQwuVJitCk0waT26KJ7QqT7Ywa23DCEhnz3FvKqKwzYLbmg7+MQRZnSM9yVPqMs+4B8D6 C5istQDx4OGcPRgo2cwzolSvZ1tJVI4oQMWWaH6o0lcQ+BORfrJrtHgwcMS50dEL81kdCrchl WvNw6c+nIlvaC+2cHIUhbiVTcWn2IgyidIN2At2wRKQq0XSZUf4EibbrFlB8gci34VgnVnfUK 3GZtojZaz4yjO5TEVTUbcy4KYwhZME/ZxVAbfs6ZwFyzZ5T/L7EDn3UDFyhG10m+xpyZwWfHU j/jnMUCD4C9Lc9hggWpg/sPZ6hLrl09JpADGbWFtYE0I2WAGAKmUA0mYzcer3G+OIwv78Wp1m QQYf3RFeWI78bIYxRXl3e4NbRCrQcWcw3vl3n0SxcUYe5CQpU2JyRlPCPmt0SmwHN1oAdVYZ7 Qh0VKLzy/oy2LE6JFBL+euhCPzlSjk81WvgT2951A26asf7EzmTIk58P3qb25zlLDX8dyE9hH I59SajgPzbuvYwjYf5778frSVlFZdmxhUki6rtXNz4wR5QB1QcT2sYETu3WWYn837vWNZ+reQ dNZ3STGC3fUDK+3puypfeJu7eLLhuNrxN2EfsWn5goktMXQOKkUMk7htwps=
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/oqVtSbtFVgSb2hrETVjXtKp4Yqs>
Subject: Re: [Gen-art] Generate review of draft-ietf-tls-cached-info-20
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Dec 2015 19:31:28 -0000

Hi Jouni,

thanks for your review. Please find my response inline:

On 11/30/2015 04:46 AM, Jouni wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-ietf-tls-cached-info-20 Reviewer: Jouni Korhonen 
> Review Date: 2015-11-29 IETF LC End Date: 2015-12-04 IESG Telechat
> date: 2015-12-17
> 
> 
> Summary: --------
> 
> Ready for publication with some nits.
> 
> Comments: ---------
> 
> The document was good read and easy to understand.
> 
> Minor issues/nits: ------------------
> 
> * IDnits spits out some warning & comments that all seem to be bogus.
> However, the normative reference to RFC 4634 needs to be replaced
> with RFC 6234.
Fixed.

> 
> * The document describes in few places how the mechanisms specified
> extends/updates the Certificate and CertificateRequest structures. So
> maybe the draft should also state that in its boilerplate “Updates:
> 5246, 7250” ?
> 

I believe it only explains the interworking with other, related
specifications but it does not really update them.

Regarding RFC 7250: With RFC 7250 the Certificate payload may contain a
SubjectPublicKeyInfo payload rather than a certificate. I wanted to
point this out in the description.

Regarding RFC 5246: The specification re-uses existing TLS 1.2 payloads
and defines extensions for them but it does not change the behavior of
the underlying TLS 1.2 mechanism.



> * Line 99: s/its’/its

OK.

> 
> * Line 164: s/data\.\./data\.
OK.

> 
> * Section 5 talks about “input data” for the hash & fingerprint
> calculation. What the “input data” exactly is becomes obvious after
> reading the Appendix A. However, for non-TLS WG activist it was not
> obvious from the first sight. Suggest adding a forward reference to
> Appendix A example.

Fine with me.

> 
> * Section 6 uses [0], [1], .. [4]. While these are perfectly correct
> they can be mixed with references in the first sight -> few seconds
> of confusion ;) I would suggest using (0), .. (4).

Sounds reasonable.

> 
> * The document uses referencing all styles “RFC 7250 [RFC7250]”, “RFC
> 7250” and “[RFC7250]”. Pick one.
Ok.

> 
> * It is unclear to me what happens & what are the procedures when two
> different “input data”s generate the same fingerprint.

Since the client caches information previously provided by the server,
such as the certificate, it is the server that can detect that such a
collision can occur. If it occurs the server operator has two options,
namely not to use the extension or to resolve the conflict.

Does this description make sense?

Ciao
Hannes