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

[Eric Rescorla <[e-mail]>]

On Thu, Apr 28, 2016 at 2:40 PM, Ilari Liusvaara <[e-mail]>
wrote:

> 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.
>

No, I don't think you need to have the extension. Either the server is
keeping
state and there's no problem or the server is offloading state in a cookie
(mechanism TBD) and in either case it just needs the state as of the
beginning of the new ClientHello.


> > - 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!).
>

I expect that post-handshake client auth will be allowed for HTTP/2. Can you
elaborate on your concern.


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).


Well note that the EncryptedExtensions.



> > - 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?
>

Yes, that's what I meant.



> > > - 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).
>

Thanks, I've fixed this


> - 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.
>

Unfortunately this does not work perfectly in distributed systems, which is
the original
source of the concern.


> > > - 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?


Ah, I see. I thought about whether we should prohibit that and decided
against
it. But I could be convinced the other way.



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

Well, it seems like there are two concerns here re: implementation errors.

1. That servers will bungle this check and reject 0-RTT when they should
accept it [false positive]
2. That servers will bungle this check and accept 0-RTT when they should
reject it (and that we'll be relying on that).

Is your concern the first or the second?

> 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.
>

Well, the current draft does not have explicit indication. All of the 0-RTT
context is tied to the ticket.

-Ekr


> Otherwise you need MUST abort requirement for the client.
>
>
> -Ilari
>