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

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 28 Apr 2016 22:32:52 +0300

Some comments:

- 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?
- Is that 0-RTT Finished message needed? It is the only 0-RTT handshake
  message...
- Server can send CertificateRequest in GDHE-PSK or PSK mode???
- 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 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]).
- 1 RTT server context presumably ends in CertificateRequest, not
  CertificateVerify (the Certificate and CertificateVerify are
  impiled).
- You might want flag for if server promises replay protection or
  not in NST.
- 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).

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

ALPN is special here tho: It needs to match the impiled 0-RTT ALPN
(does one want that extension in 0-RTT case anyway?).

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 28 Apr 2016 13:43:41 -0700

> Some comments:

Please note: this PR is still a WIP. I'll be updating it in a bit...

>   ClientHello2 as its base hash?

I don't think I understand what you are asking. Can you rephrase.

> - Is that 0-RTT Finished message needed? It is the only 0-RTT handshake

I think so it's a proof that the client knows the key. Also, per the
discussion in
Buenos-Aires we expect to be adding

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

>   explicitly define their interaction.

The list is an example. The operative word is "all".

>   implemented correctly (and the description looks completely screwy[1]).

This is an important requirement. For instance, you need the same ALPN
value.

>   CertificateVerify (the Certificate and CertificateVerify are

I'm not sure which section of the draft you're referring too here.

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

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

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

> (does one want that extension in 0-RTT case anyway?).

Yes, you absolutely need ALPN for early data.

-Ekr

>
> -Ilari
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 29 Apr 2016 07:03:59 +1000

> a resumption mode that has the server sign, we'll need a different

There is a separate issue that would have the client able to request
that the server provide a certificate/certificateverify in resumption
handshakes.  For that, we might add a allow_cert_resumption flag.  But
we would do that separately.

(Regarding that, if we use cached-info on that resumption, which is
probably a good idea overall, then that extension will differ between
handshakes.)

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 28 Apr 2016 14:21:11 -0700

On Thu, Apr 28, 2016 at 1:43 PM, Eric Rescorla <[email-masked]> wrote:

> On Thu, Apr 28, 2016 at 12:32 PM, Ilari Liusvaara <
> [email-masked]> wrote:
>
>> Some comments:
>>
>

Ah, right, I got confused about sections. Thanks.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 29 Apr 2016 00:40:46 +0300

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

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

> This is an important requirement. For instance, you need the same ALPN

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

> 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).
 
> the server implemented this and so it was unwise to promise it.

You can replay-cache on ClientHello hash.
 
> a resumption mode that has the server sign, we'll need a different

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

> Yes, I am being conservative here because false positives don't seem like

False positives? Try implementation errors.
 
> 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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 28 Apr 2016 15:11:50 -0700

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

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

> avoid all sorts of attacks).

Well note that the EncryptedExtensions.

> (apporiately transformed) and ALPN. Are there others?

Yes, that's what I meant.

> sequences) base keys and hashes (section 6.3.4 in current Editor's Copy).

Thanks, I've fixed this

> You can replay-cache on ClientHello hash.

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

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

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

> 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

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 29 Apr 2016 08:58:31 +0300

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

> Unfortunately this does not work perfectly in distributed systems, which is

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

> 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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 29 Apr 2016 16:52:08 +1000

On 29 April 2016 at 15:58, Ilari Liusvaara <[email-masked]> wrote:
>> [HRR state]

Cookies are as yet undefined, but I would imagine that these would be
just the same size as the pre-shared-key identity for all the same
reasons.

> And not many hash implementations support dumping and reloading state.

What would you prefer?  We could specify some very strict rules about
what changes a client can make to their ClientHello so that the server
can simply store things that might change (like the early_data
extension, which will disappear on the second attempt, and whether a
key share was needed, and so forth).

>> [client auth]
> The problem being that

The confused deputy problem, yes.  That's a "feature" that we have to
retain, so I don't see much point bellyaching over it.  That said, we
can (and are) improving things in HTTP/2.

>> [extension checking on resumption]
>

The primary function of SNI is routing.  Remove it and stuff breaks.
Thus, I would say include it, but make sure it doesn't result in a
change in configuration.  The simplest thing to do is reject PSK if
the old SNI != the new SNI.

> The rest besides ALPN and SNI looks to me those are either meaningless

That is probably true for a lot of them.  But we can't say that for
certain.  For instance, when we defined EMS, which is irrelevant here,
it was important that it be present when resuming or bad things
happened.  I'm not suggesting that exact thing will happen again, but
we can't presume that we won't need this.

> 2) Signal the same ALPN again, and have that client MUST check it matches

