[TLS] FATT process update

[Joseph Salowey]

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.

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

[TLS] Re: DTLS 1.3 ACK sorting, and when to clear the ACK buffer

[Ilari Liusvaara]

On Tue, Nov 05, 2024 at 11:47:44AM +, David Benjamin wrote:
> On Mon, Nov 4, 2024 at 5:19 PM Ilari Liusvaara 
> wrote:
> 
> >
> > If the blocking flight has response, then explicit ACK is required to
> > avoid deadlock (to get out of state where both sides have flight in
> > progress). But this can only happen post-handshake.
> >
> 
> Oh I see. The concern is a sender that is only willing to have one outgoing
> flight at a time? So if both sides, say, send a post-handshake
> CertificateRequest, neither will be willing to move on and send a
> responding Certificate until then things have cleared. I agree that this
> situation is indeed a problem.
> 
> I'm not sure what's the best way out of that mess. The spec says you
> "duplicate" the state machine, whatever that means, but having only one
> outgoing flight is indeed a very sensible restriction; it's one I've been
> considering for our implementation. The specification is incredibly
> ambiguous around how parallel post-handshake transactions work! I still
> need to figure out how we want to handle post-handshake messages, but I'd
> definitely been considering that restriction. But I also don't intend to
> implement any multi-flight post-handshake transactions because, well, we
> don't need them but more importantly I cannot make sense of how to make
> them work well at all. (See all the threads I've started here.)
> 
> I'm not sure what's the best way out of that mess, but I hope we can spend
> time with the badly-needed rfc9147bis to improve this.

Another edge case:

- Sender sends two parallel flights, the second one prepares epoch
  change.
- Receiver can buffer multiple messages at once.
- One of the messages from first flight is lost, the second flight
  goes all through.
- The receiver ACKs everything it got.
- The sender thinks second flight is complete, the receiver thinks it
  is incomplete.
- Prepare for epoch change is complete, so sender changes epoch.
- Receiver is not ready for epoch change. If the keys for the next epoch
  depend on the preparing flight, it can not even compute the correct
  keys.

To avoid that problem:

- Each epoch can have at most one message that prepares epoch change.
- All flights up to one that prepares the epoch change must be completed
  before the actual epoch change.

Currently, the messages that prepare epoch change are Finished (only
within handshake), and KeyUpdate. But there could be more in the future.


There is WG draft for Extended Key Update. That can be initiated from
either side, needs at least three flights (and the current version has
four flights) and prepares epcoh changes. Basically hits every edge case
there is.


> > With regards to state-keeping, i think that it would be enough to
> > track the following:
> >
> > - The first message sequence in the current flight.
> > - Current flight complete flag.
> > - First message sequence in next flight (if current flight complete).
> >
> > ... Which fits in 5 bytes (+ padding).
> >
> > This lets one recognize if record belongs to past (ignore), current
> > (process) or next (next becomes current, and process) flight.
> >
> 
> Hmm, I'm not sure if that's sufficient. While the sender might choose to
> restrict themselves to only one outgoing flight at a time for simplicity, a
> receiver can't assume that the sender has done so. The sender might have
> decided to send 10 NewSessionTickets in parallel. On the receiver side, you
> might receive them, maybe even in order, and then ACK them in sequence. But
> perhaps the very first ACK got lost, so the sender retransmits the first
> NewSessionTicket. It is expecting you to ACK it again, or it will keep
> retransmitting.

Oh yeah, it does not work if there can be multiple outstanding flights.

 
> That means that, post-handshake, the receiver needs to ACK messages
> basically arbitrarily back. That is fine because you still only need to
> track the current sequence number and ACK any past ones without processing
> anything. But it means the notion of "current flight" is everlasting. Every
> post-handshake transaction leaves its final flight around as the "current
> flight".
> 
> But now suppose you want to distinguish "current flight" from "past flight"
> and only ACK current flights. *Now* you need per-transaction state to know
> which old sequence numbers are from current vs past flights, in every
> post-handshake transaction. This seems problematic, so I think we should
> make sure the protocol works if you ACK all past sequence numbers
> indiscriminately. But if that's simpler, maybe we should just say that's
> the ACK policy and stop being fussy about only ACKing one flight at a time.
 
What if the past flight has reply? Unless one has got an (implicit) ACK
from the other side about the reply, retransmission on flight signals to
retransmit the reply.

E.g., server sends CertificateRequest and 9 NSTs in parallel. Client
insta-NAKs the CR, and ACKs all the NSTs. The NAK gets lost. Server
re-transmits th

[TLS] Re: DTLS 1.3 ACK sorting, and when to clear the ACK buffer

[David Benjamin]

On Mon, Nov 4, 2024 at 5:19 PM Ilari Liusvaara 
wrote:

> > > There is subtle edge case where this can cause outright failures:
> > >
> > > - Sender that implements only linear tracking.
> > > - Very large flight that gets split into lots of records.
> > > - Some of those records get evicted from ACK buffer before being ACKed.
> > > - Flight has no response, or response is blocked.
> > >
> > > In this scenario, no data will get through, and the sender will just
> > > re-transmit the flight forever.
> > >
> > > To counter this, if ACK buffer fills with unacknowledged records, one
> > > should immediately send ACK. If the first record in transmission was
> > > received and that ACK makes it through, it will cause forward progress.
> > >
> >
> > I'm not sure that will actually prevent forward progress, though I may be
> > misunderstanding your example. In the worst case, you will manage to ACK,
> > say, the last 32K of that flight. The peer will then retransmit all but
> the
> > last 32K, you'll ACK the last 32K of that, and so on until the whole
> flight
> > gets ACKed. This is not amazing, but it's still forward progress. And
> given
> > each record number covers about an MTU's worth of handshake data, you
> don't
> > need much ACK buffer to avoid this or make its effects minimal. Though I
> > agree flushing the ACK buffer when full is a sensible implementation
> > strategy (though also not mentioned by the specification).
>
> Maybe such sender would be too simplistic, and all senders should
> implement full tracking. But with such simplistic sender, that case
> would not make forward progress and would livelock.
>
> However, when sending, one should be mindful of implementations with
> limited tracking (on receive side):
>
> - Do not have fragment sequence jump back.
> - Do not have multi-message records unless all but the last are
>   guaranteed to be complete.
>
> What is the current maximum for number of messages in one flight?
> 6 (ServerHello, EncryptedExtensions, CertificateRequest, Certificate,
> CertificateVerify, Finished)?
>

Ah, when you say simplistic sender and linear tracking, do you mean a
sender that only tracks the prefix of bytes that have been sent? I.e. if it
sends records 1, 2, 3, 4 and I ACK record, it is unable to deal with
reordering and ignores it? Yeah, I think I agree that would indeed get
stuck in this case. Maybe not the best plan for a sender given that records
can get reordered, but ah well. For non-final flights, it's fine because
even if no ACKs get through, the peer will send the next flight which
implicitly ACKs everything. But for final flights, we do require that you
eventually manage to ACK the whole flight. There isn't a succinct way for
the peer to say "yeah, I got all that".

On the receive side, I think simplistic receivers are fine? If the
simplistic receiver drops some fragments because they're in a funny order,
they shouldn't ACK it, so the sender will know to include it in the
retransmit.

6 sounds right. We use 7, but that's because we still support NPN and
Channel ID in (D)TLS 1.2, so the maximum for us becomes 1.2's
ClientKeyExchange, Certificate, CertificateVerify, NextProto, ChannelID,
ChangeCipherSpec, Finished. (ChangeCipherSpec isn't a message, but it takes
up a slot in the outgoing queue in our implementation right now.)

> > There is in fact another subtle edge case which requires ACKing stuff
> > > from previous flight:
> > >
> > > - Sender sends flight that has no response or response is blocked.
> > > - The complete flight comes through, but the last ACK is lost.
> > > - Sender re-transmits the (possibly partial) flight.
> > >
> > > The receiver considers flight complete, but sender does not. Getting
> > > things unstuck requires ACKing stuff from previous flight.
> > >
> > > However, this does not require keeping the records from previous flight
> > > in the list.
> > >
> >
> > Well, there's two ways to get it unstuck. You could either explicitly ACK
> > the previous flight, or just start sending your reply, which implicitly
> > ACKs that flight.
>
> If the blocking flight has response, then explicit ACK is required to
> avoid deadlock (to get out of state where both sides have flight in
> progress). But this can only happen post-handshake.
>

Oh I see. The concern is a sender that is only willing to have one outgoing
flight at a time? So if both sides, say, send a post-handshake
CertificateRequest, neither will be willing to move on and send a
responding Certificate until then things have cleared. I agree that this
situation is indeed a problem.

I'm not sure what's the best way out of that mess. The spec says you
"duplicate" the state machine, whatever that means, but having only one
outgoing flight is indeed a very sensible restriction; it's one I've been
considering for our implementation. The specification is incredibly
ambiguous around how parallel post-handshake transactions work! I still
need to figure out how we want to handle post-handsh

[TLS] Re: DTLS 1.3 ACK sorting, and when to clear the ACK buffer

[David Benjamin]

On Tue, Nov 5, 2024 at 2:25 PM Ilari Liusvaara 
wrote:

> On Tue, Nov 05, 2024 at 11:47:44AM +, David Benjamin wrote:
> > On Mon, Nov 4, 2024 at 5:19 PM Ilari Liusvaara  >
> > wrote:
> >
> > >
> > > If the blocking flight has response, then explicit ACK is required to
> > > avoid deadlock (to get out of state where both sides have flight in
> > > progress). But this can only happen post-handshake.
> > >
> >
> > Oh I see. The concern is a sender that is only willing to have one
> outgoing
> > flight at a time? So if both sides, say, send a post-handshake
> > CertificateRequest, neither will be willing to move on and send a
> > responding Certificate until then things have cleared. I agree that this
> > situation is indeed a problem.
> >
> > I'm not sure what's the best way out of that mess. The spec says you
> > "duplicate" the state machine, whatever that means, but having only one
> > outgoing flight is indeed a very sensible restriction; it's one I've been
> > considering for our implementation. The specification is incredibly
> > ambiguous around how parallel post-handshake transactions work! I still
> > need to figure out how we want to handle post-handshake messages, but I'd
> > definitely been considering that restriction. But I also don't intend to
> > implement any multi-flight post-handshake transactions because, well, we
> > don't need them but more importantly I cannot make sense of how to make
> > them work well at all. (See all the threads I've started here.)
> >
> > I'm not sure what's the best way out of that mess, but I hope we can
> spend
> > time with the badly-needed rfc9147bis to improve this.
>
> Another edge case:
>
> - Sender sends two parallel flights, the second one prepares epoch
>   change.
> - Receiver can buffer multiple messages at once.
> - One of the messages from first flight is lost, the second flight
>   goes all through.
> - The receiver ACKs everything it got.
> - The sender thinks second flight is complete, the receiver thinks it
>   is incomplete.
> - Prepare for epoch change is complete, so sender changes epoch.
> - Receiver is not ready for epoch change. If the keys for the next epoch
>   depend on the preparing flight, it can not even compute the correct
>   keys.
>
> To avoid that problem:
>
> - Each epoch can have at most one message that prepares epoch change.
> - All flights up to one that prepares the epoch change must be completed
>   before the actual epoch change.
>
> Currently, the messages that prepare epoch change are Finished (only
> within handshake), and KeyUpdate. But there could be more in the future.
>
>
> There is WG draft for Extended Key Update. That can be initiated from
> either side, needs at least three flights (and the current version has
> four flights) and prepares epcoh changes. Basically hits every edge case
> there is.
>

Oh yeah, KeyUpdate as specified in RFC 9147 is completely broken. I started
a thread about it back in
https://mailarchive.ietf.org/arch/msg/tls/_ku3-YDcroNmG_QKZsYTtqYzC0M/


> > > With regards to state-keeping, i think that it would be enough to
> > > track the following:
> > >
> > > - The first message sequence in the current flight.
> > > - Current flight complete flag.
> > > - First message sequence in next flight (if current flight complete).
> > >
> > > ... Which fits in 5 bytes (+ padding).
> > >
> > > This lets one recognize if record belongs to past (ignore), current
> > > (process) or next (next becomes current, and process) flight.
> > >
> >
> > Hmm, I'm not sure if that's sufficient. While the sender might choose to
> > restrict themselves to only one outgoing flight at a time for
> simplicity, a
> > receiver can't assume that the sender has done so. The sender might have
> > decided to send 10 NewSessionTickets in parallel. On the receiver side,
> you
> > might receive them, maybe even in order, and then ACK them in sequence.
> But
> > perhaps the very first ACK got lost, so the sender retransmits the first
> > NewSessionTicket. It is expecting you to ACK it again, or it will keep
> > retransmitting.
>
> Oh yeah, it does not work if there can be multiple outstanding flights.
>
>
> > That means that, post-handshake, the receiver needs to ACK messages
> > basically arbitrarily back. That is fine because you still only need to
> > track the current sequence number and ACK any past ones without
> processing
> > anything. But it means the notion of "current flight" is everlasting.
> Every
> > post-handshake transaction leaves its final flight around as the "current
> > flight".
> >
> > But now suppose you want to distinguish "current flight" from "past
> flight"
> > and only ACK current flights. *Now* you need per-transaction state to
> know
> > which old sequence numbers are from current vs past flights, in every
> > post-handshake transaction. This seems problematic, so I think we should
> > make sure the protocol works if you ACK all past sequence numbers
> > indiscriminately. But if that's simpler, may

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

[Sean Turner]

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] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Sean Turner]

