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

["Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>]

Hi Nikos, 

thanks for your quick feedback. 

Your remark regarding the hash algorithm is correct. There are a few
other questions, namely
a)	Should there be more than one hash function be used? I would say
that in general the opinion is "yes" because of the crypto-agility
requirement. 
b)	When there is more than one algorithm what registry should be
used? The registry for HashAlgorithm registry established with RFC 5246
is one possible option but clearly defined for a different purpose. When
someone adds a new hash algorithm purely for usage with the TLS cached
info extension then the question arises of how valuable this is for what
it was initially created for by RFC 5246. I personally would just create
a separate registry rather than overloading an existing one.
c)	Should there be a negotiation of hash algorithms, as you
suggest, or rather a pure indication. I am OK with negotiation.
d)	What should be the hash algorithm that is
mandatory-to-implement? I would not pick one.

Your interpretation of the text in Section 5.1 is correct. There is
definitely a chance to improve the text. 

Regarding your question about the usage of TLS in communication
environments with low bandwidth, and high loss rate. Yes, there are
communities who run IP-based protocols, including DTLS/TLS on
constrained devices, such as sensors. Have a look at this workshop
report: http://tools.ietf.org/html/draft-iab-smart-object-workshop-06  

I would appreciate your feedback on the remaining questions concerning
the hash algorithm topic. I will produce an updated version of the draft
that clarifies the text in Section 5.1.

Ciao
Hannes

On Wed, Dec 14, 2011 at 5:08 PM, Hannes Tschofenig
<Hannes.Tschofenig at 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