[TLS] Re: 2nd Working Group Last Call for The SSLKEYLOGFILE Format for TLS

[Salz, Rich]

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 tls-le...@ietf.org

[TLS] Re: 2nd Working Group Last Call for The SSLKEYLOGFILE Format for TLS

[David Benjamin]

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_SECRET name for the non-early secret dates to the
earliest proposals for TLS 1.3 here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1287711
- BoringSSL does not output this label
- OpenSSL does not output this label
- NSS outputs this label but uses EARLY_EXPORTER_SECRET
- Wireshark consumes this label but uses EARLY_EXPORTER_SECRET

So I think EARLY_EXPORTER_MASTER_SECRET was just a typo and should always
have been EARLY_EXPORTER_SECRET. Unless there's any evidence that someone
actually relies on the EARLY_EXPORTER_MASTER_SECRET label (very, very
unlikely given both the history of early exporters and the history of this
SSLKEYLOGFILE integration), 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.

David

On Fri, Feb 7, 2025 at 1:33 PM Salz, Rich  wrote:

> 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

[TLS] Re: 2nd Working Group Last Call for The SSLKEYLOGFILE Format for TLS

[David Benjamin]

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 rename it? Does anyone even use
early exporters at all? I vaguely remember it being added for some QUIC or
tokbind thing that ultimately never actually materialized. BoringSSL
doesn't currently implement early exporters, so renaming it would not have
compatibility implications on our end.

(Actually it's kind of odd that one uses the old terminology but
EXPORTER_SECRET uses the new one. How'd we end up there?)


On Fri, Feb 7, 2025, 11:23 Salz, Rich 
wrote:

> 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)?
>
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: 2nd Working Group Last Call for The SSLKEYLOGFILE Format for TLS

[David Benjamin]

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 dates to the start of the
> I-D, but...
> - The shorter EXPORTER_SECRET name for the non-early secret dates to the
> earliest proposals for TLS 1.3 here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1287711
> - BoringSSL does not output this label
> - OpenSSL does not output this label
>

Correction: OpenSSL outputs this label but uses EARLY_EXPORTER_SECRET. Had
the wrong grep. :-)


> - NSS outputs this label but uses EARLY_EXPORTER_SECRET
> - Wireshark consumes this label but uses EARLY_EXPORTER_SECRET
>
> So I think EARLY_EXPORTER_MASTER_SECRET was just a typo and should always
> have been EARLY_EXPORTER_SECRET. Unless there's any evidence that someone
> actually relies on the EARLY_EXPORTER_MASTER_SECRET label (very, very
> unlikely given both the history of early exporters and the history of this
> SSLKEYLOGFILE integration), 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.
>
> David
>
> On Fri, Feb 7, 2025 at 1:33 PM Salz, Rich  wrote:
>
>> 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

[TLS] Re: PKI dynamics and trust anchor negotiation

[David Benjamin]

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. Servers have to explicitly act to
>> support the new identifier by getting a configuration that includes
>> it. Whether or not this is indirectly away as part of ACME doesn't
>> really change the equation. New clients can't count on server support,
>> unless they advertise an already existing value. There's been various
>> ways to express deltas to try to solve this, but they all involve
>> paying a penalty for deviation.
>>
>> The dynamic I'm worried about most then isn't fracturing: as you point
>> out there are some countervailing forces where people want easy
>> support. Rather it's that we artificially drive up the price of
>> picking different CAs than the dominant implementation.
>
>
> I very much share the concerns you've articulated here: increased barriers
> to entry both for new CAs and for new clients which have different
> root-management policies than the existing dominant implementation, and
> outsized penalties for differing from a "well-known set" as might happen
> from having tighter requirements on CA operation over time. The opaque
> token seems like it could lead to the properties that you (and I) wish to
> avoid, but when expressing my support for the group taking up the draft, I
> felt that the specific identifier form for trust anchors was still mutable,
> and therefore that it wasn't a barrier to draft adoption.
>
> If I have misunderstood, and identifiers must inherently be opaque in that
> way for all forms of trust anchors negotiation, then I appreciate the
> correction!
>

Hi Mike and Watson,