I believe that we have to do the latter.  Since we can't be sure that
the server knows the ALPN from before if it has to reject 0-RTT.  My
plan for this is:

1. store ALPN in the ticket/session
2. if doing 0-RTT, before accepting 0-RTT data, perform the normal
ALPN negotiation
3. check the negotiated ALPN with the stored value, and if they don't
match reject the 0-RTT data

Note that this means that clients will have to deal with having to
change protocols when 0-RTT data is rejected.  But I don't see any
other way to do this.

This also assumes that TLS session resumption is not carrying over
application state in addition to TLS state.  I believe that is
reasonable, though it's worth stating.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 29 Apr 2016 18:38:31 +0300

> just the same size as the pre-shared-key identity for all the same

Well, this is about the size one needs for the required state.
 
> key share was needed, and so forth).

That ~40 bytes (IIRC, it was actually 37) was done by exploiting every-
thing I could out of the rules in WIP #344 and relied on EDI being
preserved.

EDI looks like rather sizable structure currently (even after compressing
the configuration_id by obvious means).

> the old SNI != the new SNI.

That kind of non-obvious stuff really needs to be included.

They way it is right now written, I think very few TLS stacks are going
to get it right.

> we can't presume that we won't need this.

My point is: Future extensions can give their rules, TLS 1.3 spec needs
to give rules about present ones.

> match reject the 0-RTT data

4. If 0-RTT is accepted, client checks the ALPN server sent and
compares it with value it impiled. If those don't match, the client
MUST abort.

1) would be:

1. store ALPN in the ticket/session
2. if doing 0-RTT, before accepting 0-RTT data, check if the 0-RTT
   ALPN is acceptable. If it isn't, reject 0-RTT.
3. If 0-RTT was rejected, select new ALPN, signal it in Encrypted
   Extensions.

That would make ALPN and EDI mutually exclusive in EncryptedExtensions.

> change protocols when 0-RTT data is rejected.  But I don't see any

Well, the applications obviously have to be able to deal with the
protocol possibly changing.
 
> reasonable, though it's worth stating.

Well, any state they can't recover.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 29 Apr 2016 09:16:07 -0700

> the configuration_id by obvious means).

Are you looking at a different document than I am: EDI currently is:

       struct {
           select (Role) {
               case client:
                   opaque context<0..255>;

               case server:
                  struct {};
           }
       } EarlyDataIndication;

And the context is basically a placeholder.

> They way it is right now written, I think very few TLS stacks are going

Proposed text would be welcome here.

> That would make ALPN and EDI mutually exclusive in EncryptedExtensions.

This doesn't seem awesome from the client's perspective. I'm trying to make
the ordinary PSK-resumption design less of a special case.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 29 Apr 2016 20:46:43 +0300

> And the context is basically a placeholder.

Ah, I didn't see a PR about it and then looked at Editor's Copy.
Clearly a different document.
 
> Proposed text would be welcome here.

Well, the more I think about this, the messier things about interaction
between SNI, "static" PSKs and "dynamic" PSKs seem to be...

And unlike ALPN, where problems only appear in context of 0-RTT, now you
 
> the ordinary PSK-resumption design less of a special case.

Well, the client needs to keep track of the ALP anyway. If for nothing
else, to check that the server isn't trying to do anything crazy.

I think it is easier for the client just to imply the ALP in presence of
accepted 0-RTT.

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 29 Apr 2016 21:33:32 +0300

On Fri, Apr 29, 2016 at 11:30:02AM -0700, Eric Rescorla wrote:
> On Fri, Apr 29, 2016 at 10:46 AM, Ilari Liusvaara <[email-masked]>
> wrote:
> > >
> I don't see why that's true in the absence of 0-RTt. There's no reason why
> the
> server shouldn't be able to select any ALPN offers the client provides
> regardless
> of the original offer..

I mean in case where 0-RTT was accepted. Otherwise normal ALPN
negotiation can take place (and by existing definition of ALPN, has to).

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 29 Apr 2016 11:30:02 -0700

On Fri, Apr 29, 2016 at 10:46 AM, Ilari Liusvaara <[email-masked]>
wrote:

> > > > On 29 April 2016 at 15:58, Ilari Liusvaara <[email-masked]
> >
> > > wrote:
> > >

Yes, 445 builds on 444.

-Ekr