> On Nov 5, 2024, at 16:25, 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. 

Whoops November 26, 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] Fwd: New Version Notification for draft-connolly-tls-mlkem-key-agreement-04.txt

[Deirdre Connolly]

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] The TLS WG has placed draft-gutmann-tls-lts in state "Call For Adoption By WG Issued"

[IETF Secretariat]

The TLS WG has placed draft-gutmann-tls-lts in state
Call For Adoption By WG Issued (entered by Sean Turner)

The document is available at
https://datatracker.ietf.org/doc/draft-gutmann-tls-lts/


___
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

[Nick Harper]

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  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] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Watson Ladd]

I'm against adoption. 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.

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

[TLS] Re: FATT process update

[Rob Sayre]

I think Rich should retitle his document to "A 'permanent' Design Team for
TLS", but then we can get on with it.

The title is confusing because the first sentence is:

"This memo defines a permanent design team, as defined in [WGPROCS],"

That's a nit, but I think we want to be clear no process is actually being
invented (WGPROCS says you can do anything you want aside from all the
usual Note Well concerns).

thanks,
Rob


On Tue, Nov 5, 2024 at 7:34 AM 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.
>
> 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: Adoption call for TLS 1.2 Update for Long-term Support

[Rob Sayre]

On Tue, Nov 5, 2024 at 8: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.
>

