Subject: Re: Performance/safety trade-off

From: Dragana Damjanovic <[email-masked]>
Date: Wed, 1 Feb 2017 12:33:28 +0100

This is the similar problem as with a lost ClientHello and 0RTT packets.

What if we send a clear text ack for 0RTT packet if the clientHello is lost
(to actually inform the client that the ClienHello has been lost) and a
cleartext ack of 1RTT packet when a client finish message is lost. This ack
can be use only for retransmissions but not for marking packets as acked?
These ack are clear text but they should not be(acks for 0RTT and 1RTT
packes should be encrypted), so we can distinguish them from proper acks.
0RTT can be just a noise, they cannot be verified, so maybe not acking them.

dragana

On Wed, Feb 1, 2017 at 12:36 AM, Watson Ladd <[email-masked]> wrote:

>
>
> On Jan 31, 2017 3:23 PM, "Martin Thomson" <[email-masked]>
> wrote:
>
> The security analyses of TLS assume receipt and verification of the
> Finished message.  It's an obvious intuition that keys depend on the
> content of the message, therefore tampering would be easily detected.
>
>
> I think someone who is more experienced/familiar with the analysis should
> chime in. My understanding is that the ROM quickly gives high probability
> of the keys being different and hence the MAC failing, and the Finished
> message is there to give an explicit confirmation property.
>
>
> That said, we've learned that intuition is often wrong in this space,
> sometimes disastrously.  We don't have an analysis of TLS that ignores
> the client Finished message.  So unless and until we do, I don't want
> to write down anything that isn't known to be safe.
>
> I know that this sucks in subtle ways, particularly in the way that
> Ian observed with respect to acknowledgments.  Because we require that
> the Finished is acknowledged with protected keys, we lose the ability
> to generate acknowledgments for them.
>
> I see three possible approaches:
>
> 1. As I originally suggested, suck it up and don't let the server send.
>
> 2. Don't protect the Finished (it's protected with TLS handshake keys
> anyway).  That would allow for acknowledgment in the clear.  That
> requires a tweak to the way that keys are shared, but it's a fairly
> simple tweak.  The major downside is that we now have an extra packet
> to send, because you can't collapse the Finished message with other
> things (like requests).
>
> 3. In the hackiest possible way, generate a redundant ACK for the
> ClientHello in the clear.  If that could trigger retransmission of the
> first encrypted packet(s), then we'd be OK.  (Sorry, I haven't
> internalized the loss recovery stuff, so I'm not sure if this even
> works, we could be back into RTO space here.)
>
> Maybe option 2 is more appealing than appalling.
>
>
> On 1 February 2017 at 04:17, Jana Iyengar <[email-masked]> wrote:
> > Since the keys cannot be the same if the ClientHello were to be modified,
> > what is the risk we are talking about here? I don't know about the crypto
> > analyses of the TLS handshake, so some insight here would be helpful.
> But I
> > agree that having the server process 1-RTT data would help with loss
> > detection. If there's no real security implication, I'd be in favor of
> > letting the server process this data.
> >
> > On Tue, Jan 31, 2017 at 8:27 AM, Watson Ladd <[email-masked]>
> wrote:
> >>
> >> On Mon, Jan 30, 2017 at 10:29 PM, Martin Thomson
> >> <[email-masked]> wrote:
> >> > In PR #39, there is a choice:
> >> >
> >> > https://github.com/quicwg/base-drafts/pull/39
> >> >
> >> > If a server receives 1-RTT-protected packets before it receives the
> >> > client Finished message, it could use them.  It has the keys.
> >> >
> >> > Obviously, if the server depends on certificate-based client
> >> > authentication it will wait.  But that's still a relatively rare
> >> > occurrence.
> >> >
> >> > However, using 1-RTT data before verifying the Finished message could
> >> > leave the server more vulnerable to an attack where the ClientHello is
> >> > modified by an attacker.  This is something that TLS 1.3 protects
> >> > against, but only indirectly.  The traffic keys are dependent on the
> >> > content of the ClientHello and so it is likely that modifications of
> >> > the ClientHello would result in being unable to communicate.  But this
> >> > isn't a strong assertion.  The various forms of analysis of the TLS
> >> > 1.3 handshake have all (I think) assumed that verification of the
> >> > Finished message is what provides integrity for the handshake.
> >>
> >> I don't believe the finished message is necessary for ensuring
> >> manipulation of the client hello message is detected.
> >> >
> >> > In #39, I opted to forbid use of the client 1-RTT data until the
> >> > handshake completes.  I'd like to confirm that this is acceptable.
> >> >
> >> > In addition to confirming this, I'd like input on what level of
> >> > justification is necessary for this in the document.  If we believe
> >> > that this is the right decision, do we need to do anything to prevent
> >> > someone from pulling out a false start hack because they disagree with
> >> > this analysis?
> >> >
> >>
> >>
> >>
> >> --
> >> "Man is born free, but everywhere he is in chains".
> >> --Rousseau.
> >>
> >
>
>
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Feb 2017 09:40:47 +1100

