Subject: Simplify ACK frame retransmission

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Tue, 5 Dec 2017 09:13:48 -0800

What is the value in retransmitting ACK frames as opposed to either just

A) periodically send ACK frames.
or
B) realize an ACK frame was lost and send ACK frames earlier than otherwise
planned.
or
C) keep the span of the ACK frame for retransmission, but not any gap
details.

I define a span to be the min..max range of all packet numbers in an ACK
frame including gaps.

There is a lot of bookkeeping in tracking the exact ACK frame content which
does not at all seem very useful.
If more detail is needed beyond sending the current ACK state it would also
be possible and practical to store the min and max packet number in a
transmitted ACK frame such that if it is later considered lost, a new ACK
frame can be send which will attempt to cover that range while prioritising
most recent in case of space limitations.

An implementation could be free to choose between option A, B, or C. This
is sort af analogous to not retransmitting MAX values but rather sending
updated information in case of loss.

It is also not fully clarified if multiple ACK frames can exist in a packet
with different or overlapping spans.

I could open an issue, but there are so many different ACK frame issues
that I thought it better to take it on the list, at least initially.

Kind Regards,
Mikkel Fahnøe Jørgensen

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 5 Dec 2017 10:22:41 -0800

Hi Mikkel,

ACK frames are not retransmitted, see Section 9
<https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#rfc.section.9>
of
the transport draft. ACK frames are sent in response to received frames
that elicit one, but no more. Not all frames elicit acks, as specified in
Section 9.
In general, tracking ACK loss is difficult, since ACKs don't elicit ACKs
from the peer... so doing things based on ACK loss detection tends to be
difficult.

- jana

On Tue, Dec 5, 2017 at 9:13 AM, Mikkel Fahnøe Jørgensen <[email-masked]>
wrote:

> B) realize an ACK frame was lost and send ACK frames earlier than
> otherwise planned.
> or
> There is a lot of bookkeeping in tracking the exact ACK frame content
> which does not at all seem very useful.
> If more detail is needed beyond sending the current ACK state it would
> also be possible and practical to store the min and max packet number in a
> It is also not fully clarified if multiple ACK frames can exist in a
> packet with different or overlapping spans.
>

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Tue, 5 Dec 2017 11:13:15 -0800

Oh great thanks,

I have missed this change (in both senses).

Many things have happened since I last had time to put some serious effort
into QUIC.

Now most of my major concerns have been addressed:

- ack transmission is reasonably friendly (no timestamp bookkeeping, no
retransmission bookkeeping) (but still difficult to understand text for ACK
frame) - not sure about dropping the float16 format, but it was hard to
document.
- client ID is maintained throughout handshake and optional server ID is,
or will be, known by separate field (TLS params)
- protection against off-path clear text attacks.
- non-unique 5-tuples are possible without loosing connection state -
simplifying server to server with raw socket like interfaces and avoiding
ephemeral port exhausting.
- much simpler stream state diagram (no dual purpose RST stream, no ACK
needed before transition).
- 0 padding is random on wire via clear text AEAD.
- initial packet has a well-defined 1200 byte length for all networks.
- bad packets are ignored rather than causing errors during early handshake
(at least in some cases) - prevents off-path DoS.
- Stream ID is has sufficient range - allows for throw away streams needed
for partial reliability and for game server state updates.
- frame header encoding with varints rather than obscure frame type bits.
- uni-directional streams that can close without peer response (although
still with bidi complexity).
- no random packet number jumps except at new connection ID allowing for
compact data structures (but I think the random 32-bit gap at migration
might be used to exhaust the packet number space prematurely, but you can
just limit the number of acceptable migrations).
- single frame async messages are now possibly, indirectly, via Ping or
uni-streams.

I really would like a QUIC version that only depends on AES, curve25519
(and/or possibly salsa/poly) and ed25519 OpenSSH keys and certs to avoid
heavy TLS libraries, but this is still possible with a custom QUIC version.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 5 December 2017 at 19.22.43, Jana Iyengar ([email-masked]) wrote:

Hi Mikkel,

- jana

---

From: Martin Thomson <[email-masked]>
Date: Wed, 6 Dec 2017 11:06:27 +1100

> heavy TLS libraries, but this is still possible with a custom QUIC version.

Apart from the OpenSSH part, this is all possible right now with a
profile of TLS.  (I guess you mean raw public keys without X.509). All
of what you describe is negotiable in TLS.

You might not interoperate with many implementations, but it is
possible, especially if you don't care for much interoperability.  The
biggest interoperability losses are where you go from X.509 to raw
public keys (that is, RFC 7250), but Ed25519 is also only starting to
be implemented.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 6 Dec 2017 04:19:22 -0800

Kind Regards,
Mikkel Fahnøe Jørgensen

On 6 December 2017 at 01.06.28, Martin Thomson ([email-masked])
wrote:

That is good to hear, but I believe the TLS1.3-22 draft requires RSA PKCS1
signatures which is the heavy part (RFC8017) and the draft does not appear
to make this negotiable from what I can tell. If it allowed Ed25519 only
with X25519 Key Exchange, the only big issue would be the certificate
format.

