I think the answer is clear: No, we should not accept both labels. We should
simply fix it to say EARLY_EXPORTER_SECRET and move on.
That’s fine with me. I was honestly just asking.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to t
Accepting both labels gets super messy because then we have to make a bunch
of decisions like whether you output both labels on the logging side.
But we can just do a bit of research here:
- In IETF land, EARLY_EXPORTER_MASTER_SECRET dates to the start of the I-D,
but...
- The shorter EXPORTER_SEC
Changing it would be incompatible, but at a glance it looks like
EARLY_EXPORTER_MASTER_SECRET is the only label that would be impacted? We
definitely should not rename that to ...MAIN... because that's not the new
name. It's simply EARLY_EXPORTER_SECRET.
As for the right name, maybe we can still r
On Fri, Feb 7, 2025 at 1:55 PM David Benjamin wrote:
> Accepting both labels gets super messy because then we have to make a
> bunch of decisions like whether you output both labels on the logging side.
>
> But we can just do a bit of research here:
> - In IETF land, EARLY_EXPORTER_MASTER_SECRET
On Fri, Feb 7, 2025 at 9:44 AM Mike Shaver wrote:
> Hi Watson,
>
> On Thu, Feb 6, 2025 at 8:10 PM Watson Ladd wrote:
>
>> A negotiation where what is advertised is an inherently opaque
>> pointer, and where each side must maintain an idea of what that could
>> mean, does not have this property.
On Fri, Feb 7, 2025 at 12:17 PM David Benjamin
wrote:
> On Fri, Feb 7, 2025 at 9:44 AM Mike Shaver wrote:
>
>> Hi Watson,
>>
>> On Thu, Feb 6, 2025 at 8:10 PM Watson Ladd wrote:
>>
>>> A negotiation where what is advertised is an inherently opaque
>>> pointer, and where each side must maintain
The question is really "should we accept both names?"
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
Uploaded https://github.com/tlswg/sslkeylogfile/pull/22 to fix the typo.
On Fri, Feb 7, 2025 at 1:56 PM David Benjamin wrote:
> On Fri, Feb 7, 2025 at 1:55 PM David Benjamin
> wrote:
>
>> Accepting both labels gets super messy because then we have to make a
>> bunch of decisions like whether yo
On Fri, Feb 7, 2025 at 9:17 AM David Benjamin wrote:
>
> On Fri, Feb 7, 2025 at 9:44 AM Mike Shaver wrote:
>>
>> Hi Watson,
>>
>> On Thu, Feb 6, 2025 at 8:10 PM Watson Ladd wrote:
>>>
>>> A negotiation where what is advertised is an inherently opaque
>>> pointer, and where each side must maintai
I support adoption of [1] towards solving the problem identified during
October’s interim meeting. I anticipate the shape of the solution will change
in time as this group further develops the specification and acquires more
information through implementation and experimentation.
As with anythi
Hi Watson,
On Thu, Feb 6, 2025 at 8:10 PM Watson Ladd wrote:
> A negotiation where what is advertised is an inherently opaque
> pointer, and where each side must maintain an idea of what that could
> mean, does not have this property. Servers have to explicitly act to
> support the new identifie
Hi! The authors have merged draft-ietf-tls-ech-keylog file as was discussed and
decided during WGLC. I updated the “replaces” metadata for this I-D and
draft-ietf-tls-ech-keylog; as a result, the datatracker no longer shows
draft-ietf-tls-ech-keylog as a WG I-D. Expect a WGLC for
draft-ietf-tls
I read the draft. Looks good. Nice to see the word "octothorpe" instead of
pound sign, even if the document left of the last letter "e"
More seriously, should the draft allow the "new" terminology proposed in
8446bis (e.g., MAIN instead of MASTER etc)?
___
I don't think there's any new argument to address, so I will just offer
a pointers into where these issues are discussed in 'Trust is
non-negotiable'.
Section 3.3 [1] looks at how trust negotiation (as an abstract
mechanism) changes incentives to divergence for existing root programs,
as well
This email starts the 2nd working group last call for "The SSLKEYLOGFILE Format
for TLS” I-D, located here:
https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/
The WG Last Call will end 21 February 2025 @ 2359 UTC.
Please review the I-D, which now incorporates draft-ietf-tls-ech-keylogf
> On Feb 7, 2025, at 7:36 AM, Mike Shaver wrote:
>
> Hi Watson,
>
> On Thu, Feb 6, 2025 at 8:10 PM Watson Ladd wrote:
> A negotiation where what is advertised is an inherently opaque
> pointer, and where each side must maintain an idea of what that could
> mean, does not have this property. S
16 matches
Mail list logo
