Re: [TLS] TLS Cached Information Extension - version 11

[Rob Stradling <[e-mail]>]

Hi Hannes.  A couple of thoughts...


1. Have you considered the NI (Named Information) scheme [1] that the 
DECADE WG have been working on?  It "defines a URI-based name form that 
identifies a named object via hash-based binding".  Would it make sense 
to adapt your definition of CachedObject so that it makes use of NI?
(This would obviate the need for yet another hash algorithm registry).


2. Currently, cached-info only allows a TLS Client to indicate to the 
TLS Server a list of static Objects that it _doesn't_ want to receive 
(because it already has them).
i.e. "Don't send me any Objects of Type X, Y or Z that match Digests A, 
B or C".

How about extending this so that the TLS Client can indicate types of 
Object that it _does_ want to receive?
i.e. "Do send me any Objects of Type X, Y and Z that you have, excluding 
any that match Digests A, B or C".

This added functionality could meet the needs of several other TLS 
extensions that are being proposed, for example...
   - Multiple OCSP Responses [2].
   - Audit proofs for Google's Certificate Transparency proposal [3].
   - TACK rules for Convergence [4].

Or, is it your explicit intention to restrict cached-info so that it 
only supports the "standard" TLS handshake objects (e.g. Certificate, 
Trusted CAs list).
(I can see that such a restriction could help to ensure that client-side 
code can be implemented entirely within the network layer rather than 
bleeding into the application layer).


[1] http://tools.ietf.org/html/draft-farrell-decade-ni

[2] http://tools.ietf.org/html/draft-pettersen-tls-ext-multiple-ocsp

[3] 
http://www.links.org/file/CertificateAuthorityTransparencyandAuditability.pdf

[4] https://github.com/moxie0/Convergence/wiki/TACK

On 26/12/11 09:46, Hannes Tschofenig wrote:
> Hi all,
>
> Nikos provided review comments (see
> http://www.ietf.org/mail-archive/web/tls/current/msg08338.html) and I
> have incorporated them in version 11 of the draft:
> http://www.ietf.org/internet-drafts/draft-ietf-tls-cached-info-11.txt
>
> As you can see, there are a number of smaller changes here and there. I
> hope that readability has improved.
>
> There is an open issue: algorithm negotiation
>
> Currently, the draft defines a registry for hash algorithms that are
> used to produce the hashes of cached information. The client can tell
> the server that it has already cached, for example, the certificate
> chain. The server then has to only send the fingerprint of it (rather
> than the complete certificate chain). The other information (besides
> certificate chains) that can be "fingerprinted" is the list of trusted
> CAs. Does this cover all use cases?
>
> A few algorithms are defined, namely SHA-1, SHA-224, SHA-256, SHA-384,
> SHA-512. Is this a good list to start with?
>
> The draft does not define a way for the client to tell the server that
> it only supports a certain hash algorithm. Should we allow the client to
> indicate what algorithm it supports?
>
> Ciao
> Hannes
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online