[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Christopher Wood]

I do not support adoption.

Best,
Chris

> On Nov 5, 2024, at 11:25 AM, Sean Turner  wrote:
> 
> REQUEST: Let’s not rehash all the context.  It is provided for those who 
> might not remember or those that were not around for the duration.
> 
> CONTEXT: Way back in 2016 after the WG had embarked on developing TLS 1.3, 
> Peter Gutmann suggested that another way to “fix” TLS was to specify a 
> version of TLS that indicates a “known-good config drawn from the maybe 10 
> extension-RFCs”; see [0].  Peter submitted his “TLS 1.2 Update for Long-term 
> Support”; see [1]. There was some list discussion; see [2]. Peter asked us 
> about adopting the I-D; see [3]. He made changes based on that feedback; see 
> [4]. At IETF 98, the WG discussed adopting this I-D and the sense of the room 
> was to not adopt the I-D; see [5]. Progress on this document was paused while 
> the WG worked on TLS 1.3. Once RFC 8447 was published, a code point was 
> assigned for the “tls-lts” extensions; see [6] and [7]. Now that we are 
> looking to publish Feature Freeze for TLS 1.2 [8][9] we want to make sure 
> that the working group sentiment has not changed over time so we are running 
> an adoption call for TLS-LTS.
> 
> MESSAGE: This message is to judge consensus on whether there is support to 
> adopt TLS 1.2 Update for Long-term Support; see [1].  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 draft, please send a message to 
> the list and indicate why.  This call will close on November X, 2024.
> 
> Thanks,
> spt
> 
> [0] https://mailarchive.ietf.org/arch/msg/tls/Lr7VwcPCjzDJelUTRTIUJf_8-ww/
> [1] https://datatracker.ietf.org/doc/draft-gutmann-tls-lts/
> [2] https://mailarchive.ietf.org/arch/msg/tls/r4w75rooy-r8Ky-xXAUoslYTL_U/
> [3] https://mailarchive.ietf.org/arch/msg/tls/6tBftKBmxYz_wUcq79_zH8yDTQk/
> [4] https://mailarchive.ietf.org/arch/msg/tls/aw9BOS4HJ9uum0snEZqSuKA4BYw/
> [5] https://datatracker.ietf.org/meeting/98/materials/minutes-98-tls-00
> [6] 
> https://mailarchive.ietf.org/arch/msg/tls-reg-review/bP84S3tHSG9gAmc45CLTjpiA0z8/
> [7] https://mailarchive.ietf.org/arch/msg/tls/xmhnVQTckDmUkoxhx4wx1bfpYXM/
>   Thanks to Peter because he helped us iron out the
>   wrinkles in the tls-reg-review process.
> [8] https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/
> [9] https://mailarchive.ietf.org/arch/msg/tls/f62yvLL_4mDEsRzAY46L4QLjakU/
> ___
> 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 TLS 1.2 Update for Long-term Support

[David A. Cooper]

I am also against adoption.

I would not be against a draft that made deployment recommendations, if 
RFC 9325 was considered insufficient. (Although I don't like the idea of 
suggesting that TLS 1.2 without support for quantum-resistant 
cryptography is a recommended long-term solution.) However, as others 
have noted, this draft is not making deployment recommendations, it is 
specifying a new extension that signals the use of a slightly modified 
version of TLS 1.2. I also agree that not adopting this draft does not 
prevent people from using it, let alone continuing to use TLS 1.2.


Even if I thought the idea of having an extension to signal the use of a 
slightly modified version of TLS 1.2 were a good idea, I believe there 
is another reason that it would be best for this WG not to adopt the 
draft. If the draft were adopted by the WG, then it would need to be 
open for the WG to make technical changes to it. However, Peter 
indicated in 2018 [0] that the extension defined in 
draft-gutmann-tls-lts had been in use since 2016. It would be contrary 
to the goal of this draft to suggest that those who have been using it 
since 2016 should not modify their implementations to align with changes 
made by the WG. It would also be inappropriate to adopt it as a WG 
document, especially as a standards track document, and then effectively 
declare that no technical changes can be made.


[0] https://mailarchive.ietf.org/arch/msg/tls/q7up_-tJH3ysD5Xip1mKGtTLKbg/

On 11/5/24 1:45 PM, Eric Rescorla wrote:

I am against adoption.

As Nick and Watson note, this is not just a profile of TLS 1.2 but is 
rather a set of negotiated with a new extension code point, i.e., it's 
effectively a new version of TLS with as yet only lightly analyzed 
security properties. We already have a new version of TLS which has 
been heavily analyzed and widely deployed, namely TLS 1.3.


There's nothing stopping people deploying this if they want to and in 
fact there is already a code point assigned. However, the TLS WG 
should not take up this work.


-Ekr

On Tue, Nov 5, 2024 at 1:21 PM Arnaud Taddei 
 wrote:


I do support the adoption of this draft.

This draft is a very good product and the details and care that
this draft exhibits is in itself a testimony of someone who has a
real production experience, is realistic and pragmatic.

There is a big difference between
patching an endpoint to a variation of TLS1.2 which is meant to
work in a ’TLS1.2 designed environment”
Vs
patching an endpoint to TLS1.3 in an environment that was ’TLS1.2
designed environment’

If the organisation that needs to manage a security risk is given
a choice of
1) Patch to TLS-LTS
2) Patch to TLS1.3

Any risk manager is going to ask the qualification of the
implications on both and the result will be that 1) will be far
less intrusive and risky than 2)

Moreover the bench-test platform that the solution needs to go
through to prove its production readiness may not be able to
support TLS1.3 at all.

Not adopting this draft leaves only one choice to any customer
with no guarantees that the patching to TLS1.3 will work in its
TLS1.2 designed end-to-end environment at a manageable time, cost
and ‘go to production’ or ‘go to market’ time, and risk.

Worse, it could have unanticipated consequences like breaking
compliancy to regulations, to safety and I can just imagine how it
could move the risks from bits and bytes to blood and flesh.

My 0.02 Swiss francs

*Arnaud Taddei*
Global Security Strategist | Enterprise Security Group

*mobile:* +41 79 506 1129
Geneva, Switzerland
arnaud.tad...@broadcom.com | broadcom.com 


On 5 Nov 2024, at 19:48, Nick Harper  wrote:

I understand the stated goal of this draft to be to provide a way
for hard-to-update endpoints to keep using TLS 1.2 in a
secure way. The idea of a document that describes how to safely
deploy TLS 1.2 sounds like a good idea, e.g. "use only these
cipher suites, require EMS and RI, etc". This draft is not that.

This draft makes changes to the TLS handshake protocol, which
undermines the goal of supporting hard-to-update endpoints. The
two changes made to the protocol are also addressed by RFC 8446.
If endpoints need to be updated to support TLS-LTS, it would make
more sense to update them to support TLS 1.3 than TLS-LTS.

The rationale section (3.7) of the draft presents two reasons for
using TLS-LTS over TLS 1.3. The first is the slow deployment
cadence of a new protocol. LTS requires a change to the protocol
and deployment of that new change, no different from 1.3. The
second reason is fear of the unknown in 1.3: "TLS 1.3 is an
almost entirely new protocol. As such, it rolls back the 20 years
of experience that we have with all the things that can go wrong
in TLS". The 20 ye

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Peter Gutmann]

Nick Harper  writes:

>If endpoints need to be updated to support TLS-LTS, it would make more sense
>to update them to support TLS 1.3 than TLS-LTS.

The difference is that TLS 1.3 requires a complete new protocol stack while
the draft is a minimal tweak to a few known problem areas in TLS 1.2 while
being compatible with existing infrastructure built around 1.2 (or 1.0 in some
cases) - newer devices get 1.2TLS, existing ones stay on 1.2/1.0 until they
get replaced.  They're completely different things.

Peter.

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

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Peter Gutmann]

Watson Ladd  writes:

>TLS 1.3 has widely been implemented and depoloyed across embedded devices and
>has much better analysis. You'd still need to patch devices for this to be
>deployable.

I've never seen TLS 1.3 in an embedded device.  By "embedded device" do you
mean a Linux box, or something running RTEMS, uC/OS, ThreadX, or similar?

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

[TLS] Re: Fwd: New Version Notification for draft-tls-reddy-composite-mldsa-00.txt

[tirumal reddy]

On Sun, 3 Nov 2024 at 14:12, Ilari Liusvaara 
wrote:

> On Sun, Nov 03, 2024 at 05:37:34AM +0530, tirumal reddy wrote:
> >
> > The draft
> https://datatracker.ietf.org/doc/draft-tls-reddy-composite-mldsa/
> > specifies how ML-DSA in combination with traditional algorithms can be
> used
> > for authentication in TLS 1.3.
> >
>
> Important details, such as how signature are encoded seems to be
> missing.
>
>
> And I think this is very premature. As far as I can tell, there are
> major unaddressed issues with hybrid signatures. Those issues need to
> be settled first before adding any codepoints.
>
> Having multiple variants of the same hybrid signature is not acceptable
> due to severe security risks from overloading crypto library authors.
>
> Furthermore, the encodings used by draft-ietf-lamps-pq-composite-sigs
> add additional security risks. Modern crypto design uses byte string
> I/O for safety.
>

This issue is being discussed in the LAMPS WG; the composite signature API
should avoid using protocol-specific encoding.

-Tiru


>
> Currently, only bare ML-DSA and SLH-DSA are usable for post-quantum
> signature authentication. Seems that the only question that does not
> have an obvious answer is the context to use.
>
>
>
>
> -Ilari
>
> ___
> 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 TLS 1.2 Update for Long-term Support

[Martin Thomson]

On Tue, Nov 5, 2024, at 16:25, Sean Turner wrote:
> MESSAGE: This message is to judge consensus on whether there is support 
> to adopt TLS 1.2 Update for Long-term Support; 

https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls12-frozen-02 says:

"no new features will be approved for TLS 1.2"

I'll leave it to the chairs to judge whether this statement has consensus, but 
I support that statement.  We should not adopt this draft.

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

[TLS] Re: Fwd: New Version Notification for draft-connolly-tls-mlkem-key-agreement-04.txt

[Deirdre Connolly]

👍👍

On Wed, Nov 6, 2024 at 7:34 AM John Mattsson 
wrote:

> Hi Deirdre,
>
>
>
> I think it would be good to give developers and users an idea of how small
> the failure rate is. They might not understand what “cryptographically
> small failure rate” is.
>
>
>
> OLD: "ML-KEM has a cryptographically small failure rate"
>
> NEW: "ML-KEM has a cryptographically small failure rate less than 2^-138"
>
>
>
>
> https://github.com/dconnolly/draft-connolly-tls-mlkem-key-agreement/pull/5/files
>
>
>
> Cheers,
>
> John
>
>
>
> *From: *Deirdre Connolly 
> *Date: *Tuesday, 5 November 2024 at 17:28
> *To: *TLS@ietf.org , tls-reg-rev...@ietf.org <
> tls-reg-rev...@ietf.org>
> *Subject: *[TLS] Fwd: New Version Notification for
> draft-connolly-tls-mlkem-key-agreement-04.txt
>
> I've updated draft-connolly-tls-mlkem-key-agreement to include the updated
> IANA codepoints (they were initially allocated in the reserved FFDH section)
>
> https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/
>
> -- Forwarded message -
> From: 
> Date: Tue, Nov 5, 2024 at 4:08 PM
> Subject: New Version Notification for
> draft-connolly-tls-mlkem-key-agreement-04.txt
> To: Deirdre Connolly 
>
>
>
> A new version of Internet-Draft
> draft-connolly-tls-mlkem-key-agreement-04.txt
> has been successfully submitted by Deirdre Connolly and posted to the
> IETF repository.
>
> Name: draft-connolly-tls-mlkem-key-agreement
> Revision: 04
> Title:ML-KEM Post-Quantum Key Agreement for TLS 1.3
> Date: 2024-11-05
> Group:Individual Submission
> Pages:11
> URL:
> https://www.ietf.org/archive/id/draft-connolly-tls-mlkem-key-agreement-04.txt
> Status:
> https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/
> HTML:
> https://www.ietf.org/archive/id/draft-connolly-tls-mlkem-key-agreement-04.html
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-connolly-tls-mlkem-key-agreement
> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-connolly-tls-mlkem-key-agreement-04
>
> Abstract:
>
>This memo defines ML-KEM-512, ML-KEM-768, and ML-KEM-1024 as a
>standalone NamedGroups for use in TLS 1.3 to achieve post-quantum key
>agreement.
>
>
>
> The IETF Secretariat
>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Bas Westerbaan]

I do not support adoption.

On Tue, Nov 5, 2024 at 5:27 PM Sean Turner  wrote:

> REQUEST: Let’s not rehash all the context.  It is provided for those who
> might not remember or those that were not around for the duration.
>
> CONTEXT: Way back in 2016 after the WG had embarked on developing TLS 1.3,
> Peter Gutmann suggested that another way to “fix” TLS was to specify a
> version of TLS that indicates a “known-good config drawn from the maybe 10
> extension-RFCs”; see [0].  Peter submitted his “TLS 1.2 Update for
> Long-term Support”; see [1]. There was some list discussion; see [2]. Peter
> asked us about adopting the I-D; see [3]. He made changes based on that
> feedback; see [4]. At IETF 98, the WG discussed adopting this I-D and the
> sense of the room was to not adopt the I-D; see [5]. Progress on this
> document was paused while the WG worked on TLS 1.3. Once RFC 8447 was
> published, a code point was assigned for the “tls-lts” extensions; see [6]
> and [7]. Now that we are looking to publish Feature Freeze for TLS 1.2
> [8][9] we want to make sure that the working group sentiment has not
> changed over time so we are running an adoption call for TLS-LTS.
>
> MESSAGE: This message is to judge consensus on whether there is support to
> adopt TLS 1.2 Update for Long-term Support; see [1].  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 draft, please
> send a message to the list and indicate why.  This call will close on
> November X, 2024.
>
> Thanks,
> spt
>
> [0] https://mailarchive.ietf.org/arch/msg/tls/Lr7VwcPCjzDJelUTRTIUJf_8-ww/
> [1] https://datatracker.ietf.org/doc/draft-gutmann-tls-lts/
> [2] https://mailarchive.ietf.org/arch/msg/tls/r4w75rooy-r8Ky-xXAUoslYTL_U/
> [3] https://mailarchive.ietf.org/arch/msg/tls/6tBftKBmxYz_wUcq79_zH8yDTQk/
> [4] https://mailarchive.ietf.org/arch/msg/tls/aw9BOS4HJ9uum0snEZqSuKA4BYw/
> [5] https://datatracker.ietf.org/meeting/98/materials/minutes-98-tls-00
> [6]
> https://mailarchive.ietf.org/arch/msg/tls-reg-review/bP84S3tHSG9gAmc45CLTjpiA0z8/
> [7] https://mailarchive.ietf.org/arch/msg/tls/xmhnVQTckDmUkoxhx4wx1bfpYXM/
>Thanks to Peter because he helped us iron out the
>wrinkles in the tls-reg-review process.
> [8] https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/
> [9] https://mailarchive.ietf.org/arch/msg/tls/f62yvLL_4mDEsRzAY46L4QLjakU/
> ___
> 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 TLS 1.2 Update for Long-term Support

[Richard Barnes]

I concur with everything Nick says here.

Deployment guidance is fine.  We should not adopt any document that would
require code changes to implement.

We should not adopt this document in its current form.

--Richard

On Tue, Nov 5, 2024 at 7:49 PM Nick Harper  wrote:

> I understand the stated goal of this draft to be to provide a way for
> hard-to-update endpoints to keep using TLS 1.2 in a secure way. The idea of
> a document that describes how to safely deploy TLS 1.2 sounds like a good
> idea, e.g. "use only these cipher suites, require EMS and RI, etc". This
> draft is not that.
>
> This draft makes changes to the TLS handshake protocol, which undermines
> the goal of supporting hard-to-update endpoints. The two changes made to
> the protocol are also addressed by RFC 8446. If endpoints need to be
> updated to support TLS-LTS, it would make more sense to update them to
> support TLS 1.3 than TLS-LTS.
>
> The rationale section (3.7) of the draft presents two reasons for using
> TLS-LTS over TLS 1.3. The first is the slow deployment cadence of a new
> protocol. LTS requires a change to the protocol and deployment of that new
> change, no different from 1.3. The second reason is fear of the unknown in
> 1.3: "TLS 1.3 is an almost entirely new protocol. As such, it rolls back
> the 20 years of experience that we have with all the things that can go
> wrong in TLS". The 20 years of all the things that can go wrong in TLS were
> due to unsound cryptographic decisions. The research and analysis that
> found those 20 years of issues was applied to the design of 1.3 to avoid
> making the same mistakes. 1.3 doesn't roll back that experience, and we now
> have over 8 years of experience with 1.3.
>
> I do not support adoption of the draft in this format. If the draft made
> no changes to the TLS 1.2 protocol and were deployable only through
> configuration changes (e.g. a fixed list of cipher suites and extensions),
> I would probably support it.
>
> On Tue, Nov 5, 2024 at 11:02 AM Salz, Rich  40akamai@dmarc.ietf.org> wrote:
>
>> I strongly support adoption.
>>
>> I do not understand why anyone would be opposed to the IETF making
>> deployment recommendations. I can understand why someone might be bothered
>> by the impliciation that *THIS ONE WAY* is the only way to get long-term
>> support, especially if it's seen to contradict our encouragement of TLS
>> 1.3. But that is an editorial issue that can be easily fixed.
>>
>> I would like to see this adopted, a short change cycle, and then advanced
>> in the same cluster with our TLS 1.2 is frozen document.
>>
>>
>> ___
>> 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: Adoption call for TLS 1.2 Update for Long-term Support

[Viktor Dukhovni]

On Tue, Nov 05, 2024 at 07:01:13PM +, Salz, Rich wrote:

> I strongly support adoption.
> 
> I do not understand why anyone would be opposed to the IETF making
> deployment recommendations. I can understand why someone might be
> bothered by the impliciation that *THIS ONE WAY* is the only way to
> get long-term support, especially if it's seen to contradict our
> encouragement of TLS 1.3. But that is an editorial issue that can be
> easily fixed.
> 
> I would like to see this adopted, a short change cycle, and then
> advanced in the same cluster with our TLS 1.2 is frozen document.

I support adoption.

-- 
Viktor.

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

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Pascal Urien]

Hi Peter

I've never seen TLS 1.3 in an embedded device.  By "embedded device" do you
>
mean a Linux box, or something running RTEMS, uC/OS, ThreadX, or similar?
>

TLS 1.3  in PSK mode for secure element (smartcard) is described in
https://datatracker.ietf.org/doc/draft-urien-tls-se/

Implementation for javacard is there
https://github.com/purien/TLS-SE

Presentation at IETF120 HOTRFC is there
https://www.youtube.com/watch?v=0cLtrcMNjQ4

Pascal


>
> Peter.
> ___
> 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 TLS 1.2 Update for Long-term Support

[Peter Gutmann]

Arnaud Taddei writes:

>There is a big difference between
>
>patching an endpoint to a variation of TLS1.2 which is meant to work in a ’
>TLS1.2 designed environment”
>
>Vs
>
>patching an endpoint to TLS1.3 in an environment that was ’TLS1.2 designed
>environment’

Yup, and that's the intent of the draft, since some industries are going to be
living in a TLS 1.2 environment for some time (as well as TLS 1.0, but I'm not
touching that one), this will try and make it the least problematic TLS 1.2
environment, i.e. it addresses well-known problem areas without making any
significant changes - it was explicitly written not to include anything new 
(new algorithms, new signature types, new hashes, whatever), it's all existing
algorithms that have been around forever, just with minor tweaks like sending
the full domain parameters to allow verification of the DH values, which have
been a problem in the past because of the PKCS #3-based origins of SSLv2 where
this came from.