Yeah, given that a packet containing 0-RTT is essentially line noise
when it is received (it will contain what appears to be pure
randomness), acknowledging it would be unwise.  We generally save
acknowledgments for stuff that makes sense.  It means that 0-RTT can't
be used to improve ClientHello reliability, but at least we're not
worse off in this case.

On 1 February 2017 at 22:33, Dragana Damjanovic
<[email-masked]> wrote:
>> chime in. My understanding is that the ROM quickly gives high probability of
>> the keys being different and hence the MAC failing, and the Finished message
>> is there to give an explicit confirmation property.
>>
>>

---

From: Ian Swett <[email-masked]>
Date: Wed, 1 Feb 2017 18:51:29 -0500

I agree that acking packets we haven't decrypted feels very wrong.  If
there are critical security reasons why the 1RTT data can't be used before
the finished message, we should determine how much real world impact this
has on handshake and application latency.

BTW, what's in the finished message?  Possibly it could not even exist for
QUIC and be implicit now that QUIC has a key phase bit?

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Feb 2017 10:59:14 +1100

On 2 February 2017 at 10:51, Ian Swett <[email-masked]> wrote:
> I agree that acking packets we haven't decrypted feels very wrong.

Well, it's more than a feeling :)  You can't take back an ACK.  And if
you later find that you can't decrypt the packet, you might find
yourself in a terrible bind.

> QUIC and be implicit now that QUIC has a key phase bit?

The TLS Finished contains a MAC that provides key confirmation.
That's saying that producing and verifying it provides proof that the
handshake was successful and that the two endpoints agree about the
link between the handshake and the keys that it produced (caveat: I am
not a cryptographer, so please don't rely on my definition).

Key phase doesn't help here.  Finished is not a signal about the
transition from handshake to application data, it is critical to the
handshake *being* complete.

---

From: Ian Swett <[email-masked]>
Date: Wed, 1 Feb 2017 19:12:25 -0500

> yourself in a terrible bind.
I believe the proposal was to ack the undecrypted packets in an unencrypted
ack, have the peer see the ack, but not trust it(since it's unencrypted),
but still engage loss recovery for any packets that were unencrypted less
than the encrypted packets?  But yes, we clearly can't trust unencrypted
acks for encrypted packets, as we've discussed.

> handshake *being* complete.

Ok, so the question(which I can't answer), is whether encrypting data with
the resulting keys could be considered functionally equivalent to key
confirmation?

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Feb 2017 09:17:42 +0900

> the resulting keys could be considered functionally equivalent to key

This is the crux of the thread.  As Watson observes, the answer is
probably yes.  But we don't have a proof that confirms that.  Analysis
of TLS has mostly kept handshake and record protection separate.

---

From: Ian Swett <[email-masked]>
Date: Wed, 1 Feb 2017 19:29:03 -0500

So TLDR;
 1) Yes, we'd like to decrypt 1RTT packets before the confirmation is
received for all the reasons above.
 2) It's not absolutely critical to QUIC's existence
 3) We need to ask cryptographers, who are likely not on this thread.
 4) If it is sufficient, it'd be nice to never send the finished message,
since that creates two ways a handshake can complete(and sends an extra
packet).

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 2 Feb 2017 08:48:26 -0800

