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

Jouni <jouni.nospam@gmail.com> Tue, 22 December 2015 03:36 UTC

Return-Path: <jouni.nospam@gmail.com>
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 23EF61B29AC; Mon, 21 Dec 2015 19:36:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] 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 BqOCuaLPz3xR; Mon, 21 Dec 2015 19:36:52 -0800 (PST)
Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (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 3F37C1ADBF8; Mon, 21 Dec 2015 19:36:52 -0800 (PST)
Received: by mail-pf0-x235.google.com with SMTP id u7so52409118pfb.1; Mon, 21 Dec 2015 19:36:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6Su2HQBK1SRstoEK++rC6mB8190wjSNJc3qYdsSAKzw=; b=OxFwW2v/joRtHGWu2A3xiUZYAtlicWXraYoTMg+Uus09KORJaQapg28ZYTCWZOcgvv 43OedbQ3goU3nsDUfKwj+q+tYO1VRt7lB/CrtZqc4Dy1su6oDPgUVw7J3u2AniCXblyJ WP3tXQHhxHr9yQ+KqrwxAdctsBfx27ho3d1Xgdlz8YV5/vByJAgJc9xIUgEVB9W4WFVu ABRWcCjn1U+fZsYbdnZ63MpkHy5zHhN0toWtmY2X57w+DDksj27BjUMS4mM3JCAeYzFt CHnc6TErj+tKd9nzs65cRmsA5wd3xDl/d+1aVHF/0kbJKNhuW5DgyWSI2WcieCzlqulh Gj3A==
X-Received: by 10.98.70.193 with SMTP id o62mr27192645pfi.32.1450755410995; Mon, 21 Dec 2015 19:36:50 -0800 (PST)
Received: from [10.0.0.17] (c-24-5-144-221.hsd1.ca.comcast.net. [24.5.144.221]) by smtp.gmail.com with ESMTPSA id y26sm37487221pfi.32.2015.12.21.19.36.49 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 21 Dec 2015 19:36:50 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Jouni <jouni.nospam@gmail.com>
In-Reply-To: <5678538C.90204@gmx.net>
Date: Mon, 21 Dec 2015 19:36:48 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <7B6D973A-C8C9-4B00-81E5-3114263747AA@gmail.com>
References: <A36B32E0-28E9-4B9C-AE8F-F9C21B3110E4@gmail.com> <5678538C.90204@gmx.net>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/x1Ob1o3IVpneY0SFDyHS5OQpkgM>
Cc: draft-ietf-tls-cached-info@ietf.org, "gen-art@ietf.org \(gen-art@ietf.org\)" <gen-art@ietf.org>
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: Tue, 22 Dec 2015 03:36:54 -0000

Hi Hannes,


> On 21 Dec 2015, at 11:31, Hannes Tschofenig <Hannes.Tschofenig@gmx.net> wrote:
> 
> 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.

Ok. 

> 
> 
> 
>> * 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?

Yes. You should probably add the above in some form to the draft. It is a good clarification.

- Jouni


> 
> Ciao
> Hannes
>