RE: Simplify ACK frame retransmission

[Mike Bishop <[e-mail]>]

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:[e-mail]] On Behalf Of Mikkel Fahnøe Jørgensen
Sent: Wednesday, December 6, 2017 7:25 AM
To: Eric Rescorla <[e-mail]>
Cc: Jana Iyengar <[e-mail]>; IETF QUIC WG <[e-mail]>; Martin Thomson <[e-mail]>
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.