None of us are cryptographers, so I'd like to recommend that we pull in one
before we go one way or the other. Can anyone pull in a cryptographer?
Hugo, perhaps?

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 2 Feb 2017 19:53:40 +0000

> before we go one way or the other. Can anyone pull in a cryptographer?

Someone could also craft the question carefully and send it to cfrg
asking for opinions. Asking informally will probably be enough but
sometimes WGs ask more formally (via their chairs) which tends to
ensure someone does send an answer, but is generally slower.

S

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 3 Feb 2017 01:01:38 +0100

Sorry for the delay. It's been a long week of meetings.

Here's my understanding of the situation, focusing on the one-way
authentication version of TLS; I think we all agree that in the
mutually authenticated version, the server needs to wait for the
client's Finished.

The scenario of interest here is one where the server has sent
its complete flight and then receives an AEAD-encrypted message
from the client in advance of receiving the client's Finished
(which we can model as a handshake without a client Finished).

Informally, there are two potential properties we might be interested
in here:

1. The integrity of the handshake.
2. "Key confirmation", namely a demonstration that there is a
   counterparty on the other side who knows the key. Note that
   this is somewhat complicated by PSK-resumption, but for
   now consider the full handshake with DHE.

One important consideration is that we would like to be able to
establish these properties only with reference to the handshake,
without relying on the record layer. This allows you to analyze the
handshake and then compose it with an arbitrary record layer, rather
than relying on the type of combined analysis that was necessary for
TLS 1.2. Indeed, that's what we're doing with QUIC, where we are using
a record layer that's slightly different from that in TLS 1.3.  With
that in mind, upon receiving the client's Finished, the server knows
that the (anonymous) entity which sent it the ClientHello actually
knew the corresponding private DHE share and that the handshake was
un-tampered. Note that this guarantee would apply even if the
handshake were entirely unencrypted and indeed even if AES-GCM (for
instance) were completely broken. Of course, you still don't know who
you are talking to.

Krawczyk and Wee show in [0] that you actually get a secure one-way
protocol even if the client doesn't send a Finished
message. Intuitively, the server signs and MACs the entire transcript,
so any tampering is detected at the client and the client will not
accept the handshake unless it is un-tampered, so the client will also
not accept data from the server or send data to the server. The server
can of course send 0.5 RTT data, but as it doesn't know who the client
is, any tampering is largely irrelevant (See below for the resumption
case). Here's what Krawczyk and Wee say:

  TLS 1.3 include s a mandatory third message in the handshake in
  which the client sends a MAC value (client’s Finished) computed on
  the prior transcript similar to the one sent by the server in the
  second message. As our analysis shows this is not needed for the
  basic key exchange security in the case of server-only
  authentication. Yet, this message serves several purposes that are
  valuable in the TLS 1.3 setting. It serves as the confirmation from
  the client that both server and client have the same view of the
  transcript, including keying material, server identity and
  negotiated security parameters (part of the hello
  messages). Interestingly, the sending of this message has been shown
  in [21] to “upgrade" security from the indistinguishability-based
  model we use here to universally-composable security.

Without the Finished, the server only gets any confirmation that the
client has the same view when it decrypts the client's first message.
However, as I said, you only get this property via the record layer,
which means that your analysis now needs to take that into account,
whereas if you have the Finished you can get key confirmation purely
by analyzing the handshake. Now, as Watson says, there's a pretty
straight line from "received AEAD-encrypted data from the client" to
"client successfully completed the handshake", but it's not the
cleanest analytical situation.

The situation seems a bit more complicated when you are doing
resumption because now you actually care about talking to a specific
counterparty, especially if you have attached state information the
the ticket/PSK pair. I don't believe that this mostly matters in the
Krawczyk/Wee analysis, except that it's important not to over-commit
to what you know prior to receiving any information from the client's
second flight. Specifically, until you receive either Finished or some
AEAD-encrypted data, you don't know that you have a fresh connection
from the client as opposed to a replayed CH. That's generally true in
the full 1-RTT case, you just don't care because the clients are
interchangeable.

With all that said, the situation really is a lot cleaner if we leave
the Finished in place (that's why it's there after all), so I'd like
to spend some time seeing if we can do that.