I do not support adoption, but do not view it as what they call an "end
run" around the WG. So, it would be fine to go to the ISE I think. If it
gets some traction, the WG can take it up again. It's not a permanent
decision.

thanks,
Rob
___
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

[Alicja Kario]

I do not support adoption.

On Tuesday, 5 November 2024 17:25:16 CET, 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/ 


--
Regards,
Alicja (nee Hubert) Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

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

[TLS] Re: DTLS 1.3 ACK sorting, and when to clear the ACK buffer

[Ilari Liusvaara]

On Tue, Nov 05, 2024 at 03:24:16PM +, David Benjamin wrote:
> On Tue, Nov 5, 2024 at 2:25 PM Ilari Liusvaara 
> wrote:
> 
> > There is WG draft for Extended Key Update. That can be initiated from
> > either side, needs at least three flights (and the current version has
> > four flights) and prepares epcoh changes. Basically hits every edge case
> > there is.
> >
> 
> Oh yeah, KeyUpdate as specified in RFC 9147 is completely broken. I started
> a thread about it back in
> https://mailarchive.ietf.org/arch/msg/tls/_ku3-YDcroNmG_QKZsYTtqYzC0M/

Ugh, yeah, that is broken (the same-epoch requirement messes things).

Why is the same-epoch requirement there? I get that it is important that
the handshake messages get sent with correct epoch, but there is obvious
reason to keep epoch with post-handshake messages.

