Re: [TLS] draft-ietf-tls-cached-info-10.txt

Nikos Mavrogiannopoulos <nmav@gnutls.org> Wed, 14 December 2011 16:35 UTC

Return-Path: <n.mavrogiannopoulos@gmail.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 17FEA21F8C2B for <tls@ietfa.amsl.com>; Wed, 14 Dec 2011 08:35:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 3bFMhDCFV+Fp for <tls@ietfa.amsl.com>; Wed, 14 Dec 2011 08:35:58 -0800 (PST)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5930021F8B6C for <tls@ietf.org>; Wed, 14 Dec 2011 08:35:58 -0800 (PST)
Received: by eeke49 with SMTP id e49so990945eek.31 for <tls@ietf.org>; Wed, 14 Dec 2011 08:35:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=i5m9If8A94RcYM8olpSupW5NeEznTQPyoEe4pUdBuhI=; b=Kq7VdNJ37ZjWcOhL7T3m4YysMzbRYnR2r8V9R5EtgG4JNTzDWCxBvUfJt9C7gLDPmC mcURudjjuHF5zxoGKIyPSloQjO8aCIXNvHt+pu6pbLqXA9BySYoiNJyNkhKWBv0+49d1 B3KxuJPD7j/za9o4awr1Of2cxBU983aTky+yY=
MIME-Version: 1.0
Received: by 10.180.14.69 with SMTP id n5mr6274810wic.13.1323880557481; Wed, 14 Dec 2011 08:35:57 -0800 (PST)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.180.81.65 with HTTP; Wed, 14 Dec 2011 08:35:57 -0800 (PST)
In-Reply-To: <20111214160803.137810@gmx.net>
References: <20111214160803.137810@gmx.net>
Date: Wed, 14 Dec 2011 17:35:57 +0100
X-Google-Sender-Auth: bK3kjgPBr4WpOmjG6YPH72MLAcc
Message-ID: <CAJU7zaLabYCXRAY1BmkcN-UmmMSxNcXJqCwp0evDmHdoO+edSw@mail.gmail.com>
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Content-Type: text/plain; charset="UTF-8"
Cc: tls@ietf.org
Subject: Re: [TLS] draft-ietf-tls-cached-info-10.txt
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, 14 Dec 2011 16:35:59 -0000

On Wed, Dec 14, 2011 at 5:08 PM, Hannes Tschofenig
<Hannes.Tschofenig@gmx.net> wrote:
> Hi all,
> Ekr suggested during the Taipei IETF TLS meeting to remove the functionality of conveying a public key fingerprint from draft-wouters-tls-oob-pubkey. I did that already during that meeting with the submission of draft-wouters-tls-oob-pubkey-02.
[...]
> In any case, please review the document and share your comments with us.

Hello,
 Some comments.

page 5:
The hash algorithm used to calculate hash values SHALL be the hash
   algorithm that was used to generate the Finished message in the
   handshake exchange from which the hashed information was cached.
   Hash algorithm identifiers are defined in the RFC 5246 [RFC5246]
   HashAlgorithm registry.

The finished message doesn't use a hash algorithm, but rather a PRF.
That PRF is based on SHA1 in TLS 1.0 and SHA256 in TLS 1.2, but there
is no guarantee that a PRF must be based on a hash. Why doesn't this
extension negotiate the hash on the previous (non-cached) run?

page 8:
 I cannot understand the meaning of 5 and 5.1. Does it mean that the
certificate message sent is:
struct {
              CachedObject ASN.1Cert<1..2^24-1>;
} Certificate;

If this is the meaning then "Substitution syntax is defined by
expanding the syntax of the opaque ASN.1Cert structure" should be
better phrased. I'd use "The certificate message is replaced by the
CachedCertificate message defined as:"
...

same applies in 5.2.

page 3:
   "Significant benefits can be achieved in low bandwidth and high
   latency networks".
Out of curiosity. Is TLS being used in any low-bandwidth channels,
where this extension is needed? (latency low or high doesn't really
matter since the round-trips are not affected by this extension)

regards,
Nikos