It occurs to me that perhaps there's a way to improve Martin's hacky
#2 version where we don't encrypt the Finished. Specifically, we're
already discussing having a much longer header for "special" packets,
which this would be. If we simply decree that special packets also
have an explicit length rather than extending them to the end of the
UDP datagram, then we can pack multiple packets into a datagram, which
lets you send the Finished and requests together, albeit with a little
bit of overhead in terms of headers.

-Ekr

[0] http://eprint.iacr.org/2015/978.pdf

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 2 Feb 2017 16:42:14 -0800

(I'm on thin ice with my understanding of crypto, so please correct me if
I'm missing something.)

IIUC, using Finished vs. using decryptability of AEAD data is really the
same, but proving them to be equivalent is analysis we don't have.

While it doesn't matter for TLS 1.3 / TCP (since ordered delivery of
Finished followed by data), it seems to me that QUIC's unordered delivery
makes it a more interesting problem. Ekr: do you think it's worth asking
the cryptographers if using simple decryptability (which if I understand
your email correctly, is called the "indistinguishability-based model") is
a bad idea? I understand that requiring Finished has been recommended for
TLS1.3/TCP, which, again, makes sense since it's obvious that AEAD records
arrive after the Finished message, so we might as well use the Finished
message to separate analysis. It's less obvious to me however that the
requirement for Finished would have existed had the transport underneath
been one that allowed unordered delivery.

That said, David Benjamin suggested a similar but different variant of
Ekr's idea earlier: we could simply include the Finished message (as an
additional STREAM frame) in all packets during the 1-RTT round, to ensure
that any packet that is received at the server includes the Finished
message. A caveat is that the Finished message would be encrypted under the
1-RTT key, but that should be fine, right?

On Thu, Feb 2, 2017 at 4:01 PM, Eric Rescorla <[email-masked]> wrote:

> On Thu, Feb 2, 2017 at 8:53 PM, Stephen Farrell <[email-masked]
> > wrote:
>
>>
>>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 3 Feb 2017 11:53:52 +1100

On 3 February 2017 at 11:42, Jana Iyengar <[email-masked]> wrote:
> That said, David Benjamin suggested a similar but different variant of Ekr's
> idea earlier: we could simply include the Finished message (as an additional
> STREAM frame) in all packets during the 1-RTT round, to ensure that any
> packet that is received at the server includes the Finished message. A
> caveat is that the Finished message would be encrypted under the 1-RTT key,
> but that should be fine, right?

As in, aggressively "retransmit" those stream 1 frames on every packet
until any one of those packets is acknowledged?  That works, and
avoids having to design a way to cram two different levels of packet
protection into the same packet.

The rule would be "if you don't provide a client certificate,
retransmit all unacknowledged stream 1 data in every packet you send".
It's not a lot of bytes (about 40), so maybe that's an elegant
solution.

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 2 Feb 2017 17:09:03 -0800

On Thu, Feb 2, 2017 at 4:53 PM, Martin Thomson <[email-masked]>
wrote:

> Ekr's

Yeah, that's the idea. Except we'd make it a MAY retransmit, so that a
client can choose how often to send it. For instance, a client could choose
to only send it only if it's actually going to cause HoL blocking such as
in every packet that contains a STREAM frame with offset 0.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 3 Feb 2017 12:16:51 +1100

I'm happy to take that suggestion, as opposed to asking difficult
questions of cryptographers.  I find that if you ask a difficult
question, all you tend to get is more difficulty in understanding the
answer.

I will write proposed text for this.

On 3 February 2017 at 12:09, Jana Iyengar <[email-masked]> wrote:
> to only send it only if it's actually going to cause HoL blocking such as in
> every packet that contains a STREAM frame with offset 0.
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 3 Feb 2017 14:28:58 +1100

