Re: [TLS] #445: Enhanced New Session Ticket

[Ilari Liusvaara <[e-mail]>]

On Thu, Apr 28, 2016 at 01:43:41PM -0700, Eric Rescorla wrote:
> On Thu, Apr 28, 2016 at 12:32 PM, Ilari Liusvaara <[e-mail]>
> wrote:
> 
> 
> > - I presume 0-RTT used in retried ClientHello uses (and for the verify
> >   mechanism to work, that needs to be allowed!) uses ClientHello1...
> >   ClientHello2 as its base hash?
> >
> 
> I don't think I understand what you are asking. Can you rephrase.

Client sends ClientHello with 0RTT data, gets HelloRetryRequest back and
resends ClientHello. For hash continuation to work, the new ClientHello
needs to contain the EarlyData extension, which would imply there is
0RTT data following that too.
 
> > - Server can send CertificateRequest in GDHE-PSK or PSK mode???
> >
> 
> Is there a reason that's undesirable? Note that it can always do
> post-handshake
> authentication, so we need to ensure that this is secure. My understanding
> is
> that because it covers the server's Finished, it therefore builds in the PSK
> value (per the analyis from Scott et al.). Do you have a concern with this.

Note that carelessly doing post-handshake auth can lead to nasty issues
(fortunately it is not allowed for HTTP/2!).
 
And wonder what it would do to the handshake state machine to have the
possibility of the CertificateRequest message (you need state machine to
avoid all sorts of attacks).

> - What are 'etc' for parameters for 0-RTT data? Use the present
> >   extension list here and have any future extensions that matter here
> >   explicitly define their interaction.
> >
> 
> The list is an example. The operative word is "all".

And what is "all" with current extensions (defined as whatever is in
registry currently + whatever TLS 1.3 base defines)? I think ciphersuite
(apporiately transformed) and ALPN. Are there others?

I'm ignoring future extensions, as those can define whatever is needed.

> - The requirement for server to validate its extensions... Hopefully
> >   there is no security reason for that... I really don't see it being
> >   implemented correctly (and the description looks completely screwy[1]).
> >
> 
> This is an important requirement. For instance, you need the same ALPN
> value.

ALPN yes. However, with all the extensions the chances this requirement
is implemented correctly are slim.

Which means that relying upon it for safety is a Bad Idea.

I think one should explicitly call out extensions that need special
handling here (which I think is presently only ALPN).

> > - 1 RTT server context presumably ends in CertificateRequest, not
> >   CertificateVerify (the Certificate and CertificateVerify are
> >   impiled).
> >
> 
> I'm not sure which section of the draft you're referring too here.

The table of authentication block (Certificate+CertificateVerify+Finished
sequences) base keys and hashes (section 6.3.4 in current Editor's Copy).
 
> - You might want flag for if server promises replay protection or
> >   not in NST.
> >
> 
> We discussed this in BE and the consensus was that it was not clear how
> the server implemented this and so it was unwise to promise it.

You can replay-cache on ClientHello hash.
 
> > - You might want to specify that allow_dhe_resumption doesn't
> >   change key exchange, only authentication (so DHE_CERT becomes
> >   DHE_PSK and ECDHE_CERT becomes ECDHE_PSK).
> 
> I'm not sure I follow. It changes key exchange. If we want to have
> a resumption mode that has the server sign, we'll need a different
> indicator here.

Can ciphersuite C02B (ECDHE_ECDSA/...) become 00AA (DHE_PSK/...)
upon use of the created PSK?

> [1] There are many extensions that are not relevant because those
> > control server authentication (e.g. status_request, status_request_v2,
> > signed_certificate_timestamp, server_certificate_type). And some that
> > are low-level connection control (e.g. max_fragment_length)
> 
> Yes, I am being conservative here because false positives don't seem like
> they will happen a lot.

False positives? Try implementation errors.
 
> ALPN is special here tho: It needs to match the impiled 0-RTT ALPN
> > (does one want that extension in 0-RTT case anyway?).
> >
> 
> Yes, you absolutely need ALPN for early data.

I mean do you need explicit indication, as opposed to taking the
protocol the accepted 0-RTT data was for and not signaling it.

Otherwise you need MUST abort requirement for the client.


-Ilari