Yes, I think information regarding if a cipher suite is for TLS 1.3 is very
needed to have. I already asked for that in
https://mailarchive.ietf.org/arch/msg/tls/0gDKfXJvAemFDm7MWcS1DTDVIe8/
In addition, I would also like to information if the cipher suite can be used
in QUIC.
(It is very hard
At the TLS meeting at IETF 118 there was significant support for the draft
'TLS 1.2 is in Feature Freeze' (
https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/) This call
is to confirm this on the list. Please indicate if you support the
adoption of this draft and are willing to review
On 12/5/2023 10:56 AM, Russ Housley wrote:
On Dec 5, 2023, at 12:01 PM, Christian Huitema wrote:
On 12/5/2023 8:13 AM, Russ Housley wrote:
At IETF 104, I presented a slide with informal reasoning about TLS 1.3 Security.
Authentication:
The certificate processing is exactly the same. It is
> On Dec 5, 2023, at 12:01 PM, Christian Huitema wrote:
>
> On 12/5/2023 8:13 AM, Russ Housley wrote:
>> At IETF 104, I presented a slide with informal reasoning about TLS 1.3
>> Security.
>> Authentication:
>> The certificate processing is exactly the same. It is not better or worse.
>> Key S
Thanks. This is interesting, but I think we should have a higher standard
than informal reasoning.
We know that there have been challenges around the composition of PSK and
certificates in the past (see Appendix E.1 of RFC 8446), so I think that's
especially true in this case.
-Ekr
On Tue, Dec
On 12/5/2023 8:13 AM, Russ Housley wrote:
At IETF 104, I presented a slide with informal reasoning about TLS 1.3 Security.
Authentication:
The certificate processing is exactly the same. It is not better or worse.
Key Schedule computation of Early Secret:
– Initial Handshake
Without ex
At IETF 104, I presented a slide with informal reasoning about TLS 1.3 Security.
Authentication:
The certificate processing is exactly the same. It is not better or worse.
Key Schedule computation of Early Secret:
– Initial Handshake
Without extension: HKDF-Extract(0, 0)
With ext
