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

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 14 Dec 2011 17:08:03 +0100

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. 

This week I had a chat with Joe about draft-ietf-tls-cached-info-10.txt. He added me as a co-author and encouraged me to interact with the group to move it forward. 

With version 10 I refreshed the document since it expired. 

I am planning to reach out to the smart objects folks to double-check whether it meets their requirements and to solicit reviews. 

In any case, please review the document and share your comments with us.

Ciao
Hannes

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 14 Dec 2011 17:35:57 +0100

> 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…
[...]
> 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

---

From: Chris Richardson <[email-masked]>
Date: Tue, 20 Dec 2011 17:12:56 -0500

Section 3:
...
 struct {
              CachedObject cached_info<1..2^16-1>;
         } CachedInformation;
...

Section 4.1:

... which MAY contain zero or more cached
   objects (CachedObject)....

I believe that, in Section 3, you want
cached_info<0..2^16-1>

On Wed, Dec 14, 2011 at 11:08 AM, Hannes Tschofenig
<[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls