Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt

[Bob Beck]

On Fri, Oct 27, 2023 at 9:06 AM David Benjamin 
wrote:

> Responses inline.
>
> On Fri, Oct 27, 2023 at 5:04 AM Michael P1  wrote:
>
>> Hi All,
>>
>> Thank you for this interesting draft, I had a couple of quick questions.
>>
>> OpenSSL has been mentioned in this thread, but I was wondering if you had
>> examples of other implementations or services that use the "key_share
>> first" algorithm outlined in Section 3.1 of the draft, so that as this
>> document is taken forward it's both clear what the impact is and what needs
>> to be updated?
>>
> I have not done a full audit of every TLS implementation to identify which
> are key-share-first. From the thread, it sounds like rustls also needs to
> be updated. I imagine there are others. However, "needs to be updated" is a
> bit subtle. As the draft discusses, a key-share-first algorithm is fine *if
> all your supported groups are equally preferable*. In that case,
> prioritizing performance is reasonable. For instance, if you only implement
> X25519 and P-256, it's probably fine to just pick based on key shares. So
> if those implementations only implement a small handful of ECDH curves and
> have such a policy, there's no immediate problem.
>

LibreSSL also needs an update, while the code is completely different it
does use the same mechanism which is basically to just pick the prediction
if at all possible to avoid the HRR, considering everything else as
equivalently "good enough". In the old world where there really wasn't a
practical "downgrade" this was a perfectly reasonable choice to make, so I
expect the majority of
implementations will need to be modified..  Fortunately it's not a
difficult change.


>
> The problem is that this condition will obviously fail once we have a mix
> of postquantum and classical groups. So, at minimum, any such
> implementation needs to be fixed before deploying PQ. It is also quite
> questionable if the TLS library documents that some configuration is a
> preference list (as OpenSSL does), because the library would not actually
> be implementing a preference list with a key-share-first algorithm. If your
> library has pluggable groups (as OpenSSL does), this is also questionable
> as that means the TLS library probably does not actually know that all
> implemented groups are equally preferable.
>
> BoringSSL implements a preference-aware algorithm because we anticipated
> this. :-) I believe NSS's algorithm is similarly preference-aware. But
> clearly not everyone realized this when reading RFC 8446, so I think we
> need to fix the specification text to be clearer. In particular, this
> should be fixed before postquantum is widely implemented and we have a mess
> on our hands.
>
> Similarly, in Section 3.2 of the draft, can we be explicit about what we
>> mean by "best common option"? As mentioned in the thread, some servers may
>> prefer size/speed, and others security level. This is particularly relevant
>> in the PQ algorithms case, but also applies to current implementations
>> choosing between x25519 and secp384r1, for example.
>>
> This is precisely why "best" is intentionally vague, and I think needs to
> stay that way. TLS specs have always left the exact selection policy up to
> implementation. Rather, we give semantics to the offering party's messages
> (e.g. we say the client list is its preferences) and leave the selecting
> party's response up to choice. However, we neglected to give semantics to
> the client's key_share list, and have ended up in a place where reasonable
> client and reasonable server behaviors do not mesh quite right. This draft
> aims to correct that.
>
>
>> DNS hints may not help decide which is best as we explicitly are not
>> using key_shares.
>>
> I don't understand this comment. The point of DNS hints is not to help
> decide which is best. It's to help the client decide which to predict, in
> order to minimize roundtrips. The entire point of this draft is to clarify
> that the client's prediction set is *not* a statement preference. I.e. it
> is explicitly not about deciding which is best.
>
> Just to clarify, is the purpose of this draft to use new, duplicate groups
>> for TLS to indicate that the server adheres to this draft?
>>
> No, this draft does *NOT* propose to define duplicate groups.
>
> The proposal is that *going forward*, any *new* groups we define will be
> prediction-safe. In particular, we need to make sure that all post-quantum
> groups are prediction-safe, so that we can better navigate the tradeoffs
> between wanting to reliably negotiation postquantum groups, and their size
> cost. It is, broadly, not a problem for existing ECDH groups because the
> commonly implemented ones are all broadly of the same security level and
> size. I don't believe there's been a significant need for clients to play
> interesting prediction games. Thus, leaving them prediction-unsafe is just
> fine. Indeed, the other half of the draft sets client rules that ensure
> prediction-unsafe

Re: [TLS] [EXTERNAL] Re: Adoption call for Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

[Bob Beck]

I also support adoption, and am willing to contribute to text and
implementation efforts.

On Mon, Nov 6, 2023 at 6:50 PM Andrei Popov  wrote:

> Likewise, I support adoption, willing to contribute text and
> implementation.
>
> Cheers,
>
> Andrei
>
> --
> *From:* TLS  on behalf of David Benjamin <
> david...@chromium.org>
> *Sent:* Monday, November 6, 2023 9:26 AM
> *To:* Joseph Salowey 
> *Cc:*  
> *Subject:* [EXTERNAL] Re: [TLS] Adoption call for Legacy
> RSASSA-PKCS1-v1_5 codepoints for TLS 1.3
>
> I support adoption and am willing to contribute text, but this is perhaps
> not surprising. :-)
>
> On Mon, Nov 6, 2023 at 12:25 PM Joseph Salowey  wrote:
>
> At the TLS meeting at IETF 118 there was significant support for the
> draft  Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3
>  (
> https://datatracker.ietf.org/doc/draft-davidben-tls13-pkcs1/01/)  This
> call is to confirm this on the list.  Please indicate if you support the
> adoption of this draft and are willing to review and contribute text.  If
> you do not support adoption of this draft please indicate why.  This call
> will close on November 27, 2023.
>
> Thanks,
>
> Sean, Chris and Joe
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Bob Beck]

I support adoption and am willing to review.

On Tue, Dec 5, 2023 at 10:34 PM Deirdre Connolly 
wrote:

> 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 and contribute text. If
> you do not support adoption of this draft please indicate why.  This call
> will close on December 20, 2023.
>
> Thanks,
> Deirdre, Joe, and Sean
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] -draft8447bis: rename Support Group Elliptic curve groups space

[Bob Beck]

On Fri, Mar 29, 2024 at 2:59 AM David Benjamin  wrote:

> Regarding renaming, I'm torn. "Group" was a truly horrible rename. The names 
> we pick make their way into APIs and even sometimes UI surfaces for 
> developers. Every time I've plumbed TLS named groups into another system, 
> I've been met with confusion about what in the world a "group" is, and I've 
> had to embarrassingly explain that yes, it is a term of art, short for 
> "Diffie-Hellman group", no, it doesn't even make sense with PQC, and I'm 
> truly very sorry that TLS chose such a needlessly confusing name, but it's 
> the name we've got. Sometimes I just give up on the TLSWG's naming and just 
> saying "key exchange" or "key agreement", but that gets a little tricky 
> because that can also mean the left half of a TLS 1.2 cipher suite (ECDHE_RSA 
> / ECDHE_ECDSA / RSA). At one point, we tried "key exchange group" to avoid 
> that, but that's also problematic as one needs to explain to translators that 
> this does not mean "primary trade collection".
>
> This name is bad enough that I needed to make a pre-written explanation for 
> this, so I can save time and link to it every time it comes up.
>
> At the same time, we've already renamed this once. These names we pick make 
> their way everywhere, each rename we do is costly. All the old "curve" APIs 
> had to be doubled up and deprecated in systems, with the old ones forever 
> stuck around. And then some systems (probably correctly) decided to stick 
> with the old "curve" name. Renaming again will add a third, and repeat this 
> costly cycle.

This would be why in spite of the fact that I dislike the "group"
name, I would lean more to the "no do not rename" - We already deal
with "group" and "curve" for this and the names are scattered through
API and implementations, and we already have to deal with explaining
it's not really a group, and not really a curve, and it was renamed.
IMO Renaming this a third time will simply add more such confusion to
this area and make the "explaining" david alludes to above even longer
to add a third case to make people aware of the rough equivalency of
the third name in the saga, since the old names will not go away soon
or easily.

> Had we not renamed, I would say we just keep it at "curves". While "curves" 
> is also wrong for PQC, it is less generic of a name than "group" and, in my 
> experience, reads more clearly as a random term of art. It's a pity that we 
> then changed it to one of the most overloaded words in English imaginable. :-(

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS]Re: WG Adoption for TLS Trust Expressions

[Bob Beck]

On Fri, May 24, 2024 at 2:05 PM Christian Huitema 
wrote:

>
>
> On 5/23/2024 9:41 AM, David Benjamin wrote:
> > At the end of the day, the TLS components of trust expressions are
> > simply a more size-efficient form of the certificate_authorities field.
> > The rest is working through the deployment implications to reduce server
> > operator burden. However, the way we achieve this size efficiency is by
> > *not* saying the CAs names. Instead, the CA sets are indirected through
> > named and versioned "trust stores". However, the price one inherently
> > needs to pay here is that servers need to know how to map from those
> > trust stores back to the certificates. We solve this with the
> > TrustStoreInclusionList metadata from the CA.
> >
> > That TrustStoreInclusionList structure is necessarily a point-in-time
> > snapshot of the state of the world. If a root program has not included a
> > CA yet, the CA cannot claim it in the metadata or connections will fail.
> > If the CA is included in zero root programs, the only viable (i.e.
> > correct and does not cause interop issues) TrustStoreInclusionList is
> > the empty list, in which case the certificate will never be presented.
>
> I think this is making the assumptions that the only choice for clients
> is to adopt one "well known" trust store, probably from a short list. I
> am concerned that such mechanisms reinforce ongoing centralization of
> the web.
>
>
I think this is a worthwhile concern, and while noting that I am an author
of this draft, I will attempt to wear a slightly different hat temporarily.

 In another life I help maintain an OS trust store for non-mainstream
clients to access the web. My "choices" today are basically to follow
Firefox or Chrome and include most of what they support. (we have basically
followed Firefox for many years). We can decide to not include certain CA's
that we don't feel have merit, but only if they have very little use. We do
not have an effective way to add anything separate or distinct for our
clients, as such servers can not also be used with the public web in
general.  So I think as far as the situation is today, trust store choice
is already very centralized if you want your client to "usually work" on
the public web. We have basically two choices. both of which are very very
similar in their content.

 I am not certain that trust expressions would change that situation for a
non-mainstream client like this, but I don't think that it makes my choices
worse. I still have the same choice - follow one of the well known trust
stores. I can do this either by continuing as always and not having the
client send a trust expression, or, by fetching the trust anchors from a
"well known" big trust store and modifying the client to support the
necessary things and to send the appropriate trust expression.

 Were a "new" trustworthy root program to show up with CA partnerships that
were useful and made use of trust expressions, a non-mainstream client
could potentially start to make use of that as another choice, *If* they
trusted the operators of such a program to do a good job of evaluating the
trustworthiness of the CA's they were including.

-Bob


> ___
> 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: TLS Trust Expressions risks

[Bob Beck]

On Fri, May 24, 2024 at 5:18 PM Brendan McMillion <
brendanmcmill...@gmail.com> wrote:

> Even with ubiquitous server-side TE support and servers configured with
>> both a ubiquitous chain and a government-issued chain, it seems to me this
>> government push for use of their CA requires a change to server TLS stacks
>> to prefer the government CA chain since both will match the client's
>> advertised trust stores. Mandating this server behavior change seems to me
>> like a heavier lift than just a minor config change.
>>
>
> The part of the spec you quoted says: if multiple certs match, choose any.
> When TE is rendered in actual code, why do you assume that there will be no
> configurable or easily-gameable way to make sure the government CA
> always wins?
>

Since the server is free to apply whatever logic (random, smallest number
of bytes on the wire, secret government coercion) it likes to pick from
multiple matches, If what the government intends is to *always* have the
paths matching a particular trust expression chosen on a multiple match,
the server software needs to be either gamed, or complicit in making that
happen, or it will not happen reliably. (either that or the client needs to
be mandated to be modified to simply try with only the desired "bad" trust
first, and then if it doesn't work silently reconnect with the "good" trust
to work with the rest of the world - which can happen without trust
expressions perfectly fine, and is a trick clients have used before for
things like, SHA1 deprecation.

I don't believe this is in any way different than a server supporting
https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.4 (which says the
list should be used as "guidance" and leaves it up to the implementer -
maybe the list is in a priority order like key shares, maybe it is not?)
While I am not convinced that this is a real risk for surveillance issues
that is not already present, as already outlined in our previous replies,
If the community at large truly believes that this is a real risk worthy of
design work to mitigate, then this should probably also be addressed in
8446 at the same time.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: HRR support (was something else)

[Bob Beck]

On Tue, Jun 4, 2024 at 7:24 AM Martin Thomson  wrote:

> On Mon, Jun 3, 2024, at 14:34, Bas Westerbaan wrote:
> > [...] We're scanning origins so that we can send a
> > supported keyshare immediately and avoid HRR (not rolled out yet.)
> > That's not just for performance, but also to deal with origins that
> > don't support HRR.
>
> Whoa.  Are you saying that there are TLS 1.3 implementations out there
> that don't send HRR when they should?  I get that you might want to
> optimize a little if you have to connect to a server often.
>
> Optimization is a very different thing to the origin not supporting HRR at
> all.


There are most certainly situations where you do not get an HRR when you
should.  There is more than one implementation of buggy middleware out
there that mishandles large client hellos, so if you send a large key share
you are out of luck. This doesn't mean the implementation is not attempting
to implement HRR, it's just the bugs effectively mean if you hit the
problem case, you lose. While hopefully ecosystem pressure eventually gets
fixed versions deployed,  the number of these in the wild is far from zero
today.


>


> Are you concerned that this sort of coddling removes some useful incentive
> to implement HRR?
>
> I've held this concern for a while, particularly for QUIC.  If we have a
> very homogeneous profile of support for primitives, we're risking having
> the negotiation mechanisms fail when we need them.
>
> ___
> 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: TLS trust expressions and certificate_authorities

[Bob Beck]

On Thu, Jun 13, 2024 at 4:23 PM Amir Omidi  wrote:

> I’ve had a lot of trouble understanding how the user agent is supposed to
> be configured with this. Maybe a browser is going to be able to do it
> easily, but how do we envision this working in openssl? Or a programming
> language?
>
> If this is implemented by user agents, how do we envision the
> fingerprinting impact for this?
>
> My comments aren’t blockers by any means. It’s only me trying to
> understand how we imagine this draft working in these various TLS client
> implementations.
>

Hi Amir.

If you're thinking about "non-browser" things such as the openssl command
line tool, curl, nc, libcurl using utilities, etc. You probably need to
first ponder where those tools are getting their trust store to verify
certificates from the public web today.

Sometimes this is a custom bundle included with the tool, sometimes this is
a "system" CA trust store maintained by the operating system distribution.
Either way "someone" decided to include it, and usually, this is done by
following along with an existing root program
that the maintainers mostly trust to do a good job of being a root program.
Hopefully it is kept up to date both in terms of adding new additions, and
keeping up with distrusts.

By not sending a trust expression they could just continue as today, and in
the presence of a trust expressions supporting server they would get the
"default" certificate that is hoped to be ubiquitous. In the near term
until trust expressions are well supported by TLS software and servers, I
would expect that to likely be what would happen.

Outside of my day job I do assist with curating a trust store in an
operating system that is used by such tools when built there. Today we
mostly just follow along with Mozilla's trust store for firefox, because we
have no desire today to run our own root program. So let's call this
thankless task maintenance for "BasementOS".

In the future, If support were added to the TLS libraries we use, a trust
expression *could* be used, assuming BasementOS had one to use.  That could
take several forms:

   - BasementOS can use the published information from a root program
   publishing trust expressions to include the same roots of trust, and they
   simply advertise the exact trust expression corresponding to the roots
   they include. (I.E. if they decide to follow the chrome root program, they
   fetch the information from the chrome root progam, include chrome's roots
   at version 1234 and send the trust expression of "chrome 1234"). With
   support for using an identified trust store in the TLS software, one could
   even ponder being able to download or update versions of a package that
   included such roots and the trust expression for them.
   - BasementOS could decide a particular root program is mostly ok, and do
   just as the above, but exclude some roots they don't want or like in the
   system trust bundle, so they send the same trust expression, but exclude
   the roots they remove. (chrome 1234 with exclusions)

Someone could also decide we really really want to start their own root
program, for . Maybe they don't want to be what a major browser
is. One of the (unstated, and perhaps we should state it clearer) goals of
trust expressions is to allow for new root programs to be created.

   - BasementOS (or a collective of multiple OS's, packages, whatever)
   could start a root program, and start coordinating with CA's to include
   their trust expression in matching delivered certificate chains. Maybe some
   CA's do, maybe some do not. In the interim BasementOS could start with an
   existing trust store,  remove what it doesn't like, and send that along
   with it's nascent trust expression (chrome 1234 with exclusions)
   (basementOS 12) Once enough CA's include a basementOS trust expression on
   certificates, they could transition to using a BasementOS trust expression
   - Perhaps if BasementOS itself is too tiny for this job, it bands
   together in a collective with other like minded OS's / projects, etc. and
   runs a collective root program, the same way.

The important takeaway here is that even today *SOMEONE* is making
decisions somewhere about what roots such things trust when they make
connections. Trust expressions do not change that. If today they are
manually curating a bundle without a trust expression, they can continue to
do so. If they are "following" a major root program that starts to publish
trust expressions, they could also send an appropriate trust expression.

Now, do people today put a lot of thought into what "root program" is
maintaining the trust bundle and how up to date it is for their command
line tools? I am unsure that it gets the attention it might warrant.

-Bob



> Amir Omidi (he/them)
>
>
> On Thu, Jun 13, 2024 at 22:16 Eric Rescorla  wrote:
>
>>
>>
>> On Wed, Jun 12, 2024 at 5:16 PM Nick Harper  wrote:
>>
>>> On Wed, Jun 12, 2024 at 3:17 AM Dennis Jackson 
>>> wrote:
>>

[TLS]Re: Adoption call for Extended Key Update for TLS 1.3

[Bob Beck]

I support adoption, and would be willing to review drafts and would work to
have it implemented.

On Thu, Jul 25, 2024 at 9:44 AM Sean Turner  wrote:

> At the IETF 120 TLS session there was interest in adopting the Extended
> Key Update for TLS 1.3 I-D (
> https://datatracker.ietf.org/doc/draft-tschofenig-tls-extended-key-update/).
> This message starts a two-week call for adoption. If you support adoption
> and are willing to review and contribute text, please send a message to the
> list. If you do not support adoption of this I-D, please send a message to
> the list and indicate why. This call will close on 8 August 2024.
>
> Thanks,
> Sean
> ___
> 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: [⚠️] Re: [EXTERNAL] Adoption call for SSLKEYLOG Extension file for ECH

[Bob Beck]

On Thu, Jul 25, 2024 at 10:15 AM Yaroslav Rosomakho  wrote:

> Thank you for the feedback, Andrei.
>
> Yes, it is intended to stay on the informational track as an extension
> to draft-ietf-tls-keylogfile-02. We tried to keep wording in line with the
> keylogfile draft - for instance in the applicability statement it is worded
> that "this mechanism MUST NOT be used in a production system". Happy to add
> stronger wording if that helps.
>

No matter what your opinion on standardizing SSLKEYLOGFILE,
https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ does not
contain this MUST NOT guidance as in this draft.

MUST NOT guidance for only this portion of SSLKEYLOGFILE functionality that
is not present for the rest of specification calls into question how an
application developer shipping SSLKEYLOGFILE functionality in an
application is supposed to follow this guidance. Is only this portion of
the functionality supposed to be removed in "production"

It seems to me like if this is what the IETF wants to advise, This advice
is being given in the wrong draft.

-Bob


>
> The ultimate goal is to simplify adoption of ECH for both developers of
> TLS software and implementers. Without a standard approach to
> troubleshooting every developer has to build an individual set of bespoke
> troubleshooting tools. Ability to inspect ECH negotiation in off the shelf
> tools such as Wireshark during development or tests would significantly
> help adoption.
>
>
> Best Regards,
> Yaroslav
>
> On Thu, Jul 25, 2024 at 9:31 AM Andrei Popov  40microsoft@dmarc.ietf.org> wrote:
>
>> I do not support adoption, because I believe the IETF should not
>> standardize tools and techniques for decrypting TLS-protected data.
>> It is harder for a TLS implementer to reject requests for IETF-blessed
>> functionality.
>>
>> (As long as this remains on the Informational track, I believe it's
>> somewhat less harmful.)
>>
>> Cheers,
>>
>> Andrei
>>
>> -Original Message-
>> From: Sean Turner 
>> Sent: Thursday, July 25, 2024 9:16 AM
>> To: TLS List 
>> Subject: [EXTERNAL] [TLS]Adoption call for SSLKEYLOG Extension file for
>> ECH
>>
>> At the IETF 120 TLS session there was interest in adopting the SSLKEYLOG
>> Extension file for ECH I-D (
>> https://datatracker.ietf.org/doc/draft-rosomakho-tls-ech-keylogfile/).
>> This message starts a two-weekl call for adoption. If you support adoption
>> and are willing to review and contribute text, please send a message to the
>> list. If you do not support adoption of this I-D, please send a message to
>> the list and indicate why. This call will close on 8 August 2024.
>>
>> Thanks,
>> Sean
>> ___
>> 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 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: Consensus call for RFC8773bis Formal Analysis Requirement

[Bob Beck]

On Aug 25, 2024, at 13:56, Salz, Rich  wrote:








I am opposed. Anonymous email recommendations are not how the IETF operates.I would also count myself as opposed. While I understand and am sympathetic to a reviewer possibly not wanting to get deluged in email or opinions unrelated to the task at hand, I think if this is truly a problem it is symptomatic to participation in a working group as a whole and should be addressed across the board for everyone. Anonymous reviewers have a number of problems as Rich has pointed out. 
 
Attached below is a note I wrote a month ago to the Chairs.  None of the points written there – and MOST of them were a summary of WG discussion – were addressed.

 

 

From: Rich Salz 
Date: Tuesday, July 30, 2024 at 1:49 PM
To: "tls-cha...@ietf.org" 
Subject: Rethinking the formal analysis triage
 
TLS Chairs,
 
I wasn’t sure whether to send this to you or the entire WG. I let another person read this and they suggested the Chairs.  So here you go.
 
I re-read all the messages in the archive [1] and re-watched the 119 and 120 segments on the triage panel.  I believe that, as currently set up, it is so flawed that it should
 be taken down and rebuilt from scratch.
 
After the idea was proposed in March, the two most common feedback suggestions were
    • Collaborate with UFMRG
    • Make all communications open and on the mailing list
Neither of these were done. In fact, there was no response from the Chairs on either point.
 
From the beginning, the stated intent was the that one thing the panel would provide is an estimate of how much work any suggested analysis would take. The one review that
 was done so far did not include that, other than “feasible.”
 
Many people have already commented that collating all responses is a bad idea. I want to add one point that I have not seen before: if a subset of the triage reviewers recommends
 analysis, the WG has no information about the qualifications of those making the recommendation and no way to evaluate how to accept it.
 
This brings up a related point. Anonymous evaluations are against the very nature of the IETF. How can we assess the value of someone’s contributions when we don’t know who
 they are? Will “Reviewer 1” always be the same person? If the entire panel did not do a review, are WG members expected to treat all members as equally competent and qualified?
 
The WG is strongly in favor of more formal analysis. The Chairs tried to do too much and failed. Start over, respond to the feedback you got from the WG, and pick something
 easier.
 
[1]  https:/mailarchive.ietf.org/arch/browse/tls/?q=triage
 
 




___TLS mailing list -- tls@ietf.orgTo 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: [EXTERNAL] draft-ietf-tls-key-share-prediction next steps

[Bob Beck]

I also believe this should move forward.

> On Sep 10, 2024, at 4:05 PM, Bas Westerbaan 
>  wrote:
> 
> Same.
> 
> On Tue, Sep 10, 2024 at 11:51 PM Andrei Popov 
>  wrote:
> I support staying the course, continuing work on the key share prediction 
> draft and allocating the code point.
>  Cheers,
>  Andrei
>   From: David Benjamin  
> Sent: Tuesday, September 10, 2024 2:40 PM
> To:  
> Subject: [EXTERNAL] [TLS] draft-ietf-tls-key-share-prediction next steps
>   Hi all,
>   Now that we're working through the Kyber to ML-KEM transition, TLS 1.3's 
> awkwardness around key share prediction is becoming starkly visible. (It is 
> difficult for clients to efficiently offer both Kyber and ML-KEM, but a hard 
> transition loses PQ coverage for some clients. Kyber was a draft standard, 
> just deployed by early adopters, so while not ideal, I think the hard 
> transition is not the end of the world. ML-KEM is expected to be durable, so 
> a coverage-interrupting transition to FancyNewKEM would be a problem.)
>   We adopted draft-ietf-tls-key-share-prediction in June to address this. 
> There hasn't been a whole lot to do on it since. I've cut a new draft, 
> draft-ietf-tls-key-share-prediction-01, with some very minor changes that 
> were queued up in GitHub. I'd like to sort out next steps and move forward.
>   Beyond that, there are a couple of minor issues in the issue tracker. I 
> don't believe either of these need to block getting a codepoint.
> https://github.com/tlswg/tls-key-share-prediction/issues/4 - unless folks 
> think otherwise, I plan to just leave this alone and close this
> https://github.com/tlswg/tls-key-share-prediction/issues/7 - unless folks 
> think otherwise, I plan to just leave this alone and not require the receiver 
> to check
>   Finally, there's the question of downgrade protection:
> https://github.com/tlswg/tls-key-share-prediction/issues/11
>   For some background if folks have forgotten, the original key share 
> prediction draft included a ton of complexity to accommodate existing server 
> behavior that would preferentially pick groups out of key_share even if an 
> otherwise more preferred group was in supported_groups. Depending on what the 
> server was trying to do there, this could be perfectly fine (if the server 
> believes the groups are comparable in security) or a downgrade risk (if the 
> server actually believed they were in different security classes---PQ vs 
> classical---but implemented a key_share-first selection algorithm anyway). 
> Pre-adoption, my original draft took the position that it was ambiguous and 
> we cannot safely assume the server knew what it was doing. It designed a 
> scheme to clarify the semantics going forward and use codepoints to ratchet 
> in whether the server implemented the new semantics.
> https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.html
>   After WG discussion, I think we broadly concluded the semantics were 
> actually already present in RFC 8446, and it was not worth the trouble to 
> second-guess the servers here. That led to the much simpler draft, which 
> simply discusses why this is OK in security considerations:
> https://www.ietf.org/archive/id/draft-ietf-tls-key-share-prediction-01.html#name-security-considerations
>   As I wrote that text, I unsurprisingly agree with and am fine with this 
> outcome. :-) But there was some chatter about it in the adoption thread (see 
> GitHub link), so I filed the issue so we continued to discuss it. I think 
> perhaps now is the time to discuss it, if we're going to. Do folks want to 
> discuss it? Are there alternate proposals, or should we just stay the course? 
> Unless we have an alternate proposal, I propose we just stay the course and 
> go with [what I understand the conclusion to be from] the previous WG 
> discussion.
>   If there are no further significant changes that folks want to make, I 
> would like to propose we get a codepoint for this and unblock implementation. 
> The earlier this is ready, the more likely that we will be prepared by the 
> time the next KEM transition happens.
>   Thoughts?
>   David
> ___
> 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 mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Changing WG Mail List Reputation

[Bob Beck]

Thanks for this Sean.

On Fri, Oct 25, 2024 at 6:31 AM Sean Turner  wrote:

> Hello list,
>
> The TLS list is infamous in that it is regarded by some as [insert your
> descriptive word; where the chairs have heard the following words used:
> noxious, toxic, unwelcoming, and rude]. The chairs want to change this
> reputation and we hope you do too. A big part of this is on the chairs to
> be be more proactive about moderating behavior that goes against IETF WG
> procedures, code of conduct, etc. The chairs are also going to send a
> monthly reminder, which is included below, that will serve to remind
> everyone from those who joined just today to those who joined many, many
> years ago of the policies and procedures that apply to IETF mailing lists.
>
> Monthly email reminder follows:
>
> ---
>
> Hello list,
>
> As a regular reminder, this list is governed by IETF’s Working Group
> Procedures [BCP25], which also includes Anti-Harassment Procedures, and by
> participating you agree to the Note Well [NW] and to follow the Code of
> Conduct [CoC]. Thank you for contributing as part of the TLS Working Group.
>
> As moderators of this list, the chairs are charged with determining when
> messages are “disruptive to the WG process”, phrase from RFC 3934, and, at
> a minimum, the chairs consider the following to be disruptive:
> • Unsolicited bulk e-mail (from RFC 3683)
> • Discussion of subjects unrelated to IETF policy, meetings,
> activities, or technical concerns (from RFC 3683)
> • Unprofessional commentary, regardless of the general subject
> (from RFC 3683)
> • Repetition of arguments without providing substantive new
> information
> • Requesting an unreasonable amount of work to provide information
>
> To elaborate on unprofessional commentary, the chairs believe that this
> also includes uncivil commentary as defined by the IETF List Moderators
> that includes threats of violence, personal attacks, and derogatory
> language; see [Language].
>
> RFC 3683 also includes “announcements of conferences, events, or
> activities that are not sponsored or endorsed by the Internet Society or
> the IETF”. Please contact the chairs if you wish to share these types of
> announcements, but in general the chairs do not believe they are disruptive
> unless they are excessive and lack relevance.
>
> Reminder that if at anytime you feel that if somebody is out of line you
> can say so on list or directly to us (mailto:tls-cha...@ietf.org), the
> ADs (mailto:sec-...@ietf.org), or the Ombudsteam (mailto:
> ombudst...@ietf.org).
>
> ---
>
> Obviously, if we receive significant feedback about any of the above, we
> can revisit the message.
>
> Even though there are three of us, we are still not always immediately
> available to respond and because of that we would like your help in keeping
> the tone of the list professional and civil. Remember that if somebody else
> is behaving badly please refrain from reciprocating.
>
> Cheers,
> The Chairs
>
> [BCP25] https://datatracker.ietf.org/doc/bcp25/
> [NW] https://www.ietf.org/about/note-well/
> [CoC] https://datatracker.ietf.org/doc/bcp54/
> [Language]
> https://github.com/ietf/Moderators/blob/main/uncivil-commentary.md#descriptions
> ___
> 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: DTLS 1.3 ACKs near the version transition

[Bob Beck]

> On Sep 17, 2024, at 5:28 PM, David Benjamin 
>  wrote:
> 
> Ah, I just noticed this text at the end of Section 7.1:
> 
> > Note that in some cases it may be necessary to send an ACK which does not 
> > contain any record numbers. For instance, a client might receive an 
> > EncryptedExtensions message prior to receiving a ServerHello. Because it 
> > cannot decrypt the EncryptedExtensions, it cannot safely acknowledge it (as 
> > it might be damaged). If the client does not send an ACK, the server will 
> > eventually retransmit its first flight, but this might take far longer than 
> > the actual round trip time between client and server. Having the client 
> > send an empty ACK shortcuts this process.
> 
> https://www.rfc-editor.org/rfc/rfc9147.html#section-7.1-8
> 
> I guess then the intent is indeed that if you receive some random encrypted 
> DTLS 1.3 header, even though you don't know it's DTLS 1.3 yet, you interpret 
> as activating the ACKing mechanism? But that seems to prompt more questions 
> than it answers. For instance, what happens if you do that, but then finally 
> receive the ServerHello and it turns out this was just some junk packet and 
> we're really negotiation DTLS 1.2? Do you check that the ACK mechanism has 
> been activated and return an error? Do you just pause the ACK mechanism and 
> hope you're in an OK state? This seems quite prune to send the implementation 
> into unexpected and untested states.
> 
> 


Yeah, I think this has missed a nasty corner case here for implementations that 
support both. 

I think I also lean towards option A) (from below) here. Anyone else who has 
gotten at least their hands mildly dirty in a DTLS implementation that supports 
both 1.2 and 1.3 care to chime in as well? 


> On Thu, Sep 12, 2024 at 4:31 PM David Benjamin  wrote:
> Hi all,
> 
> I noticed another issue with the DTLS 1.3 ACK design. :-)
> 
> So, DTLS 1.3 uses ACKs. DTLS 1.2 does not use ACKs. But you only learn what 
> version you're speaking partway through the lifetime of the connection, so 
> there are some interesting corner cases to answer. As an illustrative 
> example, I believe the diagram in section 6 is [probably] incorrect:
> https://www.rfc-editor.org/rfc/rfc9147.html#section-6
> 
> If the client loses the first packet, it never sees the ServerHello and thus 
> learns it's speaking DTLS 1.3. While it does see the second packet, that 
> packet only contains ciphertext that it cannot decrypt. Unless it decides to 
> say "this looks like a 1.3 record header, therefore I will turn on the 1.3 
> state machine", which isn't supported by the RFC (maybe TLS 1.4 will use the 
> same record header but redo ACKs once again), it shouldn't activate the 1.3 
> state machine yet. I expect what will actually happen is that the client will 
> wait for the retransmission timeout a la DTLS 1.2.
> 
> More generally, I believe these are the situations to worry about:
> 
> 1. If a DTLS 1.2 (i.e. does not implement RFC 9147 at all) implementation 
> receives an ACK record for whatever reason, what happens? This decision we 
> don't get to change. Rather, it is a design constraint. Both OpenSSL and 
> BoringSSL treat unexpected record types as a fatal error. I haven't checked 
> other implementations. So I think we must take as a constraint that you 
> cannot send an ACK unless you know the peer is 1.3-capable.
> 
> 2. Do plaintext ACKs exist? Or is the plaintext epoch permanently at the old 
> state machine? Honestly, I wish the answer here was "no". That would have 
> avoided so many problems, because then epochs never change state machines. 
> Unfortunately, the RFC does not support this interpretation. Section 4.1 
> talks about how to demux a plaintext ACK, and section 6, though wrong, 
> clearly depicts a plaintext ACK. So instead we get to worry about the 
> transition within an epoch. Keep in mind that transitions happen at different 
> times on both sides. Keep in mind that there is a portion of the plaintext 
> epoch that lasts after version negotiation in HelloRetryRequest handshakes.
> 
> 3. If a 1.3-capable server receives half of a ClientHello, does it send an 
> ACK? I believe (1) means the answer must be "no". If you haven't read the 
> ClientHello, you haven't selected the version, so you don't know if the 
> client is 1.3-capable or not. If the client is not 1.3-capable, sending an 
> ACK may be incompatible.
> 
> 4. Is it possible for a 1.3-capable client to receive an ACK before it 
> receives a ServerHello? If so, how does the client respond? I believe the 
> answer to this question, if plaintext ACKs exist, is unavoidably "yes". 
> Suppose the server receives a 1.3 ClientHello and then negotiates DTLS 1.3. 
> That is a complete flight, so Section 7.1 discourages ACKing explicitly (you 
> can ACK implicitly), but it does not forbid an explicit ACK. An explicit ACK 
> may be sent if the server cannot generate its responding flight immediately. 
> That means a server coul

[TLS] Re: Consensus Call: early code point request for draft-ietf-tls-key-share-prediction

[Bob Beck]

On Tue, Sep 24, 2024 at 5:12 PM David Benjamin 
wrote:

> I should add, another reason to call it tls-supported-groups is that this
> is essentially what the server would have put in the supported_groups
> extension, if negotiation order in TLS were inverted. Since TLS already saw
> fit[*] to name this concept supported_groups, I think that's a fine name
> for the equivalent DNS incarnation.
>

> David
>
> [*] Mind you, supported_groups is a horrible name, but because of
> "groups", not "supported". It refers to Diffie-Hellman groups, but we're
> sticking PQ KEMs in there now. But we already disruptively renamed "curves"
> to "groups" and another rename would do it again. Honestly, we should have
> just kept it at "curves", and saved our disruption budget for a
> more appropriate name, but so it goes. :-)
>

^^^ This.   having a third term to attempt to describe a concept because we
keep changing our minds is not going to help implementers, but just cause
confusion

I don't personally like supported_curves^Wgroups but turning that into
supported^Wpreferred_curves^Wgroups^Wkems is just adding confusion and
possibly code churn for variable renaming. We should reap what we sow and
just use supported_groups

If we absolutely must name the DNS thing something else, treat it as an
opaque list of strings and don't be opinionated about what those
strings contain. The DNS doesn't know or care anyway. name it for what it's
purpose is (keyshare_hint).



> On Tue, Sep 24, 2024 at 7:07 PM David Benjamin 
> wrote:
>
>> Ah, I see. I don't think "supported" vs "preferred" captures this because
>> "preferred" in the context of TLS usually isn't a binary property but a
>> preference order. But I agree there is some ambiguity over what to list if
>> you've got a couple different values.
>>
>> I think, other than potentially changing the name, it's not likely that
>> this will have any impact on the presentation syntax. At the end of the
>> day, we're going to want to send a list of things that your service (being
>> intentionally vague about multiple server instances) supports. But since
>> "supported" vs "preferred" is not the right descriptor, I suspect we won't
>> do better than "supported" anyway. In particular...
>>
>> > I interpret preferred as being a list that the target thinks
>> > will help clients avoid HRR, and help clients choose what is
>> > considered "best" (e.g. wrt PQ) and that should work with all
>> > server instances concerned, and that's likely the shortest
>> > such list.
>>
>> That's not right. Avoiding HRR is a matter of predicting the group that
>> the server would have picked given yours and the server's preferences. For
>> example, consider a server that supports:
>>
>> A > B > C > D > E > F
>>
>> By the short list theory, you might think the server should publish, say,
>> "A, B, C". However all that accomplishes is that a client that only
>> supports D, E, and F won't know that it should predict D. The right
>> behavior is to publish your full preference list, so that all clients (up
>> to differences in selection algorithm) have the best shot of predicting
>> correctly.
>>
>> > The issue with "supported" may be that some server instances
>> > might have support for all sorts of oddball groups, and it
>> > might be counterproductive to list all of those for the
>> > target. (And/or to collect/merge the list if we're thinking
>> > about e.g. the wkech thing.)
>>
>> Variations in server instances may indeed result in mispredictions. If
>> the variation is due to a temporary rollout inconsistency, this variation
>> is shortlived and will eventually sort itself out. During that period of
>> inconsistency, neither list is more correct than the other because you want
>> to make the correct prediction for each server.
>>
>> If the variation is persistent because you've intentionally deployed
>> different instances of your service differently... first of all, don't do
>> that. The security properties are not what you might. (An attacker can
>> always direct the client to the weaker of the two.) If, despite the
>> security flaws, you insist on doing this, I suppose you can use different
>> HTTPS records for each and use all the machinery that HTTPS-RR already has
>> here. That's all orthogonal to this draft because describing multiple
>> routes to a single service is a general HTTPS-RR feature.
>>
>> > I'm fine that the text is a bit ambiguous on that for now, but
>> > if the presentation syntax says "supported" then someone may
>> > take that literally and publish very long lists that could
>> > result in failures, for some server instances. (Or else could
>> > add complexity in how e.g. a front-end thing like haproxy has
>> > to process client hellos.)
>>
>> Could you elaborate on how a long list could result in a failure or add
>> complexity?
>>
>> At the end of the day, all this does is influence what key shares the
>> client predicts. No matter which group the client predicts, the client
>> remains 

[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

[TLS] Re: Adoption Call for Trust Anchor IDs

[Bob Beck]

Rather obviously, I support adoption. 

I believe TAI is a good starting point for a practical solution for the problem 
we agreed was a useful thing to solve at the interim. 


> On Jan 15, 2025, at 8: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: Changing WG Mail List Reputation

[Bob Beck]

> On Jan 14, 2025, at 12:20 PM, Dang, Quynh H. (Fed) 
>  wrote:
> 
>  Maybe consensus calls can only be made and completed at the in-person 
> meetings ?

The problem with in-person (or even virtual at the in-person meetings) is it 
then becomes even more of a pay-to-play proposition to participate.

Not all valuable participants have an organization funding their participation 
at IETF. I believe we still want to encourage such participation, not 
discourage it.


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