That is of course other than those that prepare epoch change, but there
can only be one in epoch, and all prior flights must be complete before
the actual epoch change.

 
> > What if the past flight has reply? Unless one has got an (implicit) ACK
> > from the other side about the reply, retransmission on flight signals to
> > retransmit the reply.
> >
> > E.g., server sends CertificateRequest and 9 NSTs in parallel. Client
> > insta-NAKs the CR, and ACKs all the NSTs. The NAK gets lost. Server
> > re-transmits the CR. Now client has to resend the NAK from 9 flights
> > back.
> >
> > Since any such reply must be pending flight, one could track the range
> > of message sequences that trigger retransmit for pending flight.
> 
> 
>  (Guessing by NAK you mean replies with an empty Certificate message?)

Right.

 
> That is a good point. Until you've gotten the reply ACKed, you also need to
> store enough information to reconstruct that. Yet more things that RFC 9147
> should be spelling out.
> 
> Actually, for that matter, what ensures that the multi-message flights in a
> post-handshake transaction are consecutive? 

AFAICT, that requirement gets inherited from TLS 1.3.




-Ilari

___
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

[Salz, Rich]

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] Re: FATT process update

[Salz, Rich]

  *   I think Rich should retitle his document to "A 'permanent' Design Team 
for TLS", but then we can get on with it.