Peter.

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

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Peter Gutmann]

Eric Rescorla  writes:

>it's effectively a new version of TLS with as yet only lightly analyzed
>security properties.

Are you sure you've read the right document?  "A new version of TLS"?  It's
existing extensions, a few minor tweaks to deal with long-known problem areas,
and some implementation advice, also to deal with long-known problem areas.

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

[TLS] Re: FATT process update

[Salz, Rich]

> I still dislike encouraging private discussion of
> drafts - that's not really in the spirit of the
> IETF at all.

While you're talking spirit versus letter of the rules, it is explicitly 
allowed in RFC 2418, https://www.rfc-editor.org/rfc/rfc2418.html#page-19: In 
order for a design team to remain small and agile, it is acceptable to have 
closed membership and private meetings.


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

[TLS] Re: FATT process update

[Stephen Farrell]

Hiya,

On 06/11/2024 19:00, Salz, Rich wrote:

I still dislike encouraging private discussion of drafts - that's
not really in the spirit of the IETF at all.


While you're talking spirit versus letter of the rules, it is
explicitly allowed 


Yes.

Just to note there's also the option to have a closed mailing
list for a DT with an open archive.


in RFC 2418, https://www.rfc-editor.org/rfc/
rfc2418.html#page-19: In order for a design team to remain small and
agile, it is acceptable to have closed membership and private
meetings.


I suspect that's where the analogy between this group and DTs
may break down, as this is intended to last as long as TLSv1.3.

Cheers,
S.





OpenPGP_signature.asc
Description: OpenPGP digital signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: FATT process update

[Stephen Farrell]

Hiya,

On 05/11/2024 15:34, Joseph Salowey wrote:

There is an updated FATT available here:
https://github.com/tlswg/tls-fatt

This has taken a lot of the feedback we have received so far, but is still
a work in progress. There will be a little time to discuss in the meeting
Friday.


The process/description is getting better thanks.

Using the term liaison will confuse people so be
better to change that.

I still dislike encouraging private discussion of
drafts - that's not really in the spirit of the
IETF at all.

Cheers,
S.



Joe


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




OpenPGP_signature.asc
Description: OpenPGP digital signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: FATT process update

[Rob Sayre]

On Wed, Nov 6, 2024 at 10:00 AM Stephen Farrell 
wrote:

>
> The process/description is getting better thanks.
>

Yes, agree.


>
> Using the term liaison will confuse people so be
> better to change that.
>

Yep, it's correct English/French, but it has an IETF meaning that is more
specialized. But, see below about this issue and others.


>
> I still dislike encouraging private discussion of
> drafts - that's not really in the spirit of the
> IETF at all.
>

I think it is OK to do this. We could compare it to the way we keep IESG
minutes. These people are busy in a similar way, and they need a somewhat
private process in order to respect their time.

I think the current document is way too long. What we can do is make it a
regular IETF design team. I think we did need this detail to figure out
what we are doing, but all the extensive explanations are not necessary for
the final output. I'm not going to do a PR to delete them, because it
doesn't feel good to do a PR that just deletes other people's work. But I
would encourage the authors to pick up a red pen with an aim for many
deletions.

The edit I will suggest is this, to start:

"The FATT panel is similar to a design team as defined in Section 6.5 in
RFC 2418".

I would say that should go. If we start with

""The FATT panel is a design team as defined in Section 6.5 in RFC 2418".

Then, a lot of the process details can also go, since I doubt they will be
followed anyway. Not because what's there now is wrong, but because they
will just do their own thing.

We can once again refer to:

https://datatracker.ietf.org/doc/statement-iesg-on-design-teams-20011221/

Here, we're interested in the last phrase:

"* any design team that lasts for more than a few months should make
regular public reports on what they are doing."

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