Re: [TLS] WGLC: draft-ietf-tls-cached-info

[Adam Langley <[e-mail]>]

On Tue, Jul 29, 2014 at 5:48 AM, Sean Turner <[e-mail]> wrote:
> This is the working group last call for draft-ietf-tls-cached-info:
>   http://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/
> Please send comments on this draft to the TLS list before August 19, 2014.

It's been quite a while since this has appeared!

As an implementer, I still think there are ambiguities in the draft,
although I might just be dumb. If I'm not being dumb then I don't
think this draft is ready.


Can I send multiple CachedObjects with the same CachedInformationType?
Nothing seems to forbid it and the draft hints that it's expected:

> Note: If clients make use of the Server Name Indication [RFC6066]
>  then clients may need to cache multiple data items for a single
>  server since servers may host multiple 'virtual' servers at a single
>  underlying network address.

That's cool, but if I offer multiple certificate_chain CachedObjects,
how do I know which the server is using if it omits it? Does it echo
the one that it wants to use in its CachedObjects? In that case, I
assume that it's invalid for a server to send multiple CachedObjects
with the same CachedInformationType? The draft suggests otherwise
however:

> By
> returning the "cached_information" extension the server indicates
> that it supports caching of each present CachedObject that matches
> the specified hash value.

That suggests to me that the server's CachedObjects are just
indications about what types it supports. (But then why do they
include hash values? Does a client have to echo the CachedObject
exactly? I.e. with the same HashAlgorithm and hash value?)

The draft also says:

> Following a successful exchange of the "cached_information"
> extensions in the client and server hello, the server omits sending
> the corresponding handshake message.

But it doesn't actually seem to. E.g. if the handshake is using cached
certificates then the Certificate message isn't *omitted*, it's just
altered:

> How information is omitted from
> the handshake message is defined per cached info type.

Lastly, I think there are Triple Handshake worries in here:

> The Finished message MUST be
> calculated over the actual data exchanged in the handshake protocol.

The triple handshake fix works by extending the master secret over the
full handshake, including the server's identity. However, if the
server's identity is being replaced with an MD5 hash (and MD5 is a
value of HashAlgorithm[1]) then I think that might reintroduce the
Triple Handshake problem. The draft says:

> There is no requirement that this hash algorithm must
> have strong collision resistance.

I fear that this might be incorrect in the light of the Triple Handshake work.


[1] https://tools.ietf.org/html/rfc5246#section-7.4.1.4.1


Cheers

AGL

-- 
Adam Langley [e-mail] https://www.imperialviolet.org