Joseph Salowey writes:
> The last call has come and gone without any comment. Please indicate if
> you have reviewed the draft even if you do not have issues to raise so the
> chairs can see who has reviewed it. Also indicate if you have any plans to
> implement the draft.
I looked at the
One question that I have after reading it: I understand why one wants to
implement this extension, but I don’t see how the two endpoints would arrive at
that external PSK.
Sadly - we're back to the 1980's in terms of key management. The obvious
answers are a) they meet to exchange keys, b)
On 5/20/2019 3:41 PM, Blumenthal, Uri - 0553 - MITLL wrote:
I reviewed this draft (“browsed through” would be a more honest
statement). I didn’t spot an obvious problem with it.
One question that I have after reading it: I understand why one wants
to implement this extension, but I don’t
I reviewed this draft (“browsed through” would be a more honest statement). I
didn’t spot an obvious problem with it.
One question that I have after reading it: I understand why one wants to
implement this extension, but I don’t see how the two endpoints would arrive at
that external PSK.
TLS 1.3 Extension for Certificate-based Authentication with an External PSK
ensures the US Government has a quantum-resistant option for TLS in the interim
years until post-quantum algorithms emerge from the NIST process. For this
reason, there is an intent to specify this extension in future
Greetings,
FYI - This report has been deleted as junk.
Thank you.
RFC Editor/mf
On May 17, 2019, at 2:06 PM, RFC Errata System
wrote:
> The following errata report has been submitted for RFC5246,
> "The Transport Layer Security (TLS) Protocol Version 1.2".
>
>
Martin Rex writes:
>BEAST is an attack against Web Browsers (and the abuse known as SSL-VPNs), it
>is *NO* attack against TLS
That actually applies to an awful lot of recent attacks on TLS - they're
attacks that rely on web software that's actively cooperating with the
attacker, not attacks on
