On 12/06/2024 02:36, Nick Harper wrote:
If Trust Expressions does meaningfully change the calculus compared to
certificate_authorities, it does it in a way that lessens risk. The
certificate_authorities extension doesn't scale support the legitimate
use case of trust negotiation/advertisement
On Wednesday, 12 June 2024 02:02:41 CEST, D. J. Bernstein wrote:
There will be an annoyingly large number of options on the PQ side---for
example, for different security levels and for patent avoidance---and
I'd expect a tricky discussion of which options to recommend for TLS.
I'm not sure I buy
This email starts the working group last call for "Bootstrapping TLS Encrypted
ClientHello with DNS Service Bindings” I-D, located here:
https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/
The WG Last Call will end 26 June 2024 @ 2359 UTC.
Please review the I-D and submit issues and pull
Yes, my worry is really around enforcement of a property that can’t be strictly
adhered to. How about something along the lines of:
Until receiving a KeyUpdate from the peer, the sender MUST NOT send
another KeyUpdate with request_update set to "update_requested".
Note that implement
Works for me! Updated the PR with your suggestion (plus one extra word to
be clear it's a subsequent KeyUpdate and not a random past one).
On Wed, Jun 12, 2024 at 3:56 PM Kyle Nekritz wrote:
> Yes, my worry is really around enforcement of a property that can’t be
> strictly adhered to. How about
Hi! Just reminder to get any concerns about merging these in by 17 June 2024.
spt
> On Jun 3, 2024, at 11:38, Sean Turner wrote:
>
> Since draft-ietf-tls-rfc8446bis last completed WGLC, two PRs have been
> submitted (and discussed) that include changes to normative language:
>
> - #1343: Forb
On Wed, Jun 12, 2024 at 3:17 AM Dennis Jackson
wrote:
> You can't argue that T.E. contains the functionality of
> certificate_authorities as a subset, then conclude that having additional
> functionalities makes it less risky. You would need to argue the exact
> opposite, that T.E. doesn't contai
I had one comment earlier that seems to have been missed [0].
Basically I was wondering if it may be useful to use stronger language
in the draft to indicate a client MUST use Port Prefix Naming when
looking up the SVCB record.
Regards,
Raghu Saxena
[0] https://mailarchive.ietf.org/arch/msg