Hmm, well, if we have one concern that (against all realities of how PKIs
work) this will make it too easy for clients to pick different CAs, and
another concern that this will make it too hard, clearly we've struck a
happy medium and all is well! ;-D

More seriously, I completely agree that we need to avoid this. As valuable
as the existing CAs and root programs are, as much as I hope they continue
to be valuable, I think any design in this space which advantages and
grandfathers in existing players is simply bad for the internet. We are
dealing with inherently subjective delegations of trust here, and such
systems *need* room to change as trust evolves.

When Devon, Bob, and I worked on these initial drafts for TAI (and the
previous TE design), the three of us spent a lot of time thinking about
exactly this and trying to make sure we avoided such effects. So if you all
think we didn't quite get it right, that's very much something I care about
and would want to tweak accordingly---I mean, getting eyes on this beyond
the three of us is why I care about bringing the work here and having the
working group adopt and tweak it, despite the year's worth of aspersions
against my motivations that it has so tiringly engendered.

To that end, I don't think this design causes those problems. I'll explain
my thinking, and perhaps you all can poke holes in it if you think I've
missed something. (This is also something we can adjust post-adoption.
Procedurally, modifying things with WG consensus is very hard before
adoption–I would know, I've been trying all year!)

First, the identifiers in TAI are not meant to be some opaque thing,
representing some coupled mishmash of parameters. They represent the trust
anchor[1] and only the trust anchor. I think, if we had better trust anchor
negotiation, things like signature_algorithms_cert might have been
unnecessary because we *could* have just negotiated trust anchors, in a
world where we established a new root when adding a new incompatible sigalg
anyway. (And perhaps we should have? Have one joint and keep it well-oiled
and all.) But the extension itself doesn't take any opinion on this. It
expresses trust anchors, and if there are other TLS extensions that apply
other constraints, your server software is expected to continue to process
those as it always would.

Really, the only reason the IDs exist at all is that X.509 names are too
long. (Public Web PKI names are roughly 100 bytes.) X.509 conflates
identifying a CA with human-readable names for CAs, and ends up with
something that does a bad job of both. (Names of CAs are pretty meaningless
once keys change hands.) In another PKI design
,
these IDs could simply be what goes in the issuer field as-is. The thinking
was that when you stood up a CA, you would simply pick an ID, just as you
already have to pick a name. And if your CA predates this system, just go
ahead and allocate that ID now. This is also why we went with an OID-based
allocation, because it's reasonably compact and allows anyone to allocate
IDs without any fu

[TLS] Re: PKI dynamics and trust anchor negotiation

[David Benjamin]

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 an idea of what that could
>>> mean, does not have this property. Servers have to explicitly act to
>>> support the new identifier by getting a configuration that includes
>>> it. Whether or not this is indirectly away as part of ACME doesn't
>>> really change the equation. New clients can't count on server support,
>>> unless they advertise an already existing value. There's been various
>>> ways to express deltas to try to solve this, but they all involve
>>> paying a penalty for deviation.
>>>
>>> The dynamic I'm worried about most then isn't fracturing: as you point
>>> out there are some countervailing forces where people want easy
>>> support. Rather it's that we artificially drive up the price of
>>> picking different CAs than the dominant implementation.
>>
>>
>> I very much share the concerns you've articulated here: increased
>> barriers to entry both for new CAs and for new clients which have different
>> root-management policies than the existing dominant implementation, and
>> outsized penalties for differing from a "well-known set" as might happen
>> from having tighter requirements on CA operation over time. The opaque
>> token seems like it could lead to the properties that you (and I) wish to
>> avoid, but when expressing my support for the group taking up the draft, I
>> felt that the specific identifier form for trust anchors was still mutable,
>> and therefore that it wasn't a barrier to draft adoption.
>>
>> If I have misunderstood, and identifiers must inherently be opaque in
>> that way for all forms of trust anchors negotiation, then I appreciate the
>> correction!
>>
>
> Hi Mike and Watson,
>
> Hmm, well, if we have one concern that (against all realities of how PKIs
> work) this will make it too easy for clients to pick different CAs, and
> another concern that this will make it too hard, clearly we've struck a
> happy medium and all is well! ;-D
>
> More seriously, I completely agree that we need to avoid this. As valuable
> as the existing CAs and root programs are, as much as I hope they continue
> to be valuable, I think any design in this space which advantages and
> grandfathers in existing players is simply bad for the internet. We are
> dealing with inherently subjective delegations of trust here, and such
> systems *need* room to change as trust evolves.
>
> When Devon, Bob, and I worked on these initial drafts for TAI (and the
> previous TE design), the three of us spent a lot of time thinking about
> exactly this and trying to make sure we avoided such effects. So if you all
> think we didn't quite get it right, that's very much something I care about
> and would want to tweak accordingly---I mean, getting eyes on this beyond
> the three of us is why I care about bringing the work here and having the
> working group adopt and tweak it, despite the year's worth of aspersions
> against my motivations that it has so tiringly engendered.
>
> To that end, I don't think this design causes those problems. I'll explain
> my thinking, and perhaps you all can poke holes in it if you think I've
> missed something. (This is also something we can adjust post-adoption.
> Procedurally, modifying things with WG consensus is very hard before
> adoption–I would know, I've been trying all year!)
>
> First, the identifiers in TAI are not meant to be some opaque thing,
> representing some coupled mishmash of parameters. They represent the trust
> anchor[1] and only the trust anchor. I think, if we had better trust anchor
> negotiation, things like signature_algorithms_cert might have been
> unnecessary because we *could* have just negotiated trust anchors, in a
> world where we established a new root when adding a new incompatible sigalg
> anyway. (And perhaps we should have? Have one joint and keep it well-oiled
> and all.) But the extension itself doesn't take any opinion on this. It
> expresses trust anchors, and if there are other TLS extensions that apply
> other constraints, your server software is expected to continue to process
> those as it always would.
>
> Really, the only reason the IDs exist at all is that X.509 names are too
> long. (Public Web PKI names are roughly 100 bytes.) X.509 conflates
> identifying a CA with human-readable names for CAs, and ends up with
> something that does a bad job of both. (Names of CAs are pretty meaningless
> once keys change hands.) In another PKI design
> ,
> these IDs could simply be what goes in the issuer field as-is. The thinking
> was that when you stood up a CA, you would simply pick an ID, just as you
> already have to pick a name. And if your CA predates 

[TLS] Re: 2nd Working Group Last Call for The SSLKEYLOGFILE Format for TLS

[Salz, Rich]

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

[TLS] Re: 2nd Working Group Last Call for The SSLKEYLOGFILE Format for TLS

[David Benjamin]

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 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_SECRET name for the non-early secret dates to the
>> earliest proposals for TLS 1.3 here:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1287711
>> - BoringSSL does not output this label
>> - OpenSSL does not output this label
>>
>
> Correction: OpenSSL outputs this label but uses EARLY_EXPORTER_SECRET. Had
> the wrong grep. :-)
>
>
>> - NSS outputs this label but uses EARLY_EXPORTER_SECRET
>> - Wireshark consumes this label but uses EARLY_EXPORTER_SECRET
>>
>> So I think EARLY_EXPORTER_MASTER_SECRET was just a typo and should always
>> have been EARLY_EXPORTER_SECRET. Unless there's any evidence that someone
>> actually relies on the EARLY_EXPORTER_MASTER_SECRET label (very, very
>> unlikely given both the history of early exporters and the history of this
>> SSLKEYLOGFILE integration), 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.
>>
>> David
>>
>> On Fri, Feb 7, 2025 at 1:33 PM Salz, Rich  wrote:
>>
>>> 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

[TLS] Re: PKI dynamics and trust anchor negotiation

[Watson Ladd]

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 maintain an idea of what that could
>>> mean, does not have this property. Servers have to explicitly act to
>>> support the new identifier by getting a configuration that includes
>>> it. Whether or not this is indirectly away as part of ACME doesn't
>>> really change the equation. New clients can't count on server support,
>>> unless they advertise an already existing value. There's been various
>>> ways to express deltas to try to solve this, but they all involve
>>> paying a penalty for deviation.
>>>
>>> The dynamic I'm worried about most then isn't fracturing: as you point
>>> out there are some countervailing forces where people want easy
>>> support. Rather it's that we artificially drive up the price of
>>> picking different CAs than the dominant implementation.
>>
>>
>> I very much share the concerns you've articulated here: increased barriers 
>> to entry both for new CAs and for new clients which have different 
>> root-management policies than the existing dominant implementation, and 
>> outsized penalties for differing from a "well-known set" as might happen 
>> from having tighter requirements on CA operation over time. The opaque token 
>> seems like it could lead to the properties that you (and I) wish to avoid, 
>> but when expressing my support for the group taking up the draft, I felt 
>> that the specific identifier form for trust anchors was still mutable, and 
>> therefore that it wasn't a barrier to draft adoption.
>>
>> If I have misunderstood, and identifiers must inherently be opaque in that 
>> way for all forms of trust anchors negotiation, then I appreciate the 
>> correction!
>
>
> Hi Mike and Watson,
>
> Hmm, well, if we have one concern that (against all realities of how PKIs 
> work) this will make it too easy for clients to pick different CAs, and 
> another concern that this will make it too hard, clearly we've struck a happy 
> medium and all is well! ;-D
>
> More seriously, I completely agree that we need to avoid this. As valuable as 
> the existing CAs and root programs are, as much as I hope they continue to be 
> valuable, I think any design in this space which advantages and grandfathers 
> in existing players is simply bad for the internet. We are dealing with 
> inherently subjective delegations of trust here, and such systems *need* room 
> to change as trust evolves.
>
> When Devon, Bob, and I worked on these initial drafts for TAI (and the 
> previous TE design), the three of us spent a lot of time thinking about 
> exactly this and trying to make sure we avoided such effects. So if you all 
> think we didn't quite get it right, that's very much something I care about 
> and would want to tweak accordingly---I mean, getting eyes on this beyond the 
> three of us is why I care about bringing the work here and having the working 
> group adopt and tweak it, despite the year's worth of aspersions against my 
> motivations that it has so tiringly engendered.
>
> To that end, I don't think this design causes those problems. I'll explain my 
> thinking, and perhaps you all can poke holes in it if you think I've missed 
> something. (This is also something we can adjust post-adoption. Procedurally, 
> modifying things with WG consensus is very hard before adoption–I would know, 
> I've been trying all year!)
>
> First, the identifiers in TAI are not meant to be some opaque thing, 
> representing some coupled mishmash of parameters. They represent the trust 
> anchor[1] and only the trust anchor. I think, if we had better trust anchor 
> negotiation, things like signature_algorithms_cert might have been 
> unnecessary because we could have just negotiated trust anchors, in a world 
> where we established a new root when adding a new incompatible sigalg anyway. 
> (And perhaps we should have? Have one joint and keep it well-oiled and all.) 
> But the extension itself doesn't take any opinion on this. It expresses trust 
> anchors, and if there are other TLS extensions that apply other constraints, 
> your server software is expected to continue to process those as it always 
> would.

Silly clarification: the TAI identifier is just a compact identifier
for the root cert, like (making it up) a 4 byte identifier? So the
client sends the entire list of root certs supported, so about 100, so
400 bytes?

In that case I think you can inject it into an end-entity cert on
issuance, and into the root representations in the trust store. Where
this doesn't work out well is on cross signs where the cert can root
to multiple places/when more than one cert is needed to cover and the
config only has one, but this would solve a bunch of the issues for
command line programs where the trust store f

[TLS] Re: Adoption Call for Trust Anchor IDs

[Christopher Wood]

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 anything new, there are deployment considerations to be mindful of and 
risks to take into account. [2] identifies some of those risks. It’s clear that 
some of the risks are serious, but what's not clear — though has been argued — 
is that the likelihood of those risks will change substantially based on the 
solution space. I personally do not find these to be compelling arguments to 
stop exploring this solution space this early in the process. We benefit from 
the IETF’s inability to do anything quickly, giving us ample time to revisit 
and reevaluate potential risks over time. Should [1] be adopted, I expect the 
WG to seriously engage with that risk assessment throughout the process. 
Rigorous deployment considerations are no less required than security 
considerations, which are table stakes these days.

Finally, it’s true that the initial shape of a draft heavily influences its 
final shape, though I do not consider this to be a problem in practice. We are 
not obligated to publish anything here. This WG has abandoned plenty of adopted 
work items in the past, and I see no reason why we would not be comfortable 
doing the same here if the evidence suggests that is the best outcome for all 
relevant stakeholders, with preferential treatment towards end users.

Best,
Chris

> On Jan 15, 2025, at 10:59 AM, Joseph Salowey  wrote:
> 
> At the trust tussle Interim in October we had consensus that the working 
> group was interested in working on the following problem:
> 
> “Avoid client trust conflicts by enabling servers to reliably and efficiently 
> support clients with diverse trust anchor lists, particularly in larger PKIs 
> where the existing certificate_authorities extension is not viable”
> 
> After IETF 121, we asked for submissions for possible working group adoption 
> as a starting point for this work. We received two submissions:
> 
> [1] Trust Anchor Identifiers, draft-beck-tls-trust-anchor-ids-03 
> 
> [2] Trust is non-negotiable, draft-jackson-tls-trust-is-nonnegotiable-00 
> 
> [1] defines a new protocol mechanism, while [2] provides an explanation of 
> why the mechanism in [1] may not be needed and may be problematic. Since the 
> second draft does not define a protocol mechanism we are not considering it 
> for adoption, but we request that working group members review both documents 
> and use [2] as input into determining whether we should adopt [1] as a 
> working group item.  Adoption as a working group item means the working group 
> has change control over and can modify it as necessary; an adopted document 
> is only a starting point.  Please respond to this thread if you think the 
> document should be adopted as a working group item. If you think the document 
> is not appropriate for adoption please indicate why.  This adoption call will 
> close on February 7, 2025.  Also please remember to maintain professional 
> behavior and keep the discussion focused on technical issues.
> 
> Thanks,
> 
> Sean, Deirdre and Joe
> 
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: PKI dynamics and trust anchor negotiation

[Mike Shaver]

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 identifier by getting a configuration that includes
> it. Whether or not this is indirectly away as part of ACME doesn't
> really change the equation. New clients can't count on server support,
> unless they advertise an already existing value. There's been various
> ways to express deltas to try to solve this, but they all involve
> paying a penalty for deviation.
>
> The dynamic I'm worried about most then isn't fracturing: as you point
> out there are some countervailing forces where people want easy
> support. Rather it's that we artificially drive up the price of
> picking different CAs than the dominant implementation.


I very much share the concerns you've articulated here: increased barriers
to entry both for new CAs and for new clients which have different
root-management policies than the existing dominant implementation, and
outsized penalties for differing from a "well-known set" as might happen
from having tighter requirements on CA operation over time. The opaque
token seems like it could lead to the properties that you (and I) wish to
avoid, but when expressing my support for the group taking up the draft, I
felt that the specific identifier form for trust anchors was still mutable,
and therefore that it wasn't a barrier to draft adoption.

If I have misunderstood, and identifiers must inherently be opaque in that
way for all forms of trust anchors negotiation, then I appreciate the
correction!

Mike
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: I-D Action: draft-ietf-tls-keylogfile-03.txt

[Sean Turner]

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-keylogfile shortly.

spt

> On Feb 6, 2025, at 4:32 PM, internet-dra...@ietf.org wrote:
> 
> Internet-Draft draft-ietf-tls-keylogfile-03.txt is now available. It is a work
> item of the Transport Layer Security (TLS) WG of the IETF.
> 
>   Title:   The SSLKEYLOGFILE Format for TLS
>   Authors: Martin Thomson
>Yaroslav Rosomakho
>Hannes Tschofenig
>   Name:draft-ietf-tls-keylogfile-03.txt
>   Pages:   15
>   Dates:   2025-02-04
> 
> Abstract:
> 
>   A format that supports the logging information about the secrets used
>   in a TLS connection is described.  Recording secrets to a file in
>   SSLKEYLOGFILE format allows diagnostic and logging tools that use
>   this file to decrypt messages exchanged by TLS endpoints.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-tls-keylogfile-03.html
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-keylogfile-03
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: 2nd Working Group Last Call for The SSLKEYLOGFILE Format for TLS

[Salz, Rich]

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)?


___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: PKI dynamics and trust anchor negotiation

[Dennis Jackson]

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 as the consequences of enabling the deployment of new root 
programs with divergent policies. Unfortunately, fragmentation is often 
an insidious, gradual process that arises from many actors making 
independent decisions that prioritize their own needs, in the absence of 
any ecosystem forces strong enough to bring them together. It doesn't 
have to be a goal that is pursued deliberately, although it can also be 
(e.g. market differentiation or enshittification).


Separately, structural barriers to deployment of a new technology, which 
impact certain constituencies much more than others, are a common cause 
of ecosystem fragmentation. The specific design of TAI has serious 
issues in this regard which are laid out in section 4.6 [2].


The argument that this fragmentation is possible with existing 
mechanisms like certificate_authorities is evaluated at the end of the 
section 3.3 [3]. These extensions do not have any meaningful 
existence in the wild for the purposes of server certificate negotiation 
and it's running code that counts here. Further, for the same reasons 
that the TAI authors identified these extensions as an unsatisfactory 
solution for their needs, it is unsuitable for anyone else trying to 
deploy trust negotiation at scale.


Finally, as is discussed throughout Section 3, I disagree there is any 
security tradeoff at the heart of this issue. We've shipped many many 
improvements over the past 10+ years through the steady ratcheting of 
root program policies. Instead, I believe barriers to further 
improvements are predominantly found server-side, in the level of 
investment that server operators (and to a lesser extent CAs) are 
willing to make in terms of libraries, automation and tooling. Trust 
negotiation does nothing to address these issues, which are largely 
societal rather than technical.


Best,
Dennis

[1] 
https://datatracker.ietf.org/doc/html/draft-jackson-tls-trust-is-nonnegotiable#section-3.3


[2] 
https://datatracker.ietf.org/doc/html/draft-jackson-tls-trust-is-nonnegotiable#section-4.6


[3] 
https://datatracker.ietf.org/doc/html/draft-jackson-tls-trust-is-nonnegotiable#name-alternative-paths-to-abuse


___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] 2nd Working Group Last Call for The SSLKEYLOGFILE Format for TLS