https://github.com/quicwg/base-drafts/pull/260 opened.  The text
already assumed that you need to wait for finished.  I will merge #39
at the same time as this (assuming that there aren't objections).

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 3 Feb 2017 04:04:30 -0800

Unfortunately, if you encrypt the Finished with the keys you then use for
traffic, this
breaks key separation, which we went to quite some trouble to have (this is
why
TLS 1.3 uses a different handshake key than traffic key.) However, if you
combine my proposal with David's, I believe that that resolves all the
issues.

-Ekr

---

From: Matt Holdrege <[email-masked]>
Date: Fri, 3 Feb 2017 15:20:34 +0100

Hi,

Can I ask the newbie question was RFC 3436 and especially section 1.1 of
RFC 6083 considered as lessons learned for security for QUIC?

Thanks,
-Matt

On Fri, Feb 3, 2017 at 1:04 PM, Eric Rescorla <[email-masked]> wrote:

> breaks key separation, which we went to quite some trouble to have (this
> is why

---

From: David Benjamin <[email-masked]>
Date: Fri, 03 Feb 2017 15:35:24 +0000

On Fri, Feb 3, 2017 at 7:05 AM Eric Rescorla <[email-masked]> wrote:

I admit I do not know the formal requirements here (should we summon a
cryptographer?), but I find this claim puzzling. The Finished message is
still encrypted with the TLS-level handshake keys. If our theoretical
framework for TLS's security really cares about any additional encoding
(which does not reuse any TLS-level keys) we add on top, I feel that
framework needs work.

Going by this diagram, are we not already doing this? This suggests the
Finished and EndOfEarlyData are encrypted with QUIC 1-RTT keys:
https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.html#rfc.section.4.1

David

-Ekr

Ekr's

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 3 Feb 2017 07:58:22 -0800

On Fri, Feb 3, 2017 at 7:35 AM, David Benjamin <[email-masked]>
wrote:

> cryptographer?),

Maybe. This was discussed extensively about a year ago under the topic of
"key separation".
Some of that is in the TLS archives. I can provide some more detailed
references offline
if you like.

> but I find this claim puzzling. The Finished message is still encrypted
> with the TLS-level handshake keys. If our theoretical framework for TLS's
> security really cares about any additional encoding (which does not reuse
> any TLS-level keys) we add on top, I feel that framework needs work.
>

Quite possibly. However, one of the design objectives was to build
something which was
readily analyzable with the tools we have. As I alluded to, some (though
not all) of those
tools are designed to analyze the handshake and record layer separately and
so if you
have to use the record layer keys to complete the handshake, then that is
no longer possible.

It's certainly true that the use of exporter keys to encrypt the Finished
message does not
threaten the security of the TLS handshake. What it does, as I understand
it, is make
it problematic to separately analyze the QUIC record layer from the TLS
handshake
(in the same way as encrypting the TLS handshake with the application layer
record
keys makes it problematic to analyze the TLS handshake separately from the
TLS
application layer, which is why TLS 1.3 is designed the way it is).

> https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.

Yes. Apologies for not catching this sooner.

-Ekr

---

From: David Benjamin <[email-masked]>
Date: Fri, 03 Feb 2017 16:04:02 +0000

On Fri, Feb 3, 2017 at 10:59 AM Eric Rescorla <[email-masked]> wrote:

Ah, I see. Thanks! There's the disconnect. The worry was it being difficult
to analyze QUIC's record layer independent of the handshake, rather than
the other way around. The inverse claim made no sense to me, but this one
sounds more plausible.

-Ekr

David

-Ekr

Ekr's

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 3 Feb 2017 08:45:11 -0800

> tools are designed to analyze the handshake and record layer separately
> and so if you
So there are tools that can analyze the handshake and record layer
together? If so, why don't we employ those? I'd be interested in an
analysis of TLS1.3 + QUIC anyways -- do we have folks who'd be willing to
do this?

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 3 Feb 2017 08:57:42 -0800

> analysis of TLS1.3 + QUIC anyways -- do we have folks who'd be willing to

Apologies for not being clear: I was asking about analyzing the handshake
when we don't use the Finished message before using the 1-RTT keys in the
case where there's no client authentication.

That said, this is a bit of a bummer because of the possibility of HoL
blocking, but I don't think this is a show stopper. We could simply say
that the server MUST receive the Finished message before using the 1-RTT
keys and come back to this when we have more analysis of the handshake.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 3 Feb 2017 09:00:14 -0800

> analysis of TLS1.3 + QUIC anyways -- do we have folks who'd be willing to

I may have given a confusing impression of the situation here.

The state of play of analysis for this kind of protocol is that we have a
bunch of different tools [0]
that can analyze the protocol from different angles and together they give
a sort of composite
picture of the security of the system. Some of these tools do OK with
combined analysis of
handshake and record and some do not, but it's not like we just need to hit
it with a bigger
hammer and we'll know everything, at least not at the current level of
available tooling.

-Ekr

[0] And some of these "tools" are just analysis methodology, not software.

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 3 Feb 2017 08:59:26 -0800

On Fri, Feb 3, 2017 at 8:57 AM, Jana Iyengar <[email-masked]> wrote:

>>> have to use the record layer keys to complete the handshake, then that
>>> is no longer possible.
>>>
>>>

... and we can add ekr's+davidben's modification as a potential
optimization that a client could employ.

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 3 Feb 2017 09:07:09 -0800

On Fri, Feb 3, 2017 at 9:00 AM, Eric Rescorla <[email-masked]> wrote:

> handshake and record and some do not, but it's not like we just need to
> hit it with a bigger

Gotcha -- thanks for clarifying. It seems like we probably want to go
forward with requiring Finished and not encrypting it with 1-RTT keys then.
Does that sound right?

- jana

---

From: Victor Vasiliev <[email-masked]>
Date: Sat, 4 Feb 2017 01:07:58 -0500

Thank you for the analysis.  I was trying to write my own, but yours is
better
than what I would end up writing anyways :)

