Re: Simplify ACK frame retransmission

[Eric Rescorla <[e-mail]>]

On Wed, Dec 6, 2017 at 7:25 AM, Mikkel Fahnøe Jørgensen <[e-mail]>
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.
>>
> 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.
>

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




> 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.
>
OK.  Well, I'm generally not that enthusiastic about inventing cert
formats, but there's no technical obstacle that I know of.

-Ekr