Re: Simplify ACK frame retransmission

[Victor Vasiliev <[e-mail]>]

On Wed, Dec 6, 2017 at 10: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.
>

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.