I think my draft served my intended purpose, and while I prefer design team 
over FATT, I don’t see a reason to push forward on my draft any more.  (And 
thanks for the nice words.)

I like the current plan. There are, of course, still issues to work out, but 
the architecture is now sound :)

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

[TLS] Re: FATT process update

[Rob Sayre]

To clarify here,

You can't have a reference here to " A "permanent" Design Group for TLS".
That term is wrong and confusing.

I don't disagree with all of the rest, which has changed since the last
round, but that does need to be fixed up.

Maybe Rich doesn't want to update his draft, but that needs to be fixed.

thanks,
Rob


On Tue, Nov 5, 2024 at 9:51 AM Rob Sayre  wrote:

> I think Rich should retitle his document to "A 'permanent' Design Team for
> TLS", but then we can get on with it.
>
> The title is confusing because the first sentence is:
>
> "This memo defines a permanent design team, as defined in [WGPROCS],"
>
> That's a nit, but I think we want to be clear no process is actually being
> invented (WGPROCS says you can do anything you want aside from all the
> usual Note Well concerns).
>
> thanks,
> Rob
>
>
> On Tue, Nov 5, 2024 at 7:34 AM 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.
>>
>> 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: Adoption call for TLS 1.2 Update for Long-term Support

[Arnaud Taddei]

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


-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-m

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

[Eric Rescorla]

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 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
>
>
>
> This electronic communication and the information and any files
> transmitted with it, or attached to it, are confidential and are intended
> solely for the

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