I am still not entirely convinced of the "handshake should not depend on
record
layer" approach.  Security of QUIC+TLS depends on (1) handshake being
secure,
and (2) record layer being secure provided the keys derived from the
handshake.
If we are not sure our record layer provides the security guarantees that we
want, that would be very concerning.  If there are pieces other than the
handshake and the record layer, their security has to be verified
independently
anyways.  So I would not be that hesitant to rely on record layer security
assumptions.

Now, since
  (1) the client and the server are the only parties which know the secret,
  (2) the client traffic key is only used by the client,
  (3) the AEAD data is protected by a MAC, and
  (4) the MAC used is at least weakly unforgeable,
receiving any message authenticated with the MAC from the client proves that
client possesses the same key as the server.  Of course, this is not
*strictly*
equivalent to the Finished message since the Finished message is an HMAC of
the
entire handshake with a somewhat different key (actually, it's MAC'd twice
with
different similarly-derived keys, but let's not talk about this).  Still,
this
does confirm key possession, and unless you are concerned that your MAC
could
have been downgraded to something insecure during the handshake while the
HMAC
is still secure (which I assume is an issue for the security analysis of the
protocol anyways, since the same AEAD scheme protects your handshake), I
don't
really see how confirming the key via a MAC existing is worse than
confirming
the key via a MAC of the handshake. The exporter key is derived from the
same
transcript that is being MAC'd in the Finished message, so if the client
derives the same key, it has seen the same handshake.

I do agree that it would be really nice to reuse the existing formal
analysis,
if only for the fact that I wouldn't want to formalize the paragraph above
myself :)
Yet from a pragmatic engineering perspective, since I do not expect formal
code
verification to be widespread in QUIC libraries for the foreseeable future,
the
simplicity of the implementation (both in terms of wire protocol and
prescribed
behavior) should be prioritized over the simplicity of the proofs.  This
thread
has had some interesting workarounds for the HOL blocking issue, but they
all
sound overly complicated for solving a problem which might not be that much
of
an issue given that:
  (1) It's not clear HOL blocking is a noticeable performance hit here.  I
seem
      to recall we used to have a similar problem with SHLO loss, and
concluded
      that the workaround was not really worth it.
  (2) It's not clear that not waiting for client Finished is actually
depriving
      us of any security guarantees TLS normally promises (as far as I have
      read, it never explicitly promises aliveness verification for the
peer).
  (3) It's not clear that the protocol does not provide the desired extra
      security properties as-is via the record layer.
These three points together make me feel like adding an extra packet format
variation just to deal with client Finished HOL blocking is somewhat
far-fetched at this point.

---

From: Martin Thomson <[email-masked]>
Date: Sat, 4 Feb 2017 20:09:51 +1100

On 3 February 2017 at 23:04, Eric Rescorla <[email-masked]> wrote:
> TLS 1.3 uses a different handshake key than traffic key.)