[Sean Turner]

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-keylogfile, 
and submit issues and pull requests via the GitHub repository that can be found 
at:
 
https://github.com/tlswg/sslkeylogfile
 
Alternatively, you can also send your comments to tls@ietf.org.
 
Thanks,
spt
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: PKI dynamics and trust anchor negotiation

[Bob Beck]

> 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. Servers have to explicitly act to
> support the new identifier by getting a configuration that includes
> it. Whether or not this is indirectly away as part of ACME doesn't
> really change the equation. New clients can't count on server support,
> unless they advertise an already existing value. There's been various
> ways to express deltas to try to solve this, but they all involve
> paying a penalty for deviation.
> 
> The dynamic I'm worried about most then isn't fracturing: as you point
> out there are some countervailing forces where people want easy
> support. Rather it's that we artificially drive up the price of
> picking different CAs than the dominant implementation.
> 
> I very much share the concerns you've articulated here: increased barriers to 
> entry both for new CAs and for new clients which have different 
> root-management policies than the existing dominant implementation, and 
> outsized penalties for differing from a "well-known set" as might happen from 
> having tighter requirements on CA operation over time. The opaque token seems 
> like it could lead to the properties that you (and I) wish to avoid, but when 
> expressing my support for the group taking up the draft, I felt that the 
> specific identifier form for trust anchors was still mutable, and therefore 
> that it wasn't a barrier to draft adoption.

Without even considering the issues of what the identifier is (happy to think 
about it post adoption), if the draft was not mutable, then what’s the point in 
having a call for adoption with the working group to attempt to get to a place 
where we can have a collaborative effort?

> 
> If I have misunderstood, and identifiers must inherently be opaque in that 
> way for all forms of trust anchors negotiation, then I appreciate the 
> correction!

Speaking only as one of the authors, Why on earth would I go through this 
adoption process if I didn’t want the working group to actually assist in 
making the draft better.

If a draft has to be set in stone before being adopted, I can’t see a lot of 
value to sending it through the working group. 

> 
> Mike
> 
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org