Hi Victor,
For HTTP/2, this is essentially a noop, as endpoints are required to send
SETTINGS immediately. Whether these bytes appear before Finished or not only
affects endpoints that aren't inclined to wait for SETTINGS. This is somewhat
complicated by the way that TLS 1.2 and TLS 1.3 diffe
Thanks for this draft. I believe this is an important problem for HTTP
extensibility, and I'm glad to see work on a solution.
It occurs to me that this solution requires pretty tight integration
between the TLS termination and the HTTP backend. Some TLS load balancers
already support ALPN, but t
Dear WG,
I've taken a look at the draft and I think while its discussion of the
properties and limitations of the external PSKs are good, I think the
recommendations in section 7 could use some minor editorial work.
In particular "SHOULD be combined with a DH exchange for forward
secrecy." I wou
Hello TLS and HTTP working groups,
(QUIC WG bcc'd as this has been discussed there before)
Currently, we use SETTINGS frames as an extensibility mechanism in HTTP/2
and HTTP/3. The SETTINGS frame is sent at the very beginning of TLS
application data; this approach, while simple, has some drawbac
> -Original Message-
> From: Mohit Sethi M
> Sent: Monday, July 6, 2020 3:10 AM
> To: Jim Schaad ; draft-ietf-tls-external-psk-
> guida...@ietf.org
> Cc: tls@ietf.org
> Subject: Re: Review of draft-ietf-tls-external-psk-guidance-00
>
> Hi Jim,
>
> Thanks for the review. A clarifying q
Hi Jim,
Thanks for the review. A clarifying question in-line.
On 7/2/20 12:02 AM, Jim Schaad wrote:
> * In section 4 there is a statement that switching the roles of servers
> which use PSKs will lead to weakening of security properties. As this is a
> common scenario today in situations where y
