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

[Ilari Liusvaara <[e-mail]>]

On Thu, Apr 28, 2016 at 03:11:50PM -0700, Eric Rescorla wrote:
> 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.

That enlarges the state that needs to be kept. If one keeps extensions,
one only needs ~40 bytes. Whereas saving full hash state needs IIRC 114
bytes (SHA-256) or 228 bytes (SHA-384). And cookies are max. 255 bytes.

And not many hash implementations support dumping and reloading state.
 
> > > - 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.

They will apparently use their own mechanism. The problem being that
client and server end up being confused about authority the data is sent
as, resulting exploitable security issues (avoiding this in HTTP/2 takes
application-layer coordination).
 
> 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.

EncryptedExtensions (or its "premessages") always follow ServerHello, so
no problem there.

I place CertificateRequest as "premessage" of server Certificate. But PSK
and GDHE-PSK don't have server Certificate, so it would have to be
"premessage" of server Finished.
 
> > > - 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.

So the 'etc' stands for "whatever will be defined by future extensions"?
One might want to make that clearer.

Also, things get screwy with SNI, and I think it is better not to try to
use SNI with PSK.

The rest besides ALPN and SNI looks to me those are either meaningless
or should be taken anew.

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

Well, by CAP theorem, since you need the "C" and "A", it impiles that
you won't have "P". So implementing the guarantee is very difficult in
any sort of distributed system. But that doesn't mean it is difficult in
centralized system.

(But then, it is infeasible to eliminate 0-RTT replay completely, so relying
too much on replay-caching, even if known available is probably a bad idea).
 
> > > [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?

Well, first is only performance problem. The second can be safety problem,
so yes, my concern is 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.

I mean for the subsequent handshake. Since 0-RTT ALPN and connection
ALPN needs to match, either:

1) Take the 0-RTT ALPN implicitly as connection ALPN.
2) Signal the same ALPN again, and have that client MUST check it matches
   and abort otherwise.


-Ilari