https://tools.ietf.org/html/draft-ietf-tls-tls13-22#section-9.1

A TLS-compliant application MUST support digital signatures with
   rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for
   CertificateVerify and certificates), and ecdsa_secp256r1_sha256.  A
   TLS-compliant application MUST support key exchange with secp256r1
   (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748
<https://tools.ietf.org/html/rfc7748>].

As to Raw vs OpenSSH I will have to study the details further. Getting rid
of DER would be very nice, but it can be overcome, but there is more to it.
One part is the file/blob format, another is the metadata such as domain
and expiration date, and the third is the tooling around it. OpenSSH has
simple tooling and it can also be re-implemented standalone with just an
Ed/X25519 library and simple blob parser/printer (I can open source one if
anyone is interested). The alternative is to deal with OpenSSL tools and
rather convoluted CA mechanisms and possibly trust chains. But I do
acknowledge that the public internet evolves around these types of
certificates and that this is unlikely to change.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 6 Dec 2017 04:21:04 -0800

That mail came out strange, but see inline comments in previous mail, it is
not empty.

On 6 December 2017 at 13.19.22, Mikkel Fahnøe Jørgensen ([email-masked])
wrote:

Kind Regards,
Mikkel Fahnøe Jørgensen

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 6 Dec 2017 06:20:00 -0800

On Wed, Dec 6, 2017 at 4:19 AM, Mikkel Fahnøe Jørgensen <[email-masked]>
wrote:

> to make this negotiable from what I can tell.
>
This is just an interop requirement. I.e., if you don't do this then you
will not be able to talk to the large number of servers who have RSA only
keys embedded in PKCS#1 certs. It's quite possible to just support Ed25519,
and you say so using the signature_algorithms extension. Obviously, if you
say that, then you will have a handshake failure with anyone without a
suitable key, but in a closed world that's fine. IMO it would be better to
advertise the usual TLS/QUIC versions and be officially non-compliant than
have a new version that differed only along this axis. I imagine we could
put in some weasel words if necessary about closed environments.

Ironically, I just debugged a failure of this type.

> If it allowed Ed25519 only with X25519 Key Exchange, the only big issue
> would be the certificate format.
>

>    (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748 <https://tools.ietf.org/html/rfc7748>].
>
>
> certificates and that this is unlikely to change
>
I'm having trouble visualizing your environment here. Are you doing TOFU,
in which case this is just an issue of transporting the keys, or are you
actually operating some kind of CA system? In any case, it's also possible
to add OpenSSH certificates to TLS (it's just a code point), but I would
generally not be in favor of that unless it was really needed.

-Ekr

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 6 Dec 2017 07:25:08 -0800

Answers inline below

That would be fine with me, it is just that MUST in TLS sec. 9.1 is a
strong word, so you couldn’t really say you use TLS1.3 and hence not QUIC,
unless some permission was granted towards this use case.

The environment is not fully fleshed out but in summary it is about server
to server peer networking with multiple levels of trust and satellite
access. Satellites might be non-standard low resource systems.

I do have CA in mind, but for simpler use cases TOFU (trust on first sight)
pointing to an authorized_keys file is also a consideration.

I want some very trusted central piece of software to create and sign certs
that other parties trust in order to establish a peer to peer server
network. Shamirs Shared Secret could be part of the setup. In this case the
minimum complexity needed to implement a CA is desirable and
OpenSSH/Ed25519 is close to that as a model even if not using OpenSSH
software directly.

In addition, external parties might want to join a sub-net or create their
own compatible key management infrastructure. In this case OpenSSH tooling
is much simpler to use than OpenSSL and something operators do regularly
for SSH login. It is beneficial that some server software can be configured
to accept such a user provided key. Notably users might feel better knowing
a key is generated by a piece of software they know and trust.

The above does not require that QUIC uses OpenSSH directly, just that there
is a low-cost translation.

The use of DNS based auth is not very useful when network addresses might
be routed on overlay networks and/or having address that are not advertised
by DNS, or when not having any meaningful address at all (e.g. content
based routing). Even without SSH tooling, it is reasonably easy to
implement custom tools based on the same concept when the underlying
primitives are largely the same.

Some of this is not directly applicable to QUIC because it operates trust
at a higher level, but such a system must still manage the keys used by
QUIC connections and it is preferable that all components can agree on the
basic primitives.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 6 Dec 2017 10:21:18 -0800

> unless some permission was granted towards this use case.

Well, you would be a nonconformant QUIC implementation. It's not like
you're going to get arrested.

> I do have CA in mind, but for simpler use cases TOFU (trust on first
> sight) pointing to an authorized_keys file is also a consideration.
>
> I want some very trusted central piece of software to create and sign
> certs that other parties trust in order to establish a peer to peer server
> The above does not require that QUIC uses OpenSSH directly, just that
> there is a low-cost translation.
>
OK.  Well, I'm generally not that enthusiastic about inventing cert
formats, but there's no technical obstacle that I know of.

-Ekr

---

From: Victor Vasiliev <[email-masked]>
Date: Wed, 6 Dec 2017 13:55:35 -0500

On Wed, Dec 6, 2017 at 10:25 AM, Mikkel Fahnøe Jørgensen <[email-masked]

> unless some permission was granted towards this use case.

My reading of the spec is that application profile can override any
requirement of section 9.1.   The spec wording is somewhat ambiguous here,
but I see no reason it could change ciphers, but not signature algorithms.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 6 Dec 2017 11:02:07 -0800

On Wed, Dec 6, 2017 at 10:55 AM, Victor Vasiliev <[email-masked]> wrote:

> On Wed, Dec 6, 2017 at 10:25 AM, Mikkel Fahnøe Jørgensen <
> [email-masked]> wrote:
>
>> Answers inline below
>>
>>
>> That is good to hear, but I believe the TLS1.3-22 draft requires RSA
>>> PKCS1 signatures which is the heavy part (RFC8017) and the draft does not
>>> appear to make this negotiable from what I can tell.
>>>

I agree with that, but I don't think we should override that requirement
for the IETF standard version of QUIC, because the same deployment
considerations apply here. I agree that were Mikkel to write such a
profile, that could override this.

-Ekr

---

From: Mike Bishop <[email-masked]>
Date: Wed, 6 Dec 2017 19:08:00 +0000

Here’s the thing:  The IETF writes specifications, but doesn’t do certifications of conformance.  If you want to deploy something that doesn’t conform to the specification, what you lose is interoperability.  If you want interop, write up a doc and publish it (independent submission, AD-sponsored, non-IETF venue, etc.), and register an appropriate IANA codepoint for your variant.  If you don’t care about interop, then you’re not going to be sued for using the names TLS 1.3 or QUIC.

From: QUIC [mailto:[email-masked]] On Behalf Of Mikkel Fahnøe Jørgensen
Sent: Wednesday, December 6, 2017 7:25 AM
To: Eric Rescorla <[email-masked]>
Cc: Jana Iyengar <[email-masked]>; IETF QUIC WG <[email-masked]>; Martin Thomson <[email-masked]>
Subject: Re: Simplify ACK frame retransmission

Answers inline below

That is good to hear, but I believe the TLS1.3-22 draft requires RSA PKCS1 signatures which is the heavy part (RFC8017) and the draft does not appear to make this negotiable from what I can tell.
This is just an interop requirement. I.e., if you don't do this then you will not be able to talk to the large number of servers who have RSA only keys embedded in PKCS#1 certs. It's quite possible to just support Ed25519, and you say so using the signature_algorithms extension. Obviously, if you say that, then you will have a handshake failure with anyone without a suitable key, but in a closed world that's fine. IMO it would be better to advertise the usual TLS/QUIC versions and be officially non-compliant than have a new version that differed only along this axis. I imagine we could put in some weasel words if necessary about closed environments.

That would be fine with me, it is just that MUST in TLS sec. 9.1 is a strong word, so you couldn’t really say you use TLS1.3 and hence not QUIC, unless some permission was granted towards this use case.

As to Raw vs OpenSSH I will have to study the details further. Getting rid of DER would be very nice, but it can be overcome, but there is more to it. One part is the file/blob format, another is the metadata such as domain and expiration date, and the third is the tooling around it. OpenSSH has simple tooling and it can also be re-implemented standalone with just an Ed/X25519 library and simple blob parser/printer (I can open source one if anyone is interested). The alternative is to deal with OpenSSL tools and rather convoluted CA mechanisms and possibly trust chains. But I do acknowledge that the public internet evolves around these types of certificates and that this is unlikely to change
I'm having trouble visualizing your environment here. Are you doing TOFU, in which case this is just an issue of transporting the keys, or are you actually operating some kind of CA system? In any case, it's also possible to add OpenSSH certificates to TLS (it's just a code point), but I would generally not be in favor of that unless it was really needed.

The environment is not fully fleshed out but in summary it is about server to server peer networking with multiple levels of trust and satellite access. Satellites might be non-standard low resource systems.

I do have CA in mind, but for simpler use cases TOFU (trust on first sight) pointing to an authorized_keys file is also a consideration.

I want some very trusted central piece of software to create and sign certs that other parties trust in order to establish a peer to peer server network. Shamirs Shared Secret could be part of the setup. In this case the minimum complexity needed to implement a CA is desirable and OpenSSH/Ed25519 is close to that as a model even if not using OpenSSH software directly.

In addition, external parties might want to join a sub-net or create their own compatible key management infrastructure. In this case OpenSSH tooling is much simpler to use than OpenSSL and something operators do regularly for SSH login. It is beneficial that some server software can be configured to accept such a user provided key. Notably users might feel better knowing a key is generated by a piece of software they know and trust.

The above does not require that QUIC uses OpenSSH directly, just that there is a low-cost translation.

The use of DNS based auth is not very useful when network addresses might be routed on overlay networks and/or having address that are not advertised by DNS, or when not having any meaningful address at all (e.g. content based routing). Even without SSH tooling, it is reasonably easy to implement custom tools based on the same concept when the underlying primitives are largely the same.

Some of this is not directly applicable to QUIC because it operates trust at a higher level, but such a system must still manage the keys used by QUIC connections and it is preferable that all components can agree on the basic primitives.