[John Mattsson]

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 

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: mailto:internet-dra...@ietf.org>>
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 mailto:durumcrustu...@gmail.com>>


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

[Thom Wiggers]

Hi all,

I don’t think that we should consider saying that TLS 1.2 (or a variant) is an 
okay and safe choice for the next 10+ years while this protocol will not 
receive post-quantum security updates (if we stick with “no PQ for TLS 1.2”). I 
realize that integrating PQC in a “LTS” deployment might not be feasible/stable 
enough at this moment, but I fear that putting out a “TLS-LTS” gives people 
“permission" to ossify on non-PQC (as it will not be backported) for a 
considerable amount of time longer.

For this reason, and the same reasons as stated by Eric, Nick and Watson, I am 
against adoption of this document (or at least in this form). There may be 
contents of this document that we might consider extracting 

Cheers,

Thom

> Op 6 nov 2024, om 06:45 heeft Eric Rescorla  het volgende 
> geschreven:
> 
> 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 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.

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

[tirumal reddy]

On Mon, 4 Nov 2024 at 19:47, Alicja Kario  wrote:

> Hello,
>
> I don't think we should go back to signing with PKCS#1 v1.5 in TLSv1.3.


> I'm opposed to including those two IDs:
>
>  mldsa44_rsa_pkcs1_sha256 (0x090C),
>  mldsa65_rsa_pkcs1_sha384 (0x090D),
>

I wanted to remove them but I see TLS 1.3 allows rsa_pkcs1 for certificates
but not for certificate verification and it is mandatory to implement
digital signature. I will update the draft to restrict its use to
the "signature_algorithms_cert" extension.

-Tiru


>
> Theoretically we could require the RSA part to still make PSS signatures
> but I think that would be rather hard on the cryptographic backends...
> So I'd rather not have them.
>
> On Sunday, 3 November 2024 01:07:34 CET, tirumal reddy wrote:
> > Hi all,
> >
> > 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.
> >
> > Comments and suggestions are welcome.
> >
> > Regards,
> > - Tiru
> >
> > -- Forwarded message -
> > From: 
> > Date: Sun, 3 Nov 2024 at 05:33
> > Subject: New Version Notification for
> draft-tls-reddy-composite-mldsa-00.txt
> > To: Tirumaleswar Reddy.K , John Gray
> > , Scott Fluhrer ,
> > Timothy Hollebeek 
> >
> >
> > A new version of Internet-Draft draft-tls-reddy-composite-mldsa-00.txt
> has
> > been successfully submitted by Tirumaleswar Reddy and posted to the
> > IETF repository.
> >
> > Name: draft-tls-reddy-composite-mldsa
> > Revision: 00
> > Title:Use of Composite ML-DSA in TLS 1.3
> > Date: 2024-11-02
> > Group:Individual Submission
> > Pages:8
> > URL:
> > https://www.ietf.org/archive/id/draft-tls-reddy-composite-mldsa-00.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-tls-reddy-composite-mldsa/
> > HTML:
> >  https://www.ietf.org/archive/id/draft-tls-reddy-composite-mldsa-00.html
> > HTMLized:
> > https://datatracker.ietf.org/doc/html/draft-tls-reddy-composite-mldsa
> >
> >
> > Abstract:
> >
> >This document specifies how the post-quantum signature scheme ML-DSA
> >[FIPS204], in combination with traditional algorithms RSA-
> >PKCS#1v1.5,RSA-PSS, ECDSA, Ed25519, and Ed448 can be used for
> >authentication in TLS 1.3.  The composite ML-DSA approach is
> >beneficial in deployments where operators seek additional protection
> >against potential breaks or catastrophic bugs in ML-DSA.
> >
> >
> >
> > The IETF Secretariat
> >
> >
> >
>
> --
> Regards,
> Alicja (nee Hubert) Kario
> Principal Quality Engineer, RHEL Crypto team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org