*facepalm* of course.

> However, if you

That's not so simple.  We'll have to be very careful with this one.  I
have an idea, but it depends on having "special packets" more fully
fleshed out.

---

From: Ted Hardie <[email-masked]>
Date: Mon, 6 Feb 2017 11:24:40 -0800

> have an idea, but it depends on having "special packets" more fully
So, to just to confirm the state of play by returning to Martin's original
set of choices, we had:

> works, we could be back into RTO space here.)

One is always possible, but it doesn't optimize anything much, so we can
leave it off the table until we've decided that anything that does optimize
this flow isn't workable or worth it.

Three is testable:  are we certain that generating a redundant ACK for the
ClientHello triggers retransmission?  There are going to be cases where
this is needed anyways, so it seems worth testing whether it is used in
this hack or not.  If it does work, it's still less optimized that 2, but
we could leave it on the table.

In two, the concern is that including the Finished message, which is
encrypted with TTL handshake keys, in packets that are also encrypted using
the QUIC 1-RTT keys will make formal analysis of the security state lose
the independence of the handshake and record layers that is a desired
design goal.

Ekr suggested that we resolve this by using explicit lengths here, rather
than padding to the end of the frame; that would allow, at least in some
cases, the client to generate two packets within one datagram.  David
Benjamin suggested that we include the Finished message in all packets
until acknowledged.  Several people have since suggested combining the
two.

That would appear to me to mean using explicit lengths and the two-packets
per datagram theory until Finished is acknowledged, but correct me if I
have combined David and ekr's ideas in a way different than folks presumed.

Is that a reasonable summary?

Additional questions:

Speaking personally, I'm a bit worried about the theory in which we combine
two packets into a single datagram, as I'm not clear how much receiver
stacks would have to change to do that unpacking correctly.  I can imagine
them doing the wrong thing (in multiple ways) when encountering a second
set of headers within the same datagram.  Are there examples of this
approach in use already that we can use to guide us?

The usual way to avoid that problem but keep the main idea seems to be
generating an enveloping mechanism that allows the second packet to be
within a payload section of the (now only) packet within the datagram.  But
doing so requires us to find an enveloping mechanism that doesn't generate
the same problem in formal analysis.    As I look at that, I can't see any
reason why that enveloping mechanism would actually need to enclose a valid
packet (rather than Finished message), so we might be able to do this by
adding a Flag to the quic common header like "BonusFinish" and then having
a Finished message jammed in the type dependent field.  The semantics here
would be that this packet contains a bonus finish message in the header, as
well as QUIC common packet.  That could be included until acknowledged.
The Finished message would still be encrypted by the TTL handshake key, but
it would be outside the payload encrypted by the 1-RTT keys.

Does the authentication of the headers generates the same formal analysis
problem?.  Can we encode the Finished message in a type dependent fields?
Are there other problems with this approach that I'm missing?

thanks,

Ted

---

From: Martin Thomson <[email-masked]>
Date: Tue, 7 Feb 2017 12:16:52 +1100

On 7 February 2017 at 06:24, Ted Hardie <[email-masked]> wrote:
> problem?.

Hmm, probably.  I had been considering an approach where you had a
special packet type that included a length-prefixed finished in the
header, with the tail of the packet being 1-RTT protected.  However,
you are right that this triggers the problem because the finished
might be seen as part of the header and we've agreed to integrity
protect the header.

> Can we encode the Finished message in a type dependent fields?

Maybe, but perhaps only if it is outside of the authenticated data,
which might be OK if we are still able to authenticate the *existence*
of the finished, but it could accidentally leave us with a design for
unauthenticated extensions to the header.  I'm not sure that I'm happy
about that as an outcome.

Jana just reminded me that they ran an experiment regarding HOLB at
the server: originally server packets were protected with 0-RTT keys
immediately after the handshake, but the experiment fairly
conclusively determined that protecting packets with 1-RTT keys didn't
affect application metrics by any observable amount.  Since using
1-RTT keys created a dependency on the SHLO in much the same way that
we're dependent on the client Finished, I wonder if the reciprocal
arrangement (i.e., option 1: wait it out) would have a similarly
trivial impact.

In other words, maybe we should measure before we waste even more time on this.